Project Management Isn’t Rocket Science, Or is It?

According to any number of surveys, the majority of information technology projects fail to meet their goals of cost, schedule and functionally. We discussed one reason in the Links column entitled “Why IT Projects Fail: Lack of User Involvement” on August 8.

by Dr. Gerald Hoffman ePrarie.com

That was a pleasant discussion for IT professionals because we could blame the other guys – the users – even though there are other causes of project failure, many of which are within the control of IT. One cause of project failure is bad project management.

Project management is hard. It isn’t rocket science, although the formal discipline of project management as we know it today began as a tool necessary to make rocket science effective in the space program.

If you view project management from a purely technical perspective, it looks easy. There are only a few core ideas, each of which is conceptually quite simple and can be learned in a matter of hours. They include:

The idea of “project” as an activity with a beginning, a middle and an end.
The idea of breaking up a large project into a set of smaller and independent tasks.
The idea of defining the relationships among the tasks in terms of precedence, which tasks must be completed before others can be started and the description of theses relationships by means of critical path diagrams.
The twin concepts of milestones and deliverables, allowing project managers to track and assess the progress of a project.

Still, 75 percent of all IT projects fail. Why? There are two basic reasons: untrained project managers and lack of historical data about costs and levels of effort.

The transition from line worker to first-level supervisor is the most difficult transition in nearly everyone’s career. Still, organizations continue to do dumb things such as promoting the best salesperson to be sales manager, the best assembly line worker to be the line supervisor, and (sad to say) the best programmer to be project manager – all without much thought about what the person really needs to know in order to be an effective manager.

The unspoken assumption seems to be that if you understand the technology and the process as a result of having worked in it, you can manage others executing the process.

Of course a project manager needs to understand project management, the concepts listed above and others related to them, as well as what project management software can do and what it cannot do, but the manager also needs to understand how to supervise people, how to motivate them and how to lead them.

A manager must know how to form teams and encourage teamwork, how to estimate costs and schedules, and must face the hard realities of missed milestones and deliverables that don’t quite deliver what was promised.

Most of all, a manager must understand how to manage change because change is what any project (IT or other) is all about. The changes a manager must manage are largely among people and organizations where the manager is an outsider with no line authority to make things happen. In brief, the manager must be a manager.

Give your new project managers training in basic supervisory skills first (preferably not from a project management point of view). Let them learn the general principles of people management, leadership and motivation, change management and the “sales skills” necessary to deal with the user community. Then teach them project management and its associated concepts and techniques.

The most skilled project manager in the world is at the mercy of the cost and schedule estimates that are made at the beginning of the project, and these are notoriously inaccurate.

Much research has been done on methods of estimating costs of IT projects, and the bottom line seems to be this hardly surprising conclusion: the best way to estimate the cost of a proposed project is to compare it with the cost of a similar project done in the same organization. Problem is, most organizations have no useful historical records of costs of IT projects, so project managers are forced to rely on their own experiences, which may be very limited.

The short-term answer is to appoint a project manager with lots of experience in projects similar to the one at hand and with excellent memories. The longer-term solution is to begin to collect cost and schedule data on projects as they are finished and make that data available for future use.

This is not easy because it requires a lot of self-examination – not all of which is pleasant. For instance, collect data about costs from actual time sheets, not just the data from the project plan. As anyone who has attempted to do function-point analysis will tell you, this is not easy to do, but it is essential to long-term success.

A competent project manager and a good historical database will go a long way toward making any project a success. Lack of these two essential elements is a prescription for failure.

Dr. Gerald Hoffman is a consultant, educator, author and all-around nice guy. With expertise in the management of information technology, he works to help organizations garner value from their information technology investments. An adjunct professor at Northwestern University, Hoffman has worked with numerous companies on their information technology management issues and has participated on a number of boards. Feel free to visit his Web site or e-mail him at [email protected].

Copyright 2002 Gerald Hoffman Company, Inc.

http://eprairie.com/news/viewnews.asp?newsletterID=4105