If you are planning for a year, sow rice; if you are planning for a decade, plant trees; if you are planning for a lifetime, educate people - What the heck is planning? - II
In the post, a little bit of background or what planning is normally taken as was covered, now we get into the nitty gritty of what was really meant by reducing risk, reducing uncertainty, supporting better decision making, establishing trust and conveying information.
Reducing Risk
Planning increases the likelihood of project success by providing insights into the project’s risks. Some projects are so risky that we may choose not to start once we’ve learned about the risks. Other projects may contain features whose risks can be contained by early attention. The discussions that occur while estimating raise questions that expose potential dark corners of a project. For example, suppose you are asked to estimate how long it will take to integrate the new project with an existing mainframe legacy system that you know nothing about. This will expose the integration features as a potential risk. The project team can opt to eliminate the risk right then by spending time learning about the legacy system. Or the risk can be noted and the estimate for the work either made larger or expressed as a range to account for the greater uncertainty and risk. I remember sitting for hours and hours in such meetings where the potential risks and gaps were discussed in the company I used to work for, at the initiation of such meetings, this was merely taken as an overhead, a waste of time etc but as time flew by and the participants matured, such meetings were a God send oppurtunity to fine tune everything!
Reducing Uncertainty
Throughout a project, the team is generating new capabilities in the product. They are also generating new knowledge -- about the product, the technologies in use, and themselves as a team. It is critical that this new knowledge be acknowledged and factored into an iterative planning process that is designed to help a team refine their vision of the product. The most critical risk facing most projects is the risk of developing the wrong product. Yet, this risk is entirely ignored on most projects.
An agile approach to planning can dramatically reduce (and hopefully eliminate) this risk. (a clever teaser which hints of what is to come in some future blog :P)
Supporting Better Decision Making
Estimates and plans help us make decisions. How does an organization decide if a particular project is worth doing if it does not have estimates of the value and the cost of the project? Beyond decisions about whether or not to start a project, estimates help us make sure we are working on the most valuable projects possible. Suppose an organization is considering two projects, one is estimated to make $1 million and the second is estimated to make $2 million. First, the organization needs schedule and cost estimates in order to determine if these projects are worth pursuing. Will the projects take so long that they miss a market window? Will the projects cost more than they’ll make? Second, the organization needs estimates and a plan so that they can decide which to pursue. The company may be able to pursue one project, both projects, or neither if the costs are too high.
Establishing Trust
Frequent reliable delivery of promised features builds trust between the developers
of a product and the customers of that product. Reliable estimates enable reliable
delivery. A customer needs estimates in order to make important prioritization and tradeoff decisions. Estimates also help a customer decide how much of a feature to develop. Rather than investing twenty days and getting everything, perhaps ten days of effort will yield 80% of the benefit. Customers are reluctant to make these types of tradeoff decisions early in a project unless the developers’ estimates have proven trustworthy.
Conveying Information
A plan conveys expectations and describes one possibility of what may come to pass over the course of a project. A plan does not guarantee an exact set of features on an exact date at a specified cost. A plan does, however, communicate and establish a set of baseline expectations. Far too often a plan is reduced to a single date and all of the assumptions and expectations that led to that date are forgotten.
Suppose you ask me when a project will be done. I tell you seven months but provide no explanation of how I arrived at that duration. You should be skeptical of my estimate. Without additional information you have no way of determining whether I’ve thought about the question sufficiently or whether my estimate is realistic.
Suppose, instead, that I provide you with a plan that estimates completion in seven to nine months, shows what work will be completed in the first one or two months, documents key assumptions, and establishes an approach for how we’ll collaboratively measure progress. In this case you can look at my plan and draw conclusions about the confidence you should have in it.
A little humor that caught my attention whilst reading a blog;
Reducing Risk
Planning increases the likelihood of project success by providing insights into the project’s risks. Some projects are so risky that we may choose not to start once we’ve learned about the risks. Other projects may contain features whose risks can be contained by early attention. The discussions that occur while estimating raise questions that expose potential dark corners of a project. For example, suppose you are asked to estimate how long it will take to integrate the new project with an existing mainframe legacy system that you know nothing about. This will expose the integration features as a potential risk. The project team can opt to eliminate the risk right then by spending time learning about the legacy system. Or the risk can be noted and the estimate for the work either made larger or expressed as a range to account for the greater uncertainty and risk. I remember sitting for hours and hours in such meetings where the potential risks and gaps were discussed in the company I used to work for, at the initiation of such meetings, this was merely taken as an overhead, a waste of time etc but as time flew by and the participants matured, such meetings were a God send oppurtunity to fine tune everything!
Reducing Uncertainty
Throughout a project, the team is generating new capabilities in the product. They are also generating new knowledge -- about the product, the technologies in use, and themselves as a team. It is critical that this new knowledge be acknowledged and factored into an iterative planning process that is designed to help a team refine their vision of the product. The most critical risk facing most projects is the risk of developing the wrong product. Yet, this risk is entirely ignored on most projects.
An agile approach to planning can dramatically reduce (and hopefully eliminate) this risk. (a clever teaser which hints of what is to come in some future blog :P)
Supporting Better Decision Making
Estimates and plans help us make decisions. How does an organization decide if a particular project is worth doing if it does not have estimates of the value and the cost of the project? Beyond decisions about whether or not to start a project, estimates help us make sure we are working on the most valuable projects possible. Suppose an organization is considering two projects, one is estimated to make $1 million and the second is estimated to make $2 million. First, the organization needs schedule and cost estimates in order to determine if these projects are worth pursuing. Will the projects take so long that they miss a market window? Will the projects cost more than they’ll make? Second, the organization needs estimates and a plan so that they can decide which to pursue. The company may be able to pursue one project, both projects, or neither if the costs are too high.
Establishing Trust
Frequent reliable delivery of promised features builds trust between the developers
of a product and the customers of that product. Reliable estimates enable reliable
delivery. A customer needs estimates in order to make important prioritization and tradeoff decisions. Estimates also help a customer decide how much of a feature to develop. Rather than investing twenty days and getting everything, perhaps ten days of effort will yield 80% of the benefit. Customers are reluctant to make these types of tradeoff decisions early in a project unless the developers’ estimates have proven trustworthy.
Conveying Information
A plan conveys expectations and describes one possibility of what may come to pass over the course of a project. A plan does not guarantee an exact set of features on an exact date at a specified cost. A plan does, however, communicate and establish a set of baseline expectations. Far too often a plan is reduced to a single date and all of the assumptions and expectations that led to that date are forgotten.
Suppose you ask me when a project will be done. I tell you seven months but provide no explanation of how I arrived at that duration. You should be skeptical of my estimate. Without additional information you have no way of determining whether I’ve thought about the question sufficiently or whether my estimate is realistic.
Suppose, instead, that I provide you with a plan that estimates completion in seven to nine months, shows what work will be completed in the first one or two months, documents key assumptions, and establishes an approach for how we’ll collaboratively measure progress. In this case you can look at my plan and draw conclusions about the confidence you should have in it.
A little humor that caught my attention whilst reading a blog;
So, this concludes the second part of "...what the heck is planning?" (more to come soon between more posts and stuff)
It is imperative that we read blog post very carefully. I am already done it and find that this post is really amazing.
ReplyDeleterice prioritization