Requirements management and configuration management are required for anything that even closely resembles effective testing. Experience suggests failing in these two areas unnecessarily complicates the product verification activities, and we will show some of those traumas in the next few posts. An iterative and incremental product development process calls for reviews throughout the development process. […]
In some recent discussions with product development neophytes, we have heard a merging of the concepts of verification and validation. Let us set the record straight. Verification and Validation are not synonymous. The World English Dictionary defines verification as “establishment of the correctness of a theory, fact, etc…” and validation as “to confirm or corroborate”. […]
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 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 […]
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 […]
So how do we ensure we get meaningful requirements? We have a number of ways to understand our objective and learning about the Interviews customer clinics Simulation Digital mock ups Prototype physical mock ups Instrumentation Other information gathering (standards, regulations, etc.) We start with interviews of customers, stakeholders and project sponsors. Interviews also include customer […]
When working for a company that takes cost reductions seriously, we can expect to see some categories repeated. Let’s take a look at these and what they are: Cost reduction: we spend less on a line item than our budget Cost avoidance: we choose to spend and then decide not to (often occurs with capital […]
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 […]
Teams must grow; teams cannot be simply appointed and anointed. We may have a designated group that evolves into a team, but this emergent phenomenon takes time. It takes time to discover the strengths and weakness if each member of the group, understanding that ultimately transforms into trust, the backbone value/concept for any successful team. […]