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.
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.
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
- Effective capital budgeting
- Proper project sizing
- Estimate uncertainty
- A focus on defect removal
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.
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 UncertaintyProject methodology needs to take into account expected uncertainty.
Projects with low uncertainty can be handled with a traditional project methodology; these projects can have their 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 RemovalDeveloper'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).
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 projects fail to come together and succeed.