Who is the primary stakeholder for your new PMIS deployment?

Your organization’s project managers should be the primary stakeholders for any new Project Management Information System. Here’s how to keep the priority on them by doing a basic stakeholder analysis as part of the requirements gathering process.

As you begin gathering requirements for a new Project Management Information System (PMIS), one of the biggest challenges you will face is prioritizing features among the different stakeholders in your organization.

You may be thinking that a PMIS should equally address the needs of all stakeholders. Ideally, yes. However, the ideal scenario is rare.

The requirements gathering process will most likely produce a long list of features and you will need to make compromises. Perhaps some features will be part of the first phase, while others will be added later.

Since your project managers will be the power users of any PMIS your organization deploys, their requirements should be prioritized ahead of “nice to have” features from other stakeholders.  Your goal should be to ensure that any new system provides your organization’s project managers everything they need to make better decisions with information that is accurate, timely and meaningful.

Most every other feature should be secondary.

What are the highest priority features for your PMIS deployment?

Often PMIS projects wind up being developed based on things like:

1. Auditing requirements
2. Claims management
3. Document management
4. Fancy dashboards for executive reporting
5. Approval workflows and reporting

But most of the above features would not be top priorities from a project manager’s perspective.

So why do so many PMIS implementations prioritize these things over what is most important to project managers? There are many reasons:

• Feature requirement lists are heavily shaped by who participates the most during development. Project managers may be too busy running projects to attend planning meetings for a new PMIS.
• Perhaps the project managers at an organization aren’t technically savvy about what is possible in a new PMIS.
• There may be a lack of agreement on best practices.
• Budget limitations may keep organizations from exploring features or enhancements – especially if an organization is deploying an expensive one-size-fits-all PMIS platform.

So what ends up happening? The resulting PMIS becomes overly complex since the stakeholders inevitably become Document Control and Auditing when there is no PM representation during requirements gathering. As a result, the PMS tracks every minute detail in case of an audit or claim. This means a ton of extra data entry for project managers and engineers. Meanwhile, project managers still don’t have the tools they need to do their job more efficiently and they fall back on manual workarounds. In other words, another failed PMIS deployment.

The above is very strange since the cost of Document Control Specialists can be less than 25% of a Project Manager.  Ask yourself: would your organization rather spend money on Document Control Specialists or Project Managers?

Why you should do a Stakeholder Requirements Assessment as part of your requirement gathering

We recommend doing a Stakeholder Assessment when we plan and deploy a new PMIS solution. A Stakeholder Assessment defines all of the stakeholders, their success criteria, decision making process, role within the project team and areas of focus.

We then apply the Stakeholder Requirements Matrix (See below) to what we learned during the requirements gathering process.  The Stakeholder Requirements Matrix provides a framework to prioritize everyone’s needs so you can prioritize requirements gathering and phases of a development/deployment.

A Stakeholder Requirements Matrix template for your new PMIS

Here’s a basic template to start a simple stakeholder analysis for your organization’s PMIS deployment:

1. Start with a blank table or spreadsheet
2. List the key stakeholders in your organization in the left column
3. List all of the project areas that you’d like your ideal PMIS system to cover in a row along the top
4. Mark the areas that pertain to each stakeholder’s primary responsibility
5. Rank the project areas according to priority

All the features on your requirements list can now be categorized by project area and priority.

Below is an example for a typical construction PMIS project.

Let us know what you think. Was Stakeholder Requirements Matrix helpful for your organization? How have you managed these challenges on your software deployments?

Need expert help gathering requirements for a construction project management solution?

We know that the requirement gathering process can be daunting. Lydon Solutions is here to help! Our team of experts has deployed project management information systems for clients managing multi-billion-dollar construction projects.  Get a free consultation to learn how we can help your organization.