Risk Management Through the Project
In modern life, risk management is a fundamental discipline for success. This does not just apply to work life, or project management but also personal life. Today we are going to discuss the approaches and impacts on the project when there is insufficient attention to the risks to which the project will be subjected. The risks to which our work will be subjected depends upon the what we are doing and how we go about doing it, that is, the strategies and tactics we employ to reach the objective.
Consider an automotive project to develop a new product. This will require understanding the need, creating the design, develop the manufacturing line and verify and validate the product and the manufacturing line, and ultimately launch the product at the production rate. We demonstrate in our SAE book, an example of how these phases work and how these phases share information.
Risk Management Class
We … Continue reading
A company is deciding to undertake product development project, there is a consideration that amounts to a type of bet. Continue reading
We have written much on requirements in other blog posts. We have been maintaining this blog for years, admittedly sometimes more fervently than others. We have created a schedule for our blog posts and other events by Value Transformation personnel available either on the event location on the website or as a downloadable from the website.
There seems to be a myth that “waterfall” development requires ALL of one step in the delivery sequence before the next step can begin. For example, all requirements must be written before work commences on the development work. I have worked in what I would call traditional development approaches that some would refer to as waterfall, and at no time did we believe or act as if all requirements must be known and documented before we moved to the next stage, the actual development. Even PMI recognizes the need work with the level of detail that can be known from where the … Continue reading
Flip a coin, heads or tails. The probability that it will come up heads is 50%, after all there are only two sides. Flip that same coin again, the same probability, 50%. However, if we say that success is two successive heads (or tails) that is different. The probability of two consecutive heads, is the product of the two coin tosses (50% x 50%) or 25%.
I’m sure we understand task dependencies. This is fundamental to project management and schedule. Dependencies are the connections between tasks for example, I must put socks on before I put my shoes on (assuming I wear socks, which I generally do). Of course, this is not the only type of dependency (finish-start). There are four actually;
Finish-start Start-start Start-finish Finish-finish
Let us focus on finish-start for a bit. Specifically, lets talk about a portion of the resulting schedule and the task consequences on the entire project.
Each task has … Continue reading
Taxonomy of Project Failure – Risks
Experience suggests there are many ways to project failure due to our project management actions, this does not include the riskiness of the effort in general that comes with the uncertainty associated with projects – these are not operations. Projects by definition have uncertain components, this is especially true in product development and especially in software product development. That taxonomy would look much different than the one below as we could have, for example, material, processes, people, technical, measurements and many other ways to breakdown or categorize the failures. However, project management is there to make things better, or it should be. It is there to improve our probability of success, not bring in additional potential project failure modes that must be navigated. It seems all too often what really happens is poor project management does not make the situation better, but snatches defeat out of the jaws of success. Below find a breakdown … Continue reading
This blog post originates from Capers Jones LinkedIn comments about toxic requirements. He posted a comment to a requirements article and brought up bloated requirements and toxic requirements. I have never heard of the name “toxic requirements” perhaps that is uniquely Capers Jones identifier – I like it. However, I believe I have experienced toxic requirements. An example I have frequently witnessed would be requirements that are politically charged, not in the governmental sense but in the organization’s sense. Have you seen the same set of requirements come in on many different projects? Each time the requirements are deferred or remove, yet these continue to re-appear. These requirements may have little to do with the project objectives, but these requirements are the “pet” of some person or entity within the company. We spend more time wrestling with these requirements than building the product. We will risk the significant portions of the project, specifically, those requirements that will actually achieve … Continue reading
We have discussed the nonfunctional requirements for extensibility in our earlier posts. Now we turn to others in the nonfunctional list of requirements. Today we are going to consider maintainability. Maintainability is the measure of ability to successfully repair or fix the product after manufacturing, usually in the field, and over time.
For manufacturing entities, many of the maintainability requirements are born out, at least in part, by the manufacturing and assembly environment of the customer organization. The Design for Assembly (DFA) and Design for Manufacturing (DFM). The building of the product with ease will frequently translate into the maintainability requirements. That is not to say all will. The manufacturing line will often have specialized tools and conditions that ensure the long-term and repeatable production of the product. For example, the modular approach we take to manufacturing the system that may arise from our DFMA work will also likely help with the maintainability of the product in the field. So too … Continue reading
You do not have to go it alone when it comes to developing requirements. There are many templates and well-defined approaches to help in this regard. If you are developing a complex system, it is good to break the requirements up, starting at the highest level of abstraction. We will call that systems specification. The Institute of Electrical and Electronic Engineers (IEEE) standard 1233, Guide for Developing Systems Requirements Specifications, provides a good starting point for the documentation structure from which we can adapt to our specific needs. Many organizations work from internal templates which provide the structure of the topics that must be considered when developing the requirements.
System Development and Requirements
For a sufficiently complex system, we may have a number of specifications involved. We will choose to work from the greatest level of abstraction of the product, in other words, take a system’s orientation, to develop and define the attributes of the system required to meet the … Continue reading
In keeping with our requirements work, we will start by identifying the attributes of a good requirement. We start our project off with the requirements, so it stands to reason if we start off poorly or in the wrong direction, we will not make the objective. This situation will get worse the longer we spend time with poor requirements.
Requirements are not loose; these are tangible statements of the product that are able to be refuted or confirmed. As we have seen, requirements are part of our project contract closure, but it is also part of our product testing. To be able to effectively do either of these means we must have requirements that fit the attributes defined below:
Cohesive Complete Consistent Correct Observable Feasible Unambiguous Required Verifiable Traceable Requirements Failures
Requirements not written in a way that meets the attributes defined above poses some level of risk to the endeavor or the project outcome. For … Continue reading
In this series on CMMI (capability maturity model integration) and requirements, we have discussed:
understanding requirements commitment to the requirements control changes to requirements traceability of requirements from detail to scope and back inconsistencies, the difference between of what is included and what is being done
The processes above work together and amount to managing the requirements. The degree to which our company consistently does these things in a repeatable way is the degree this approach is institutionalized. Do we skip these steps when in times of duress? Experience suggests this happens more often than we care to admit. If you watch Aircraft Disasters on the Smithsonian Channel (or on Netflix) you will see many of the disasters there are due to skipping process steps that seem innocuous or benign in consequences, only to find out this small alteration in the context of the rest of the system or situation presented is quite disastrous. An episode that … Continue reading