We all wish that there was a simple answers to this question, but there are not. 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 understanding though: (1) Everyone has a theory , (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 the 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. Mist 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), the better the planning, the more likely the outcome will match the plan.
Of the 155 defense project failures studied in “The core problem of project failure,” T. Perkins, The Journal of Defense Software Engineering, Vol 3. 11, pp 17, June 2006.
- 115 – Project managers did not know what to do.
- 120 – Project manager overlooked implementing a project management principle.
- 125 – PMs allowed constraints imposed at higher levels to prevent them from doing what they should do.
- 130 – PMs do not believe the project management principles add value.
- 145 – Policies / directives prevented PMs from doing what they should do.
- 150 – Statutes prevented PMs from doing what they should do.
- 140 – PMs primary goal was other than project success.
- 135 – 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 start with ignoring or overlooking a core principle of project success. This cover most of the sins of Bad Management, from compressed schedules, limited budge, to failing to produce credible estimates for the work.
So where do we start?
Let's start with some principles. But first a recap
- 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 is hard work to provide accurate data about schedule, work performed, and costs on a periodic basis. Constant communications and trained personnel is necessary.
Five Immutable Principles of Project Success
-
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, 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 emerg 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
-
What 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 doesn't have a deadline and a set and mandated capabilities. Knowing there is sufficient 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?" Risk Management is how Adults Manage Projects - Tim Lister is a go place to start. The uncertainties of all project work come in two type - reducible and irreducible. For irreducible we need margin. For reducible we need specific retirement activities.
-
What periodic measures of physical percent complete assure progress to plan? This question is based on a critical principle - how long are we willing to wait before we find out we're late? This period varies but what ever it is it must ve short enough to take corrective action to arrive as planned. Agile does is every two to four week. In formal DOD 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.
With these Principles, here's five Practiuces that can put them 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 be assessed 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 operation 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 rarely on any enterprise or non-trivial project, since the needed capabilities usually have some sequential dependencies. Accept Produce Purchase Request before issuing Purchase Order.
- Perform Continuous Risk Management for each Performance–Based Project Management® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.
The integration of these five Practices are the foundation of Performance–Based Project Management®. Each Practice stands alone and at the same time is coupled with the other Practices areas. 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, Let Customer Tell Us To Stop?
All business works on managing the flow of cost in exchange for value. All business has a fiduciary responsibility to spend wisely. Visibility to the obligated spend is part of Managerial Finance. Opportunity Cost is the basis of Microeconomics of decision making.
The 5 Principles and 5 Practices are the basis of good business management of the scarce resources of all businesses.
This is how adults manage projects
