This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Thursday, October 09, 2003
Promises, Predictions, and Planning -- Projects are about promises. Project management is an effort to make, manage, and keep promises about scope, quality, schedule and cost of efforts deemed worth pursuing. While Deming said, "Management is prediction," pinpoint prediction cannot be expected and to strive for it is a futile waste of time. However, reasonably reliable expectations of when a user or an organization will have a specifically defined product, process, system, feature, or fix to support its efforts must be expected and provided by those tasked to deliver them.
Like many partial efforts that are too often described as projects, "software projects" rarely, if ever, stand alone. At best, they are most often components of larger initiatives, delivering either products to be sold or changes in business processes aimed at more effective operations and better profits. As such, the real promises associated with them are those that are tied to the bottom line impact of the effort. (Too often there is too strong an organizational border between things like R&D or IT and other components of the larger projects, but that's a strategic discussion for another time.) The component projects exist to serve the larger effort, which exists to serve the strategies and goals of the parent organization, which need to make and keep promises to satisfy key stakeholders.
In recent examples of high-profile failures of major companies to keep their promises (and of the Sarbanes-Oxley response), it is incumbent on management to demand reasonable and reliable promises regarding the efforts under their charge. Otherwise, they won’t be able to make or keep appropriate promises to the customers and shareholders who foot the bill. It's not good enough to leave critical aspects of project promises too open-ended or too open to compromise. While details along the way are, of course, subject to modification and tweaking along the way, the larger efforts' significant objectives, deliverables, and success criteria need to be kept at the top of the mind of those involved, and the promises associated with them must be kept unless and until rational decisions otherwise are made.
How the objectives are delivered may be subject to considerable learning along the way, but the basics of what will be delivered, in terms of functionality related to bottom-line impact, needs to be a relatively constant pole star for the project. If delivered functionality deviates too much from desired functionality, then the project's success is called into question. One way of avoiding this is to manage the big-picture effort, not just the component part, as the project. A new product development effort is not just and R&D/Engineering design effort, but a manufacturing, distribution, marketing, and sales effort as well. Implementation of a business system is not just a software project, but a process design, training, customer preparation, and roll-out effort as well. By doing this, the day-to-day interactions between suppliers and customers (both internal and external to the project) are formally included in the planning that goes on not only at the start of the effort, but also in the replanning that goes on daily during the execution of well-managed, high-performance projects.
Such projects need the close interaction of all these internal customers throughout the project. To accomplish this, project planning needs to move away from the oft-recommended hierarchical WBS viewpoint of the project to the interdependent view of a dependency network as soon as possible. The project level emphasis on the components of the components that are encouraged by detailed WBS views takes too much time for too little benefit, and tends to isolate the projects internal customers and suppliers. More important for an efficient planning process -- and an efficient, effective plan -- is to get out of the details of components and into the higher level details of the interdependencies between the project's component efforts and resource groups. The time wasted on detailing what goes on within a component effort or within one set of resources or another is time that is more productively spent on understanding what needs to pass between them.
If there is any chance of reasonably predicting the outcome of a complex effort, the identification of major dependencies is far more important than the futile attempt to identify unidentifiable details of work in particular components. To this end, for planning, the linear list and hierarchical outline-dominated Gantt Chart view (too often presented by project management software as the default view) should be avoided. It should be replaced by a dependency-centric network view of the understanding of the project that combines the boxes (the work) and arrows (outputs/handoffs/inputs/deliverables of that work) of the effort. Or even better, it can be replaced by a view dominated by post-its or cards. In either case, it is put together by those who will do the work or by their trusted representatives, typically facilitated by a project manager.
Once the objectives, the major chunks of work required, and their interdependencies are understood, the time and cost aspects of prediction and promise can be addressed. But to address them effectively and efficiently, sufficient respect for uncertainty and unknowns must be paid. The idea of "accurate estimates," over which too much time, effort, and angst is too often spent in project planning, needs to be set aside. It must be replaced with a brief conversation about how long (in time or iterations) something might take and how short it could take if good luck and good work practices come together. The former needs to respect the fact that Murphy's Law has not yet been repealed and that there are non-trivial unknowns at the time of planning. The latter highlights what management practices and additional predecessor pieces of the project would benefit delivery speed. The difference between the two is the time value of doing what is necessary to make the shorter time more likely.
From a planning efficiency perspective, this two-point range estimate heads off a lot of unnecessary negotiation, CYA, and other political activity that is associated with "accurate estimates" or "estimates as commitments," and does little but strain the necessary teamwork and trust between the people involved. It does so by respecting the concerns of those who will do the work, and and by providing necessary understanding of the prediction to those for whom speed of delivery translates to more benefit.
And from an effectiveness perspective, it provides the basis for rational predictions and promises; expected not-to-exceed promises bounded by the upper limits of a range of reasonable prediction that is managed, refined and narrowed as the project effort learns more about itself.
posted by Frank - Permanent Link -