Project management 101

Heard much about project management lately? Probably so. Thanks largely to the efforts of Mark Forman of the Office of Management and Budget and Ira Hobbs of the CIO Council, the issue of project management has been placed on the front burner for everybody who cares about information technology's ability to deliver successful results for the government.

I recently read J. Davidson Frame's "Managing Projects in Organizations," which is a book that would serve as a great primer for government workers getting initiated into project management. Frame, a professor and consultant from the Washington, D.C., area, states that the management of people, requirements and risks lays the foundation of project management. The book will be of obvious interest to government people managing vendor IT systems efforts and also to those managing projects inside the government.

Consistent with the government's tendency to emphasize technical fixes over organizational and leadership issues, government project management training often highlights work breakdown structures, critical paths and budgeted cost of work performed. Frame leaves that discussion for the very end of his book.

Frame reminds us that when we think of projects, we need to think of the risks associated, because projects are unique. A lack of experience with a project inherently accompanies the project's uniqueness, which creates risk.

Lack of experience is one reason government officials contract IT systems projects to vendors that have had more experience with developing such projects.

The basic principle of risk management, Frame suggests, is management by exception. There will always be variances between planned and actual cost, schedule and performance. The key is to establish tolerable limits and to pay attention to variances outside that range.

Frame devotes a good deal of attention to the upfront effort required to determine customer needs and translate them into requirements. Most projects fail, he argues, because of problems with requirements set at the beginning of the projects.

The danger is that the project will end up delivering something different from what customers wanted and/or expected.

Frame discusses a number of the pitfalls involved in getting customers to articulate their needs and translate them into requirements. He makes a number of practical suggestions, such as simply asking staff members to present their interpretation of the requirement once it has been put on paper to see if the language is subject to multiple interpretations.

In a sense, it is comforting to learn that the private sector — the context for Frame's book — faces the same issues here as the government.

Vacation reading, anyone?

Kelman is a professor of public management at Harvard University's Kennedy School and former administrator of the Office of Federal Procurement Policy. He can be reached at steve_kelman@harvard.edu.