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

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

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

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

Brainstorming as neologism began with Alex Osborn of the advertising agency BBDO in 1942. His primary concern was creative thinking. In general, classical brainstorming generally follows this pattern: Gather a group of people Decide on a duration and quantity of ideas desired Solicit ideas from group members No editing, snide comments, or insults Collect ideas […]

To reduce the chances of going too far down the wrong road, we qualify our projects with some sort of business analysis, for example internal rate of return or return on investment or some other fiduciary measurement.  If we are working from a staged-gate project management system, we will relentlessly review our project condition against […]

There is a saying: “if you change form, fit or function, you change the part number.” On the surface this seems like a good saying. People use this saying as rule of thumb to determine if a new part number is required.  Taking out new part numbers cost the company some administrative time and effort […]

Every time we make a decision, we reduce the probability of some risks but may increase the probability of other risks. Consider where the following story may fit into our discussion. We have a project that should have, in fact, started months ago to meet the desired production introduction date.  Unfortunately, that did not happen […]

There are a number of quality tools that can help to evoke the risks that may be associated with your project. One such tool usually associated with cause and effect is the Ishikawa diagram. We can use this tool to explore risks as well. We will explore what happens (cause) and how it will impact […]