Project Management

When to consider a project management information system

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.
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


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.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

I think that the establishment of a PMIS is an absolute necessity forany organisation engaged in project management of any description. I used to do a lot of this stuff back in the 1980s when I moved from civil engineering into IT. There was a concept called project control, but I argued that this was just accountants telling you where the money went, whereas what was needed was a system that would give you timely information on where the project stood, so that schedules could be changed, resources allocated and so forth ot complete the project with the maximum economy and quality possible. On a wry note, I caused a riot at one clients office when I set up a system which reported work still left to do and the resources currently available to do it (instead of the usual &age complete). The staff just found it all too threatening !


Before considering a PMIS your organisation needs to agree on a formal phase/gate process to: - Put discipline into an ad hoc and chaotic process - Provide a roadmap for the project leader, defining his/her tasks and deliverables - Agree a visible process known and understood by everyone in the company - Force more attention to quality of execution. The evaluation points are the quality control checkpoints. - Create a complete process - so there are no missing steps - Be multi-functional - it forces input from all parties - Become faster - activities are done concurrently rather than sequentially Take a look at where the process and the software tool are reviewed. or contact me for a web demonstration.


I'm a daily participant in a PMIS that's about 3 years old. IMHO, we're barely getting the most basic functions out of it. PMIS's offer a dazzling array of features, modules and capabilities, but don't lose sight of your priorities. Figure out the single most important feature is, or the short list, and make that work first. For instance, if time accounting and project schedule are most important, make that work first before you use it for budgeting, scope management, issue management, status reporting or whatever. Next, A PMIS in a bureacracy can create whole departments, processes and empires that drain the life out of other areas of the organization. If not careful, they can put an incredible burden on people that need to be doing "real work." Remember - PMIS has the capability to generate reports on the security engineer or whoever that hasn't completed their "TPS report." They can reduce the agility of workers and generate tons of frustration. Adoption of a PMIS is definitely a cultural change - the hardest of all changes. Take things slow, and demonstrate the added value one small step at a time. Stop once in a while and do a gut check - are those basic gut check. OK, the resource allocation feature is working great! But is the milestone hit rate report still reflecting reality? Trust me - these are real PMIS concerns. Don't cripple a good organization with loads of low-value compliance work.

PM Hut
PM Hut

Although this article was originally published in 2002, it's still not outdated. It still makes sense even in today's (much) more dynamic business environment. I love the part about the Project Management Process. I would like to propose a complete series of articles on the subject, which can be found here:


This article describes how the PM's were not doing their jobs. Putting a system in place does not guarentee good information if the PM is not inputting accurately. The PM's need to follow the process. Then if multiple interdependant projects or programs are involved a PMIS helps. Step 1 PM's do their job or they get fired. Step 2 Integrate with a PMIS.

Danny Graham
Danny Graham

A PMIS system is just a tool, its not a solution to the problem of poorly managed projects. Before looking at specific PMIS systems - read extensively around the subject so that you understand the nature of the problems you are dealing with. For example poor code quality wont be solved by installing a PMIS - you solve that through the actual responsibility structure of the team, the processes that they use and indeed the coding standards that they adopt. For example you could set up the teams as surgical units (see Brooks: The Mythical Man Month). Ensure that no one developer writes the functional spec by themselves (more than one pair of eyes on the spec, more than one pair of eys on the code). Look at how issues move back and forth between your different departments (business users, dev & test for example), who is able to sign off the different deliverables and where the disconnects are. Once you have a process, you can then impose that on a PMIS to take the drudgery out of using it day to day. And remember, no process is set in stone - it should evolve as you and your circumstances evolve. What is right for you today may not be right for you tomorrow. Review and update it, streamlining or augmenting - after each project completes. Within our business we adopted Microsoft's TFS even whilst we were still on our own proprietary language. The key here is that Source Control, Issue Tracking and Project Management Tasks are all held in one integrated system. This allows you to experience fully joined up thinking and eliminates the problems caused by having to jump between systems to understand bug fixes or the impact of new requirements (one version of the truth - no likelyhood of issues being in one system and not another - fewer opportunities to drop the ball). You can go from looking at a change in a line of code, to the Issue that caused it, back to the spec and the business problem that you were trying to solve in the first place in a series of clicks. And vice versa. This gives you true joined up thinking - and an audit trail. I should stress I'm not advocating TFS per se, any system that can join up source control, issue tracking, and requirements will do. And its very important you can impose your own process on it - which for the most part TFS does - and that you can subsequently alter that process. It changed our lives immeasurably for the better.


can someone please recommend some good vendors that they are using for PMIS?


It's very common that companies want to solve the problems with a "new system", when what we need are people trained in project management. A good project manager, can do his job, even with pencil and paper. Do not get me wrong, the software (PMIS) can help us immensely to the problem, but is "help" no "solution". Probably one of the first things to be thought that when you thinking a PIMS, is not the software in question, but the repository of information, because IS what they really inport.


I looked at several of these and found a few with solid performance and support. If you want a web-based app, consider dotProject (, web2project (, or PHProjekt ( PHProjekt is more of a groupware application, where dotProject and its spin off, web2project, are focused on projects with other functionality resting in add-on modules. All of them operate on a standard LAMP or WAMP setup. Since you get the source code for all of these you can customize them as needed. If a stand-alone application will do the trick for you, then OpenProj ( is about your only option. I actually use OpenProj to create projects from some templates I created, then import them into dotProject for actual execution. It might be a little more trouble than most people would like, but you can't beat the price. :) If budget is a concern, then you should definitely give these a look.


We have a system called Team-Logic that also includes an Intranet, CMS, lead tracking, project management, and an email newsletter server. You can see it our site at Cost is only $50 for 10 users.


If you're not sure about how to start a short list of vendors, you probably should start with a partner who can help you assess your current state of your project management process (as stated in the article). Internal Audit might be able to help. If you're still curious, the Gartner Magic Quadrant is usually a good place to start. They published their latest Project Portfolio Management magic quadrant. All of the main vendors are leading the way - CA, BMC, HP (be careful these guys are expensive).


There's a new company Automated Business Solutions that's got a very interesting and flexible Project Management application that I saw a demo of last week. If you go to the website you can sign up for an online demo or drop them a line for more information.


Don't forget to check the two sources which are specifically interested in project management. PMI (the Project Management Institute) has released its Project Management Maturity Model (OPM3) since this was written as well as its Portfolio Management Standard. Also BSA/HM Gov't has the Prince2 and ITIL standards. Both these organizations provide a great deal of guidance in improving your PM, PgmM and Portfolio Management maturity depending on which side of the pond you are on. Much better source of info than Gartner et al. I should think. Both organizations also maintain lists of 3rd party consultants who are certified to measure organizational maturity.

Editor's Picks