We have witnessed a disconcerting trend.  That trend is in consolidating risk reserves for projects into one, centrally managed bucket of money.  This bucket was once reserved for the unknown-unknowns and was called a Management Reserve.   However, more businesses are beginning to strip projects of their known-unknown Project Risk Reserves and placing calculated project contributions […]

By: Rick Edwards A good carpenter never blames his tools. There is also an aphorism “it is the poor musician who blames his instrument”.  Why do so many good project managers blame their scheduling tool when their project schedule doesn’t fit their desired schedule? Project managers often struggle with documenting task dependencies utilizing the technology […]

We have recently had a discussion on what it takes to quality assure software. The discussion focused on FMEA and the role it plays in quality assurance.  The discussion began to sound as if the FMEA was the panacea for poor quality. There is no silver bullet. To be sure the FMEA (which is essentially […]

We have our requirements, our iterative packages and content defined, and now the developers are producing the iterations. During this time, the verification and test folks have been creating the test cases or details on how we intend to confirm the product performance. Our requirements provide the fodder for our testing.  For each requirement there […]

Once we have our captured our requirements. We identify the substance of the content for the iterations from the development.  In fact, recall from the requirements prioritization blog post. That work has given us some insight into how the iterative packages could be developed and what content or capabilities are to be delivered.  In the […]

The initial product requirements provide the product baseline. Our project planning will be focused upon delivering meeting these requirements. In a phased development process, we will prioritize the requirements (shown earlier) and deliver iterations.  This staged delivery allows us to gain additional insight into the product.  We may learn things that necessitate changes to the […]

We now have linked our scope through to the various levels of requirements. We are then able to prioritize the delivery of the various project obligations.  The prioritization may be based, for example upon: Technical need Customer need Regulatory requirements Complexity and Risk Technical needs are the dependencies to getting the product features working, for […]

This may sound difficult, but there are some rules for good requirements.  According to the International Council on Systems Engineering (INCOSE http://www.incose.org/chicagoland/docs/Writing%20Effective%20Requirements.pdf), requirements should have the attributes below (similarly can be found at IEEE): Necessary –  driven by the objective of the project and business Verifiable – ability to objectively confirmed that the requirement is […]

Requirements are fundamental to project success as the scope definition.  Additionally, there are dependencies that impact the ability to produce suitable requirements.  A few of those things are: Well defined scope of the work Sponsor and customer involvement Capability of the requirements authors Prioritized functions or abilities The needs or objectives of the customers or […]

Consider a rather large project that like so many projects had some difficulties. The project team had a major component (subsystem) delivered from a supplier. The supplier has one set of processes and the customer organization another. This supplier delivers multiple versions of this major subsystem. The customer integrates this subsystem into the larger system […]