Archive for the
‘Requirements Management’ Category

Our configuration management is borne out of our requirements.  In our earlier blog post, we discussed how the project scope must be traceable to the requirements. In the case we present below, the project scope is a particular function or need to be met, for example a new feature or function for an automobile.  We […]

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 […]

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 […]

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 […]

“Scaffolding” is a term often used in education, but in our experience, rarely followed to a significant extent. Scaffolding allows us to grow a student in capability by starting easily and providing progressively more intricate and involved exercises. This approach actualizes Lev Vygotsky’s concept of the zone of proximal development. When training clients, we must […]

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. […]

The Pareto chart (not to be directly confused with the Pareto probability distribution function) is a simple approach to revealing significance in data. Before we plot our chart, we need to complete some initial work: Gather the data in a natural format (count, floating point [decimal], dollars, etc.) Sort the data from high to low […]

I have been having a running discussion with one of my colleagues regarding project and cost, specifically the cost of a project that is under consideration for termination.  A project is going through a gate review. During this review we find that the objectives are not met by this phase and further action has little […]

We can use value analysis and value engineering techniques to improve our product cost structure and ultimately our value proposition.  The analysis phase of this activity is called value analysis. The design phase of this activity is called value engineering.  We are a bit constrained during these activities since as we have a product already […]