The notion of successfully managing a project starts - as always - with the 5 Immutable Principles of project success.
- What does done look like? - do we know what the customer wants? If the customer doesn't know, or can't state in some tangible terms what done looks like, then the project will have little chance of success. Other than spending money to discover what done looks like there is not much hope. What agile development does is spend money to discover what done looks like. This expense has to be done one way or the other. Someone has to pay. Agile does this explicitly through several different processes. Formal DOD 5000.02 process do this in a way as well. Pre-Milestone A activities are essential experiments to discover what the end product could look like.
- How do we get to Done? - we need a plan, a strategy to reach done. This strategy describes how we are going to perform the work, in what order does it need to be performed, and what the outcomes of the work look like. There might need to be a detailed schedule, but there are other ways to sequence the work. Agile does this. Check lists do this. A formal Integrated Master Schedule (IMS) does this. But no matter the mechanism, the work needs to be descibed in some way.
- Do we have enough of what we need to reach done? - resources, facilities, funding, tools, etc. How do we know what we need? Have we made estimates of these resouces, so those providing them can go out and get them? Are these estimates of funding, skills, facilities, developed in some credible manner. Reference Class Forecasting is a good way. Past performance is another good way. Subject Matter Experts is a way, but it has built in biases that must be dealt with if the estimate for resources is to be credible.
- Do we know what impediments we will encounter along the way? - this is called risk management. Risk management is how adults manage projects is Tim Lister's quote that must be applied to all project. Agile methods are not risk management. #NoEstimates is not risk management. Risk management is a specific process of Identifying, Analyzing, Planning, Tracking, Controling, and Communicating the risk.
- How can we measure progress to plan? - the only answer is Physical Percent Complete. This is defined in formal Earned Value Management processes. This is the basis of agile software development. This is the basis of all good project management processes. Show me the results of your work and let's confirm with the customer it is acceptable.
So What's the Point?
If these principles are not in place on your project, it'll be a disappointment. So in the end any successful project management process must answer the following:
- What are we building?
- What will it cost in the end?
- When will we be done?
- How can we recognize that what we're building is what the customer wants?
- How can we recognize that we're making progress toward delivering what the customer wants on budget and on schedule?
By the way, the common objections by some in the agile community to the notion of on-budget, on-schedule as a measure of project performance is seriously misinformed. Those paying for the project not only want to know these, they must know this. It's not the developers money. It's the customers money. They must know the final cost and the date when the project is done. They must also - of course - know that what is being produced delivers the needed capabilities. But having those capabilities late is not good. Spending much more than budgeted is not good. All three attributes are needed.
These numbers by the way are probabilistic. Every number on a project is drawn from a statistical process to produce a probabilistic outcome. The notion that NOT forecasting the future performance of cost, schedule, and technical outcomes can't be done is simply nonsense. Of course it can be done. You just have to remember the things you learned in your high school statistics class. Plus a few other things about probability distributions and confidence levels.
