Strangely, I am enjoying this course. Not only does it give me a soapbox to pontificate on the dos and don'ts — and I do — but I have finally begun to master many of the mechanics of project management (when I was running projects in the past, it was alas mostly improvised). In addition, through terrific guest speakers and published case studies, I have a better perspective on what good project management really is — and on why a remarkable number of systems projects, sadly, are perceived as "failures."

First, a few numbers. In a recent study of systems projects, the Standish Group has reported the success rate (on time, on budget and delivering the functionality that was promised) was only 16.2 percent, while a whopping 31.1 percent of the projects launched are cancelled [1]. A story in the Economist reported that 85 percent of public sector IT projects do not succeed [2]. A Gartner Group study revealed that more than 50 percent of customer relationship management projects are viewed as failures [3]. [Note: I would welcome similar O.R.-focused data from anyone who has studied it or seen data elsewhere.]

I would suggest that one way to raise these rates is to make the denominator smaller and to address the alignment of different objectives sooner rather than later. Perhaps the reason so many projects are viewed as failures is because there is no common definition of success.

Consider an O.R.-based systems project from the perspective of the organization that is receiving it. There are at least four constituencies that have a voice in defining a project's "success":

• The executive sponsor: This is the person who "owns" the budget that is responsible for the costs of the project. He or she is focused on visible business results that can assure peers and superiors that this project was a "worthwhile investment." In addition, in a world where strategies, operations and competitive landscapes change faster than ever, the worthiness of a project for the sponsor is measured not only in terms of the traditional ROI but also in how well it enables the company or group to progress in its desired direction — which may be different at the end of the project than at the beginning!

• The project manager: This person has the responsibility for coordinating all of the players and activities on a day-to-day basis, and also for communicating progress and results to the executive sponsor. The perception of this project has a direct reflection on the PM. It can improve career prospects, or torpedo them.

• The IT organization and its leadership: O.R. projects required input data, often on a regular basis, and quite often produce output data that is to be delivered to different people through various systems. The IT organization, which is constantly under pressure to keep all existing systems up and running while building and innovating as best it can while adhering to its ever-more-scrutinized budget, wants as much predictability as possible about how much a project is going to require of it. Its leadership is quite risk averse — it has the scars from past "adventures" — and it will judge the project based on the level of disruption that the IT group experiences. Panicked calls for more resources, beepers going off at midnight and embarrassing executive encounters are all bad things!

• The users: This group does not respond much to explanations about theory or technology, high-level descriptions of a project's virtue or lectures about how it fits into some grand plan. This often-overlooked but often-powerful constituency cares primarily about one key question: "Is my job really easier as a result of this system?" The rest is mostly noise.

This is why making projects "successful" is hard.

Frances T. Hartmann is a veteran project manager and professor at the University of Calgary. In his book "Don't Park Your Brain Outside," he exhorts project managers to spend the time early to get different constituencies to articulate what is being done, why it is being done, and what the goals actually are. Such discussions are often simply overlooked or ignored, for such talks are typically uncomfortable and risky, and invariably require real leadership from the PM to navigate through. Sometimes the outcome is uncertain; most of the time the personalities are challenging; and often there is no agreement at all, either at the beginning or at the end.

All the more reason to do this up front, before significant resources have been spent on the project. As Hartmann points out, "If we cannot get the stakeholders to agree on what success is at the outset, what hope do we have of getting them to agree at the end?"

Sure, this definition may change over the course of the project, but getting some level agreement up front is one of the most important things that a PM can do. And it never shows up on the Gantt Chart.



Vijay Mehrotra (vjm@sfsu.edu) is a faculty member in the Decisions Sciences Group in the College of Business at San Francisco State University, and an operations management consultant.

References

1. www.standishgroup.com
2. As reported in: Klastorin, Ted, "Project Management: Tools and Trade-Offs," John Wiley and Sons, 2004.
3. As reported by: Bednarz, Ann, Network World, Sept. 17, 2001, p. 14.

Table of Contents

OR/MS Today Home Page


OR/MS Today copyright © 2005 by the Institute for Operations Research and the Management Sciences. All rights reserved.


Lionheart Publishing, Inc.
506 Roswell Rd., Suite 220, Marietta, GA 30060 USA
Phone: 770-431-0867 | Fax: 770-432-6969
E-mail: lpi@lionhrtpub.com
URL: http://www.lionhrtpub.com


Web Site © Copyright 2005 by Lionheart Publishing, Inc. All rights reserved.