The old saw of Plan the Work, then Work the Plan is at the heart of the success of any non-trivial project. The core concepts go like this:
- If we don't know what done looks like, how will we recognize it when it arrives?
- If we claim to be making progress, what are the units of measure of this progress?
- Are these units of measure meaningful to the participants, especially the customer?
- When there are changes, how will we know what the impacts are to the plan?
But there is a body of voices out there equating Planning with waterfall process. The common one is the Agile Manifesto
Responding to Change Over Following the Plan
A quick look reveals the fundamental flaw in this notion. The Plan is the Strategy for the successful completion of the project. With no Plan you have no Strategy. With no Strategy, you have no guidance on how to respond to change. You driven by the "winds of change." The first result of responding to change in the absence of a plan, is you can only know you've arrived at Done, when the money runs out or the date for the product's shipment arrives. Usually not an acceptable option for those funding the project.
What Does Done Look Like?
I've used this phrase since 2002. It was first used by Martin Radley who was a Project Manager in our Program Office at Rocky Flats. Martin's other phrase was what does "Done Done" look like?
If we don't have a definitive description of what Done looks like, it's going to be difficult to determine what work needs to be done and in what order it is to be performed. The description of Done at the highest level is usually some capability needed by the customer to fulfill the business plan or assigned mission:
- Process claims transactions for $0.07 each after 60 days of operations
- Dock at the International Space Station with 4 crew members on board
How Do We Measure Progress?
With a description of what Done looks like, we can decompose this into small descriptions of Done. This decomposition can go down to a granularity needed to manage the project. For Scrum projects this is an iteration and the work efforts in the stories. For larger programs this is the Work Packages and the Rolling Waves that implement those Work Packages, along with the Planning Packages for future "emerging" work.
By The Way, in the space and defense world Work Packages typically have duration of less that 60 calendar days or 45 work days. Just a little bit longer than iterations in Scrum.
What is the Unit of Measure of Progress?
This measure of progress must be units of Physical Percent Complete. Tangible evidence that what was planned to be completed was actually completed in the ti me frame planned for the allocated budget.
Managing in the Presence of Change
Trying to control or restrict change is not a method for success. Change happens. It is unavoidable.
In many domains encouraging change is not the preferred approach. In other domains accepting change is part of the process of reaching the end. Domain and context are needed before any discussion can be had about how to manage in the presence of change.
No matter the domain and context, change happens and you must manage the project in the presence of this change. The core process for doing this is to determine what the impact of the change is, how to moves the project forward, backward, or sideways. What to the change cost in terms of money, time, risk, value to the customer.
Answering these questions is the role of the change management process - no matter what method you are using to develop the product or service.
In the End
- Plan the Work - state what done looks like in some meaningful way
- Work the Plan - perform the work, measure progress, make the appropriate adjustments
- Continuously Manage Risk - during all steps, the management of risk is how adults manage projects
