The quantity of project successes seem to be to be as alien as finding life on Roter planet. Is it true that software projects fail that often?
What is inability? When any of the following 4 occur, a project is considered an inability:
the required operation is not met
there is a time overrun,
there is a cost overrun,
a combo of any of the above 3.
There are projects that are totally scrapped for political and other reasons but I am keeping them out of this post. It will be interesting to see if someone can find the breakdown of the 70-80% failure rate among the 4 factors listed above to provide a bit more quality on where most jobs are failing.
Required Operation Not Met
The responsibility for this squarely is best left to the project team plus more so on the Business Expert. Nevertheless , I would like to add some situation to this statement. In a traditional waterfall model the requirements are accumulated first, analyzed and make their way through the SDLC process. In large projects the time distance between gathering requirements and UAT is significant, few of years in some cases. Within a speedily changing world now distance is significant as the requirements could have altered for no fault of the BA or the project team. And also the business environment is such that things change quickly (the financial crisis in 08 drastically altered the way that banks view liquidity) or new legislation was introduced (think Dodd-Frank or Basel) that calls for a significant change in the way in which business is conducted. All of these are beyond the power over the project team, though sufficient hints will be available (and will be seen by a willing BA) of impending changes. If nothing has transformed and the functionality is still not met, the condition may have been a result of any of the many points over the SDLC lifecycle - certain requirements were poorly written, limited analysis, inappropriate design presumptions, no technical walkthroughs, low of the caliber of the complex team, no unit assessment, no SIT or low quality of SIT, or simply insufficient time to do any of these.
Time And/Or Cost Overrun
The reason why I incorporate the two is, in most cases, because they go hand-in-hand. (In some instances, as in in which the job is on hold and people are moved to other projects temporarily, there may be an occasion overrun but not a cost overrun). For effective description, there has to be a benchmark. Once we say a job overran time or budget then the implicit supposition is that the time and budget estimates were accurate in the first place. When does this happen?
Generally, time is pre-determined either by the business or the project supervisor or someone higher up. "The project go-live time is 30th June". Which it! Work backwards and figure out how to fit the SDLC within that time frame. Having scratched around we physique the requirements and examination are due in 5 days! The time quotes are inaccurate, grossly under estimated and fundamentally wrong. Come June 30th the job is checked for finalization and is given an 'F' grade. How major is that?
So is the case with the budget. Estimating time and cost is an not perfect science. There are many methods that contain been around ranging from the a minimum of complex-pick-a-number-from-thin-air to very structure function point analysis with a variety of others with different examples of complexity lying down in between. But also for a few, almost all of the tasks I have been part of the budget is determined by someone who is detached from fact and hasn't heard of any of the calculating mechanisms. In some occasions these numbers were pruned down by this section. Now, what does the budget department know about the system? Zilch. Will be these high-end methods reliable enough to produce a precise estimate? No. But we now have some basis for the numbers.
Why don't many folks use these methods? Lack of time is the common answer. There may be another reason too - deficiency of information to suggestions into these methods. This is very interesting to note the stage where the cost is predicted. In almost all situations the cost is believed even before the requirements process starts! The reason is simple - "we need to create a project charter for which we need a pitch. Give us a number". Surprisingly these guesstimates become estimates and finally provide as the benchmark against which the final results are compared.
We have an inaccurate time and cost estimate to commence with. Is it good to compare the real time and cost of the project against these inaccurate numbers? No, but this is precisely the conundrum we are in.
Here is some food for considered to break the cycle:
Elicit requirements fully and analyze them. These costs may not be made a fortune anyway. These are sunk costs if projects may happen but at least they provide a better insight.
Estimate time and cost based on those detailed requirements.
Use a reasonable estimation method to arrive at as well as cost.
Compare actual project time and actual costs against these estimates.
Let's breast up those project inability reasons to deliver job success!
Comments
Post a Comment