Why Do Projects Fail?
Why do projects fail?
We all wish there was a simple answer to this question, but there isn’t. Anyone suggesting there is, doesn’t understand the complexities of non-trivial projects in any domain.There are enough opinions to paper the side of a battle ship. With all these opinions, nobody has a straightforward answer that is applicable to all projects. There are two fundamental understandings, though: 1) Everyone has a theory, and 2) there is no singular cause that is universally applicable.
In fact, most of the suggestions on project failures have little in common. With that said, I’d suggest there is a better way to view the project failure problem.
What are the core principles, processes and practices for project success?
I will suggest there are three common denominators consistently mentioned in various literature that are key to a project’s success:
- Requirements management. Success was not just defined by well-documented technical requirements, but well-defined programmatic requirements/thresholds. Requirements creep is a challenge for all projects, no matter what method is used to develop the products or services from those projects. Requirements creep comes in many forms. But the basis for dealing with requirements creep starts with a Systems Engineering strategy to manage those requirements. Most IT and business software projects don’t know about Systems Engineering, and that’s a common cause failure mode.
- Early and continuous risk management, with specific steps defined for managing the risk once identified.
- Project planning. Without incredible luck, no project will succeed without a realistic and thorough plan for that success. It’s completely obvious (at least to those managing successful projects), that the better the planning, the more likely the outcome will match the plan.
What are the core findings around why projects fail?
According to the findings from the 155 defense project failures studied in “The core problem of project failure,” T. Perkins, The Journal of Defense Software Engineering, these were the reasons behind the project failures:
- Project managers did not know what to do.
- The project manager overlooked implementing a project management principle.
- PMs allowed constraints imposed at higher levels to prevent them from doing what they should do.
- PMs didn’t believe that project management principles add value.
- Policies and directives prevented PMs from doing what they should do.
- Statutes prevented PMs from doing what they should do.
- The PM’s primary goal was something other than project success.
- The PMs believed a project management principle was flawed.
From this research these numbers can be summarized into two larger classes:
- Lack of knowledge: The project managers and the development team did not know what to do
- Improper application of this knowledge. This started by ignoring or overlooking a core principle of project success—which covers most of the sins of Bad Management, from compressed schedules and limited budgets, to failing to produce credible estimates for the work.
Here’s a further recap of the findings on project failures:
- Good management doesn’t simply happen. It takes qualified managers—on both the buyer and supplier side, to appropriately apply project management methods.
- Good planning doesn’t simply happen. Careful planning of work scope, WBS, realistic milestones, realistic metrics, and a realistic cost baseline is needed.
- It’s hard work to provide accurate data about schedule, work performed, and costs on a periodic basis. Constant communications and trained personnel is necessary.
So where do we start?
Here are five immutable principles of project success:
Digging deeper, here are the considerations that go into successful projects:
- What capabilities are needed to fulfill the Concept of Operations, the Mission and Vision, or the Business System Requirements? Without knowing the answers to these questions, requirements, features and deliverables have no home. They have no testable reasons for being in the project.
- What technical and operational requirements are needed to deliver these capabilities? With the needed capabilities confirmed by those using the outcomes of the project, the technical and operational requirements can be defined. This can be stated up front, or they can emerge as the project progresses. The capabilities are stable; all other things can change as discovery takes place. If you keep changing the capabilities, you’re going to be on a death-march project.
- Which schedule delivers the product or services on time to meet the requirements? Do you have enough money, time and resources to show up as planned? No credible project goes without a deadline and a set of mandated capabilities. Knowing there is a sufficient amount of everything on Day One and every day after that is the key to managing in the presence of uncertainty.
- What impediments to success, their mitigations, retirement plans, or buy downs are in place to increase the probability of success? The uncertainties of all project work come in two types: reducible and irreducible. For irreducible we need margin. For reducible we need specific retirement activities. “Risk Management Is Project Management for Grown-Ups” by Tim Lister is a good place to start.
- What periodic measures of physical percent complete assure progress to plan? This question is based on a critical principle of: How long are we willing to wait before we find out we’re late? This period varies but whatever it is, it must be short enough to take corrective action to arrive as planned. Agile does this every two to four weeks. In formal DOD [department of defense] procurement, measures of physical percent complete are done every four weeks. The advantage of Agile is working products must be produced every period. Not the case in larger more formal processes.
Here are five practices that can put these five principles to work:
- Identify needed capabilities to achieve program objectives or the particular end-state. Define these capabilities through scenarios from the customer point of view in units of Measure of Effectiveness (MoE) meaningful to the customer.
- Describe the business function that will be enabled by the outcomes of the project.
- Assess these functions in terms of effectiveness and performance.
- Define the technical and operational requirements that must be fulfilled for the system capabilities to be available to the customer at the planned time and planned cost. Define these requirements in terms that are isolated from any implementation technical products or processes. Only then bind the requirements with technology.
- This can be a formal work breakdown structure or an Agile backlog.
- The planned work is described in terms of deliverables.
- Describe the technical and operational performance measures for each feature.
- Establish the performance measurement baseline describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical performance.
- Execute the PMB’s work packages in the planned order, assuring all performance assessments are 0%/100% complete before proceeding. No rework, no transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements.
- If there is no planned order the work processes will be simple.
- This is a rarity on any enterprise or non-trivial project, since the needed capabilities usually have some sequential dependencies. Accept produce purchase requests before issuing purchase orders.
- Perform continuous risk management for each Performance–Based Project Management® process area to identify, analyze, plan, track, control, and communicate programmatic and technical risk.
Performance-Based Project Management principles
The integration of these five practices are the foundation of my Performance–Based Project Management process. Each practice stands alone and at the same time is coupled with the other practices. Each practice contains specific steps for producing beneficial outcomes to the project, while establishing the basis for overall project success.
Each practice can be developed to the level needed for specific projects. All five practices are critical to the success of any project. If a Practice area is missing or poorly developed, the capability to manage the project will be jeopardized, possibly in ways not know until the project is too far along to be recovered.
Each Practice provides information needed to make decisions about the majority flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments to progress, but are the tools needed to increase the probability of success.
Why all this formality? Why not just start coding, and let customers tell us to stop?
All businesses work on managing the flow of cost in exchange for value. All businesses have a fiduciary responsibility to spend wisely. Visibility to the obligated spend is part of managerial Finance. Opportunity cost is the basis of the microeconomics of decision making.
The five principles and five practices are the basis of good business management of the scarce resources of all businesses.
This is how adults manage projects.
Making credible project estimates is a great place to start. To learn how to hit the mark on your delivery dates, download our eBook, “Six Best Practices for Accurate Project Estimates.”