When you have a plan to accomplish something, how to do know if that plan is a GOOD or BAD plan?
Is the plan good if it presented in an aesthetically pleasing manner? Is a plan good if people understand it? Is a plan good, perhaps, if some people do NOT understand it? What do you employ as a plan measuring stick?
In fairness, I would say a plan is typically considered to be good when reviewers of the plan feel that it addresses all necessary aspects of the project or effort and has tasks scheduled in such a way such that it seems the steps of the plan will reasonably get completed as specified. In other words, it holds up to pressure testing by stakeholders.
This said, however, this measurement would rely on many assumptions.The most important assumption is that you and the stakeholders understand all of the “necessary aspects” of the project. One way to foster understanding is to compare your project tasks to the tasks of previous projects. This, of course, is only possible if these artifacts for comparison exist and you know the degree of similarity.
Can you really ever know how good a plan is?
When it comes to knowledge projects, such as software development, I assert that nobody really knows if a plan is good or bad. You only know if something is done and works once it is complete.
Completing work comes through solid execution. In fact, this is partially supported by 3 of the 4 phrases in the agile manifesto (and remember while we value the left part of these phrases more, there is still value on the right as well):
- Working software over comprehensive documentation: In other words, focus more on the software, not the surrounding documentation,which includes your plan.
- Customer collaboration over contract negotiation: Spend energy on working directly with the customer rather than negotiating, among other things, a “plan.”
- Responding to change over following a plan: Put more effort into dealing with what to do when you learn new things through execution rather than blindly following a plan that has probably been out of date since a day after it was created.
Also note the seventh principle behind the agile manifesto: Working software is the primary measure of progress. In other words, pointing to where a team may be on a plan is often an arbitrary measure of progress. Working software that results from execution, on the other hand, does not lie!
Additionally, SAFe Principles support focusing on execution as well.
- Assume variability, preserve options: This supports not spending lots of time on a static plan, and instead leveraging the plan to support variability and some uncertainty.
- Build incrementally with fast, integrated learning cycles: The key is to “build” not “plan.” Foster real learning based on what you have built and not some arbitrary measurement of where you stand against your plan.
- Base milestones on the objective evaluation of working systems: This approach will give you a great sense of where you really stand based upon the product in front of you along with what works and what does not work, as opposed to subjectively measuring only against a plan.
Setting aside all of the observations above, how do you feel when you have to give a “percent complete” measurement based on a work in progress?
I personally do not like that. If the work is broken down into small pieces which can each be complete or incomplete and a percentage is derived from this, I feel much more confident in giving a percentage value measurement. This, again, is accomplished through executing completion of the fully functional artifacts.
With that in mind, check back for part two of this post, where I will give some steps you can follow to focus on execution.
