Plans are meant to be changed. Otherwise it wouldn't be a Plan. Plans are Strategies for the successful completion of the Project.
A Strategy is a hypothesis that needs to be tested. This test is the feedback received from the execution of the project, the gathering of the Measures of Effectiveness (MoE), the Measures of Performance (MoP), the Critical Success Factors (CSF), the Key Performance Indicators (KPI), and the Technical Performance Indicators (TPM).
These measures provide visibility into how our Strategy is working. These measures provide feedback needed to take corrective actions for the Strategy.
Once we have the Strategy and have the means of testing the hypothesis, we can produce a Schedule that implements the Plan - the steps needed to produce the deliverables in the Plan, in the order they are needed.
This schedule can be changed as well. It has to be changed. It can't stay fixed for the simple reason that the tests being performed against the Plan produce new information. Steering Information for the strategy.
Buyt this steering information needs to come from the predefined MoE, MoP, CSF, KPI, amd TPMs. Sure there is new input that is received from the external domain. But that external input needs to find a home in the existing Plan based and Schedule guided framework.
No making things up as you go
You can certainly use the agile approach of capturing all this input through planning and confirmation processes. Putting sticky note on the wall or entering the items in an Agile software management tool. But in the end you need to answer those 5 pesky Immutable questions:
- Where are we going? - the Plan tells us that
- How do we get there? - the Schedule tells us that
- Do we have enough of everything we need? - the resource loaded schedule and any other external dependencies tells us that
- What are the impediments along the way? - the Risk Management Plan tells us that.
- How are we measuring progress to plan? - Earned Value, or any measure of physical percent complete that ensures compliance with all the measures - MoE, MoP, CSF, KPI, and TPMs.
Yes that last items says compliance. Compliance within the upper and lower limits of the metric at the time of measurement. Without this measurement the project is in fact self guided, going where ever those watching the project see emerging toward
Along with these is the other pesky item - change control. Anyone who tells you we don't need change control has never managed an "emerging" project. Changes cost money. Changes impact schedule. Changes impact this that have already been done. Dried concrete, released databases, User Interfaces that have the training manuals already written.
So with those 5 immutable principles, all the stakeholders still need to know a few more things:
- When will this project be done?
- How much will it cost when we are done?
- How do we know the stakeholders will be happy, or as happy as they could possibly be?
