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 […]
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 […]
We have been contemplating the ways we have seen employees respond to the consequences of a decision and the imminent resulting risk. We have noted these responses and know that there are at least two categories of response, Road Sign or Ambulance. Road sign people focus on moving the organization to a better place by […]
“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 […]
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 […]
Failure to train employees is a failure to invest in our own companies. In one case, we saw an incredible decline in unplanned production line downtime when we started teaching the technicians how to do their jobs—what a concept! If we are afraid our investment will move on to the next company after we have […]