On the Agile Project Management Forum (APM) there's several threads about agile development and agile project management. Actually very little about agile project management, even though the forum is about agile project management. But that's another story.
What's fundamentally missing in the conversation is the concept of differences between:
- Planning and Scheduling.
- Between "knowing" about the future and making decisions based on a "model" of the future.
- Between deterministic processes and probabilistic processes
Now not everyone shares my interest in these topics. But our clients do. The US Government does. And most enterprise class project sponsors do. Here's why.
Planning Versus Scheduling
A Plan is the strategy for the successful completion of the project. It's a description of the project steps that produce increasing maturity of the products or processes produced by the project. Like all plans it makes use of feedback to "test the strategy." Strategy testing is very akin to hypothesis testing. You need some form of measurement, with units of measure agreed up front, that can be used to guide the plan along the various hills and dales that the project will take while it is being executed.
Planning is a creative process usually managed by a Program or Project Manager (or the Planner working for the PM) and the participants in the project. These participants - the subject matter experts - have some idea of what "done" looks like. Or at least they know who to ask what "done" looks like.
Scheduling is the identification of the work needed to deliver the product or process defined in the plan. A schedule is usually a list is tasks, the order of execution of those task - the dependencies - some estimate of the duration of that work. All arranged in a logical manner so those doing the work have some idea of what to do next.
Now it's not always necessary to state explicitly "what to do next." This is why there are various granularities to a schedule. A Master Schedule might show the major sequence of the project.
- Identify the system components
- Assign the various development organizations to build those components in what ever way works for them
- Integrate these components in some test environment
- Put the results product or service to work
This "Begin, Do All Work, End" process works well for engineering like projects. Things like airplanes, highways, tall buildings, and even software projects. Not all software projects, but many software projects. Software projects where those building the software number in the 100's or maybe 1,000's. Smaller teams can have other processes that skip some of the steps needed for larger projects.
This BTW is the crux of the debate over agile.
- Can agile build the air traffic control system?
- Can agile install SAP at 52 sites with cold cut over every first Monday of the month for several years?
Good questions. No definitive answers that I know of. Answers beyond the anecdotal approaches found in many agile forums.
Knowing the Future and Modeling the Future
Many confuse "knowledge of the future" with a "model of the future." They confuse these because they make the assumption - which might be correct - that "knowledge of the future is not perfect." Missing the idea that imperfect knowledge is used to make decisions all the time. From the weather to the stock market.
But decisions still need to be made in the presence of uncertainty. Managing in the presence of uncertainty is what Project Manager do for a living. Having a model that contains descriptions of this imperfect future, in some probabilistic way, is not only useful it is the way project manager work. At least projects managers that understand the difference between deterministic and probabilistic.
Probabilistic models are the bread and butter of large project management process. Monte Carlo Simulations (MCS) are the tools used to model the probabilistic aspects of the project. Cost, Schedule and even Technical Performance Measures. The technical models are similar to P-Charts found in statistical process control. Probabilistic cost and schedule models use probability distributions for duration or cost. The correlations between the elements of cost and schedule are then developed and the MCS run to see "what happen when these probabilities occur."
Railing against the failings of deterministic models is not only naive, silly, it is simply bad Project Management. Stop doing bad project management and project performance will improve. It's really that simple.
Yes other project management methods can help. Earned Schedule, Lean Construction, Integrated Project Teams, and maybe even agile software development. But Agile Software Development is not Project Management, its software development. Software development may be the project at times. And if it is, then the process of agile software development work - when the preconditions are in place.
But software development is many times just one of dozens of other processes in a project. The issue comes when the agile software development advocates confuse their practices with the practices of project management. This is not a problem for project managers. But it is a problem for the many of the business people sponsoring projects. The "next thing" of eXterme Programming and in some cases Scrum is sometimes substituted for project management. This is not a wise choice in the absence of the experience of successfully doing it.
What's Next
If the term Agile Project Management is to have any meaning outside the narrow domain of software development, it needs to have a basis of discussion.
- What are project management processes?
- How can these processes be identified for specific domains and contexts?
- What are the success criteria for applying a process in a specific context or domain?
