This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
Sunday, February 15, 2004
Promises and Prescriptions Part 1 - Introduction -- Projects--including software projects--are about promises.
Projects are about turning uncertain work efforts into reasonably certain outcomes. Project sponsors, customers, and stakeholders rely on project promises to carry out and coordinate larger strategies in support of organizational needs. Yet, making and keeping those promises are hindered by common problems: people on projects are reluctant to promise the unknown, plans are disrupted by rework, and schedules are thwarted by contention for resources that are involved with more than one effort.
In his classic business novel, The Goal, Eliyahu Goldratt introduced an approach to managing complex systems known as the Theory of Constraints (TOC). While Goldratt's novel revolves around a manufacturing plant, he offered management prescriptions that can help software projects as well. Later, he refined the application of TOC to the domain of project management with Critical Chain Project Management (CCPM). In this article, I'll offer you prescriptions from CCPM to help deal with common problems encountered in software projects. While there's much more to TOC and CCPM, these prescriptions will help improve project performance even if you don't pursue the full solution.
Within software projects, there are three common complaints. One is rework. Work efforts are designed in a highly intricate, interactive, and interdependent domain. Touching one piece of a work product can impact other pieces, frequently requiring rework of what was thought to have been completed. In addition to missed or misunderstood interdependencies, time pressures that compromise quality, uncontrolled changes in requirements, and miscommunication all contribute unexpected work and tend to extend the timeframe upon which the project promise is based.
Second, software efforts often exist in mixed- and multi-project environments. A limited pool of people and resources are assigned to mixed responsibilities, such as development and maintenance--or are shared across multiple concurrent projects. The resulting conflicts of priorities are a major source of difficulty in promising and delivering projects.
The third issue is a culmination of the first two, plus impacts of project work in an uncertain environment. Projects are about promises--necessary promises that help an organization to manage its future. The fear of promising the unknown results in either irrational promises that stress out those tasked with delivery, or unresolved promises that stress out those who must run the business or sell the product the project is intended to support.
(Watch for the thesethreeissues (and prescriptions for dealing with them) in future installments of this article, originally published in Better Software magazine.)
View Frank Patrick's profile
