Consider this, few projects fail because of unusual or unforeseen problems. If you are trying to go so fast that you don’t do your due diligence or decide to skip steps then — “You get what you deserve!“.
Projects succeed because they do not rely on force of personality and luck.
Only 3 of 10 software projects succeed (see Understanding Your Chances). Success happens when you implement best practices and avoid worst practices; not just talk about them and convince yourself that you are doing them.
Therefore 7 out of 10 projects fail, even if you redefine ‘challenged projects‘ as political victories; these projects are often severely over time and budget.
It is estimated that between $3 trillion and $6 trillion dollars are wasted every year in IT; by organizations that “don’t know, and don’t know that they don’t know“, i.e. what you don’t know can definitely hurt you.
What is amazing is that failures do not prompt the incompetent to learn why they failed. After the post-fail finger-pointing ceremony, people just dust themselves off and rinse and repeat.
There is never enough time to do the project correctly, but there is always enough time to do it again.
Ingredients of a Successful Project
Successful software projects have the following characteristics:
- Effective capital budgeting
- Proper project sizing
- Estimate uncertainty
- A focus on defect removal
Capital Budgeting
Capital budgeting means having business cases for major projects and allocating capital to the most promising projects; a little due diligence prevents bad projects from starting.
For example, RJ Reynolds invested $325 million to develop smokeless cigarettes when they knew in the initial pilot that the cigarette tasted bad and no one would buy them.
Project Sizing
If a project has a good business case, then the next step is to figure out how big the project is. This requires that you expand the requirements sufficiently to estimate time and cost.
When it comes to software — size matters.
Not only does size matter, you need to understand the level of uncertainty (requirements, technical, or skill) tied to your project to understand how much re-work or discovery will be necessary.
- Re-engineering a product with new technologies? (high technical uncertainty)
- Building a new product with existing technologies? (high requirements uncertainty)
- Building software with a team unfamiliar with the technology? (have high skills uncertainty)
Skipping the time to get estimates is a major cause of project failure.
There are still executives that give engineering a few hours or a few days to estimate major projects and wonder why the projects go late or get cancelled.
Estimate Uncertainty
Project methodology needs to take into account expected uncertainty.
Projects with low uncertainty can be handled with a traditional project methodology; these projects can have there work breakdown structures elaborated and dependencies can be worked out ahead of time.
Projects with moderate to high uncertainty will require rework and discovery. This must be built into the project plan or you need to switch to an Agile methodology. If you don’t then there will be missing tasks on the project plan as well as task duration that is under-estimated.
Project tasks get stuck at 90% complete because the sources of uncertainty are not established a priori.
Executing a project with personnel that are not competent with the technologies that you want to use is essentially professional malpractice. If you must use existing personnel that don’t know the technologies you want then you need to build in a large margin for training and rework over the project; these projects will take at least 2x as long as your worst estimate.
Focus on Early Defect Removal
Developer’s say: “There is never enough time to write the code“. Statistics say, “There is never enough time to find all the defects” (see The Programmer Productivity Paradox). To be successful you need to find defects as quickly as possible, especially since:
- If it costs X to find a defect pre-test
- It costs 10X to find it in QA
- It costs 100X to find it once deployed in the field
You do the math, it costs less to find defects before they get to QA. You are kidding yourself if you think that it is cost effective to have huge QA departments (see The Cost of Not Doing Quality).
Conclusion
Building software reliably and repeatably is not difficult. What is difficult is getting organizations to realize that there is a minimum set of processes that must be followed to have a successful project.
Organizations regularly skip one or more steps and wonder why projects fail to come together and succeed.
| Reference: | Failed! You get what you deserve! from our JCG partner Dalip Mahal at the Accelerated Development blog. |
