A project management information system (PMIS) can provide a framework to help guide the progress of IT projects. Here's how one company decided that a PMIS was needed to help increase project success rates.

By George Sifri| in Tech Decision Maker, October 7, 2008, 1:40 AM PST

Editor's note:This article was originally published on December 4, 2002.

We all know that accurate, timely, and relevant information is essential to the decision-making process of a project and that relying on an inadequate information system puts a project at risk. We all know that information is a valuable resource for project managers. Despite the fact that we all know these things, project managers often fail to deliver the types of information needed to ensure project success. Implementing a project management information system (PMIS) is one way to address critical project information needs.

One of my major clients, an international engineering firm, decided to break the cycle of miscommunication and derailed projects by ordering the development and implementation of a PMIS that is able to provide upper management with adequate information about all the projects in the organization's portfolio. Traditionally, engineers and project managers do not communicate project status adequately with upper management and functional departments; they believe that projects are their responsibility and they have the authority to deliver them. Furthermore, functional departments are often reluctant or do not have time to provide information to project engineers. These circumstances often lead to late, over budget, and low quality projects.

Symptoms of the problem

The following symptoms made us realize the necessity for implementing a PMIS:

• There was a loss of control through the systematic analysis of the information gathered.
• There was no system for integrating the time, cost, scope, and quality objectives.
• Projects were often late, over budget, and of low quality.
• To overcome the shortage in information, managers created project organizations within the corporate organization that led to duplication and waste of time, money, and effort.
• The inability of the project manager/team to accurately report the status of the project in terms of time, cost, and work remaining.

Here is the approach we decided to use for the progressive development of the PMIS:

• Identify what is needed.
• Compare the current situation with what is needed to achieve the aim of the PMIS set by upper management.
• Bridge the gap between what is needed and what was already in place.

Questions in search of answers

The symptoms we studied pointed to a number of questions:

• What information do we need in order to adequately plan, organize, and control our project?
• What information do we need to share with other stakeholders?
• What information do we need about other projects in the organization that interface with our project?
• What information do we need in order to coordinate our project's activities with other initiatives in the organization?
• What is the cost of not having accurate, timely, and relevant information about our project?
• What is the cost of having accurate, timely, and relevant information about our project?
• Is the available information suitable for decision making?
• Do we have too much data but not enough information?
• What value does the PMIS add to the project?

Improvement objectives

We agreed that the new system should meet improvement objectives for the project management process. This meant we needed to state the improvement objectives as early as possible so that we could define the requirements of the system in terms of these objectives and facilitate the system's acquisition process. We decided the improvement objectives for the new system should:

• Enable the project team to identify and isolate sources of significant variances and determine the reason why a project deviated from its plan.
• Allow the project team to track the status of the work packages in order to determine the work that is completed and the work that is still pending.
• Help the project team manage project schedules by providing the basis for work package resource allocation and work timing.
• Interface and be compatible with larger legacy information systems.
• Help the project team forecast the impact of certain risks on time, costs, and quality baselines.
• Give the project team insight into what revisions to the baselines they need to implement, when they should implement these revisions, and why they are implementing these revisions.
• Integrate with the work breakdown structure (WBS), which provides the capability to report the status of the work packages throughout the project's life cycle. These reports include identification of the work package, its associated cost code and schedule, and the individual responsible for the work.

Reengineering the project management process

We analyzed the existing management process and decided that it was inadequate for solving the business problem, or meeting the improvement objectives. Thus, significant changes were required. We had to spend a considerable amount of time developing and documenting the new process before going to the acquisition phase.

There was a wide gap between the information requirements we had identified and the existing project management processes and methods. Thus, we needed to develop a considerable number of project management procedures. We settled on eight categories of procedures. The following is a partial list of the procedures and their categories:

Procedures for project definition

• Preliminary estimate
• Preparation of technical specifications
• Startup review

Procedures for estimating and cost control

• Bottom-up estimate preparation
• Cost control
• Cost feedback

Procedures for scheduling

• Glossary of planning terminology
• Project milestones

Procedures for human resource management

• Coding procedure

Procedures for procurement management

• Selecting vendors
• Appraising vendors

Procedures for materials management

• Expediting
• Inventory control
• Inspections for quality assurance
• Vendor data

Procedures for documents management

• Numbering system
• Distribution profiles
• Filing structure

Procedures for integrating the proposed PMIS with other information systems

• Data dictionary

Conclusion

We have identified the need for the system, the symptoms of the problem, issues to consider, improvement objectives, and the infrastructure required (in terms of manual procedures) to implement a PMIS. In the next installment in this two-part series, we will expand our definition of a PMIS, describe the information needs of stakeholders, the main components of a PMIS, and the acquisition process.

http://www.techrepublic.com/blog/tech-decision-maker/when-to-consider-a-project-management-information-system-112729/