There are Principles, Practices, and Processes of project success. I have a book coming that describes them. These are independent of any method, any domain, any favorite tool, buzz words, or personal paradigm. Much research on Root Causes of project failure have led to these Principles, Practices, and Processes. The Principles don't change, can't change. The Practices need to be tailored to the needs of the project and its paradigm. The Processes are localized.
But around these are 7 Activities of any project, that if not performed in some way, the probability of success is reduced, sometimes to Zero.
- Plan the scope of work.
- Break down the project scope of work into finite pieces that can be assigned to a responsible person or an organization for control of the technical, schedule, and cost objectives.
- Integrated the project work scope, schedule, and cost objectives into an agreed upon plan against which accomplishments can be measured. Control the changes to this plan.
- Capture the actual costs of doing the work and record the accomplishments produced by this work in units of measure meaningful to the decision makers.
- Objectively assess the accomplishments at the level the work is performed in those same units of measures
- Analyze any significant variances from the plan, forecast the impacts of these variances, and prepare an Estimate At Completion based on the performance to date of the work performed. Define corrective actions.
- Report this information to the project team and customer, so agreement on corrective actions can result.
Domain and Context
No matter if your building bridges across rivers, a flying machine to Mars, the next anti-virus drug, or writing software using Scrum for your internal web site, these activities must take place in some way.
- Scope - We can't have a project if we don't have some notion of what DONE looks like. What does the customer want the result to do? What capabilities does the customer want to possess when the project is complete. If the customer doesn't know, then money and time has to be spent to discover this. The Agile development method spends money to discover the requirements. This is many times the right thing to do. But time and money have to be spent.
- Work Breakdown - As we discover what DONE looks like it may change. This is the nature of projects. As we discover new descriptions of DONE, the breakdown of the work has to change with it, otherwise those performing the work, won't know what the new DONE looks like.
- Integrating People and Work - this is a straight forward process. Assign people to work. The key is self-organizing, can't be the same as self-directed. Direction comes from external sources. Organization comes from internal sources.
- Capture Costs - how much something costs is compared against how much something was planned to cost. This feedback provided steering inputs for future cost forecasting. Without this feedback there is not learning process, some not improvement is possible without feedback learning.
- Assess accomplishments - the only true assessment of accomplishment comes from customer feedback. Did the delivered product or service fulfil the needed capabilities? Measures of Effectiveness are the assessment of those capabilities.
- Analyze variances - with a plan and the actuals, you can get feedback from your performance. This is fundamental in all project domains. Kent Beck's quote optimism is the disease of software development, feed back is the cure, is applicable to all project domains, not just software.
- Report actionable information - with the variances against plan, you can then take corrective actions to get back on plan.
Without the last 4 activities, you're managing the project open loop. This might be OK if your customer doesn't care how much it will cost or how long it will take to finish the defined work. But of they do, you'll need a target cost and a target completion date, the feedback that you're making progress to those values. And of course some confidence that those targets are credible, their degree of variance, and how they are changing as the project progresses.
So one final comment
When we hear that we don't need to estimate, there is no way to have a closed loop control system. Without on estimate of the cost, schedule, and technical performance goals, the only management control system is open loop. This is unlikley to lead to success for any non-trivial project.
