In spite of 30 years of structured programming, CASE tools, OO development, 4th GL languages, CMMI, and PMI, the failure rate for larger projects has failed to respond to all of this love and attention. We normally think of failure as a negative thing; but it can have its upside. Saddling a competitor or enemy with a doomed project could stain their career or at the very least inflict a high level of pain on them. A CEO about to retire, or whose focus is on near term stock options, may be able to boost quarterly profits by continuing to add staff to a doomed effort: one for which the customer pays for the added staff, of course.
Since failure is a constant, here is a management guide on how to assure failure. While any one step in the process can be overcome, taken together they create the perfect software project storm.
I am often asked this question during SLIM Training classes. I remember wondering about that myself. It is a logical question since SLIM-Estimate workbooks are often imported into SLIM-Control to create the baseline project plan. The answer is ‐‐ they are not directly related, because uncertainty ranges, probability curves, and control bounds are designed to perform different tasks. This post is the first in a series looking at risk associated with an estimate, risk of your project plan, and handling deviations from the plan.
A colleague of mine recently sent me a blog post explaining the difference between project contingency and padding. The blogger made the distinction that padding is what often gets added to an individual’s estimate of the effort required to perform a task (in her example, a software development task) to account for project ‘unknowns’. The estimator determines the most likely required effort, then pads it with a little more effort in order to arrive at an estimate to which he or she can commit. Thus, padding represents an undisclosed effort reserve (and implied schedule reserve) to buffer against potential risk. Contingency reserve, she explains, is “an amount of money in the budget or time in the schedule seen and approved by management. It is documented. It is measured and therefore managed.” Ms.
Here's a risk question for you:
If today’s weather forecast predicts a 40% chance of rain and it actually rains, was that forecast “inaccurate”? If the weather channel predicts a 40% chance of rain, but the sun shines all day, was the forecast “accurate”?
Software project estimates, like weather forecasts, should always be accompanied by some explicit attempt to quantify the risk that the actual outcome will differ significantly from the estimated outcome. Estimates delivered without explicit risk assessment are more like targets: goals someone wants to achieve.
Seen from an airplane window, the ground looks almost two dimensional. Only the largest features: cities, rivers, and mountain ranges, stand out against the background. The true complexity of the terrain only becomes apparent after we land and have to navigate through congested traffic, bad weather, and one-way streets.
Software projects are similar. Staffing and budget plans are often based on high level requirements that tell us what needs to be done, but not how to accomplish it. As business objectives are translated into the actions that need to be taken and the work products that must be produced, the size of the project, whether expressed in lines of code, function points, or RICEF objects, increases along with the time and effort required to create them.
Events are said to be independent when the outcome of one event does not affect the other.
On the other hand, two events are dependent when the occurrence or nonoccurrence of one event does affect the probability of the other event.
This is an important distinction, as we shall see.