Project management style is a significant determinant separating successful projects from failures. Contrary to conventional wisdom, steering leadership is better than detailed plan-and-track leadership.
Successful Software Management Style: Steering and Balance
Walker Royce, IBM Software Group
oftware project managers are more likely to succeed ifthey use techniques that are more like managing a movie production than an engineering production. “Heresy!” some might shout. “Software projects need more disciplined engineering management, not less.” Before you dismiss my claim as an insult to the profession, consider these observations (a related discussion appears elsewhere1):
Most software professionals have no laws of physics or propertiesof materials to constrain their problems or solutions. They are bound only by human imagination, economic constraints, and platform performance. (Some embedded-software developers are an occasional exception.) In a software project, you can change almost anything at any time: plans, people, funding, milestones, requirements, designs, and tests. Requirements—probably the most misused word in ourindustry— rarely describe anything that is truly required. Nearly everything is negotiable. Metrics and measures for software products have no atomic units and are highly subjective. Economic performance more typical in service industries (measured by a user’s perceived value rather than the cost of production) has proven to be the best measure of success for software. These observations probablysound countercultural to project managers who use engineering mindsets to produce airplanes, bridges, heart transplant valves, nuclear reactors, skyscrapers, and satellites (unless these projects include significant software content or are firstof-a-kind systems). However, they do apply to movie producers—professionals who regularly create a unique and complex web of intellectual property limitedonly by vision and creativity. I prefer to describe software management as a discipline of software economics rather than software engineering. Software projects are rarely concerned with established and mature engineering tenets. Rather, a software manager’s day-to-day decisions (like those of movie producers) are dominated by value judgments, cost trade-offs, human factors, macro-economic trends,technology trends, market strength, and timing. To deal with these more subjective decisions, I recommend using a steering leadership
Published by the IEEE Computer Society
0740-7459/05/$20.00 © 2005 IEEE
style that comprises active management involvement and frequent course correction.
■ ■ ■
An iterative approach The economic performance of softwareprojects is difficult to capture in one simple metric, but in the last five years, approximately one in three has delivered on budget and on schedule with any sort of predictability.2 I suspect the economic performance of movie productions looks pretty similar. Traditional project management approaches in software-intensive projects don’t encourage the steering and adjustment needed to reconcilesignificant levels of uncertainty in the
■ ■ ■
Elaboration. Synthesize, demonstrate, and assess an architecture baseline. Construction. Develop, demonstrate, and assess useful increments. Transition. Assess usability and produce and deploy product.
problem space (what the user really wants or needs), solution space (what architecture and technology mix is most appropriate), and planning space(including cost and time constraints, team composition and productivity, stakeholder communication, and incremental result sequences).
We need a more dynamic and adaptive way of thinking about software progress and quality management, one that accommodates patterns of successful projects. Today’s modern software management approaches are generally known as iterative development methods.3–5...