Program Management
Relax the Project Schedule
I have been enjoying Alan Cohen's A Deep Breath of Life. I read it every morning with pen in hand, never failing to find at least one or two profound sentences to be my watch-words for the day. One of the July writings contains this quote: "Only infinite patience begets immediate results." David writes about the perils of rushing through life, and how a lack of patience can causes us to create unnecessary chaos in our daily rounds. He writes, "Rushing never improves the quality of our life or the results we seek; to the contrary, it muddles our vision and causes us to make errors that cost us twice as much time and energy to repair."
Seven Steps to Software Project Failure
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.
Why Do We Keep Having the Same Problems?
The thirty years I have spent in software have bridged a period of remarkable and ever accelerating change. Mercifully, coding an online system on a black and white CRT that accesses an IMS database is mostly a quaint memory. Technology, tools, and processes have all evolved. Why is it, then, that we continue to have the same problems we experienced in the Information Technology Dark Ages? Here are the symptoms:
- Software projects that continue to overshoot their schedules
- Quality problems have neither disappeared nor lessened to an acceptable level
- Budgets are regularly exceeded: sometimes wildly
- Project estimates are inaccurate
I see two principal reasons. I’m certain there are others.
Managing Software Risk via "Whether Forecasting"
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.
What If? The Power of the Question
After being away from QSM and the software world for three years, I was blown away by SLIM v8.0's dynamic product integration. I knew it was coming, yet I was still impressed by the simplicity and power of analysis promoted by real-time data and tool links across the SLIM Suite that frees managers to focus on the important program issues.
SLIM-MasterPlan is the center of the SLIM Suite product integration. It improves upon previously existing program management features of aggregating multiple SLIM-Estimate projects and ancillary tasks with two new capabilities:
