A PMIS can be a critically important tool for organizations undertaking large capital expenditures for construction projects. These projects are complex and have unique goals, making careful planning vital when choosing and setting up a PMIS. This plan should identify all system requirements so that they align with department needs. Before the organization decides whether to use another department's system, it must fully understand the PMIS requirements.

Implementing a new system, especially a PMIS system, will involve many organizations beyond the project management office (PMO). Accounting, IT, supply chain, budgeting and planning, HR, and operations should be engaged early in discussions spanning the full selection process. The goal will be to identify requirements and participate in system selection.

Selection teams should expect other departments and team members to recommend alternatives to a new system installed solely to manage projects. From enterprise resource planning (ERP) systems to work management systems, adjacent alternatives abound within most organizations.

The IT department may suggest the use of its own IT service management system, known as an ITSM, for the task. Before weighing this as an option, PMIS requirements should be fully identified and understood. System maintenance, security, change management and data life cycles will also need to be considered before the PMO team makes the decision to digitally coexist inside another department’s system.

PMIS selection teams should consider both business and technical requirements. While business requirements will largely be identified by the PMO with input from operations and supply chain professionals, it’s the IT department that will take the lead in identifying technical requirements of the system. To get to that point, the selection team needs to drive the discussion on business requirements. This will inform the IT department on use cases, user counts, record counts, user roles and record retention requirements.

While each organization is unique, and each PMO will execute project work differently, the PMIS selection team should evaluate and prioritize needs and functions in categories such as these:

• Cost and budget control
• Scope control
• Materials management
  • Procurement management
• Schedule management
  • Milestone management
• Earned value management
• Resource management
  • Labor management
  • Safety information management
• Risk and issue management
• Quality management
• Communications management
• Change management

The team should focus on determining how the tool will be used to provide support to project team members. Within each of these areas, the team should drill down into use cases. Using the current organization’s process as a guide, the team will be able to determine exactly how the system is to be used, by whom and when. While a system built for the purpose of reporting upward will be useful, a system that supports project team members and helps them to accomplish their goals will be used consistently and sustainably.

Project teams’ use of spreadsheets and text documents to manage projects is often a key factor driving selection and implementation of a PMIS. Organizations find it difficult to align spreadsheets into data and draw information from that data into reports. PMO teams often spend a great deal of time and resources to roll reports up and summarize. While this activity cannot always be avoided completely, a well-implemented PMIS can align data at the source and pass this data along to the organization’s data lake for higher-level reporting.

Support for project team members and reporting functionality are critical elements for a PMIS. A great requirements list will no doubt gravitate around these two pillars of performance. Once that requirements list is completed, it should be prioritized, and that prioritized list should be used to make the decision on which system to pursue.

Organizations with strong IT departments typically have a system in place for managing support calls. When a system runs into issues, an ITSM system is ready for end users to log the issue and communicate with IT until they and their vendors get it resolved. The set of functions supported by an ITSM, including logging support tickets and managing them to completion, seems useful in a project management environment. When considering a new or replacement PMIS, organizations sometimes consider their own ITSM as a logical equivalent. However, consideration of an ITSM among the many commercially available PMIS platforms should be done carefully.

In considering whether an ITSM should serve as an alternative to a PMIS, teams should determine whether the IT department and ITSM vendor is committed to supporting the system’s role. These factors should be weighed:

• Whether the ITSM supports all the requirements of a PMIS.
• Whether the advantages of using an ITSM outweigh the disadvantages.
• Whether the PMO can work in harmony with the IT department to which the ITSM is dedicated as a support solution.

System changes implemented by the IT department could potentially impact the use of the system as a PMIS. Likewise, changes required by the PMO may not be able to be made inside an ITSM. The team should also consider the future requirements of their PMIS and their IT department’s ITSM system. The team should carefully consider the need for data analytics, data modeling and use of artificial intelligence (AI) in the future, and whether the ITSM will support this need of the PMO. Detailed conversations between the PMO and the IT department are necessary for maintaining alignment now and in the future.

A commercially available PMIS will advertise itself as supporting a PMO, project teams and project stakeholders. Some PMIS vendors position themselves to support certain industries better than other systems might.

Some vendors, for example, are heavily focused on oil and gas, federal government, utilities and commercial construction markets. There are also vendors focused on serving smaller projects, while others are focused on larger or megaprojects.

When considering an ITSM, remember the focus of the vendor will be on the IT department rather than the PMO. Some may position themselves to support large internal systems, while others may focus on end-user self-support. The problems encountered in supporting IT systems are as varied and complex as the problems faced in supporting project teams.

One of the first things a team considering a dual-purpose role for an ITSM is whether the ITSM considers itself to be a PMIS as well as an ITSM. Any ITSM vendor not willing to at least offer the ITSM as a replacement for a PMIS should be removed from consideration. To consider an ITSM further, the vendor should be offering itself as a PMIS particularly focused on the industry and size requirements of the PMO shopping for a PMIS.

Reusing existing functionality and systems is the main idea of using an ITSM as a PMIS. It is not advisable to try to get a function of the ITSM to work in a way it wasn’t intended. If the ITSM has an issues management function, for example, don’t consider using it to track invoices or labor hours.

Borrowing existing functions and forcing them to fit into a new purpose is a change management challenge. This may result in individual teams using functions and forms differently or regressing back to using forms and spreadsheets. Later, using all of this collected data on invoices and labor hours in the issues management table will be a nightmare for the data analytics team. For those functions that aren’t supported by the ITSM, find a different tool in the organization rather than contorting an existing feature.

Remember, the IT support organization is the customer of the ITSM. As the customer, the ITSM vendor will be aligned to IT, not necessarily your PMO. The IT support organization, likewise, will be aligned to its mission of supporting all its applications.

The selection team should consider — and have honest communications with IT — as to whether future functions and enhancements to use the system as a PMIS will be supported. Further, the criticality of this support is important to understand. The business criticality (BC) level of an ITSM will be very high — nearly the highest level — in most organizations. To illustrate: If the ITSM comes offline, the organization’s highest-criticality-level systems are now at risk as a result; high-priority support cases in those systems can no longer be managed. Therefore, the IT organization will be reluctant to test and make changes to the ITSM. Extensive testing will be required, and the IT organization will not want to execute a high-risk change to the ITSM at a time when criticality of supported systems is also high. In short, the IT department will be highly protective of its ITSM, which will make testing and rollout a potential challenge.

All software vendors issue product updates, patches and changes. Using an ITSM as a PMIS comes with either some level of configuration or customization, often because the PMO will be using the base functions in a novel way. As a result, the PMO will be required to support product changes by testing customizations or processes with each release.

Both the IT group and the PMO need to be able to support this activity. The selection team should consider, and communicate with IT, whether its members will be able to test their process with each update and patch. Selection team members should also honestly consider whether they can support doing this for the life of the application.

In the case of an ITSM implemented as software as a service (SaaS), the vendor may have limited ways to allow the PMO to execute its own testing, and setup of additional nonproduction environments should be considered. Failure to properly maintain the system as a PMIS will result in stranded users and failures within the project teams being supported. During this failure, it is important to remember that the IT department will continue to be protective of its ITSM and may not rush into implementing a fix. Selection teams should consider this carefully.

Corporate policies governing project authorization, procurement and/or changes often drive specific requirements for security, workflows and access control. In addition, functions like this in a commercial PMIS will likely be tied to budgetary controls inside the system. Before deciding that the ITSM will serve as a PMIS, see that corporate policy and governance requirements are fully addressed in the requirements and that reliable plans are in place to support them. Consulting with internal auditors to gain full understanding of the ITSM system, and whether it can be used as a PMIS, due to its existing controls, is highly recommended to remain compliant.

It is also important to consider how the users will perform their tasks in their roles. For example, the ITSM may offer issues management, but if the PMO’s issues management process requires project team members to respond differently based on their role, you should see that the ITSM can differentiate roles and allow role-based business process modelling.

Aligning a commercial PMIS to the roles in a PMO can be a challenge on its own. An ITSM would need to be highly flexible to allow the PMO to control processes and roles. In addition, the ITSM would have to potentially pull double-duty to allow role-based business modeling for its service management function and its PMIS function.

If it has not already done so, the team should consider the advantages of using the ITSM as a substitute for a commercially available PMIS. The first advantage could be cost of ownership. Depending on the system, licenses may already be held by (or available to) the project teams. In these circumstances, on-premise applications, backend databases, front-end user interfaces and all other support systems will already be in place. Acquisition costs should be minimized to cover additional end-user license needs, any configuration and integration costs (discussed later), change management, implementation (a go-live event), and training.

Certainly, the presence of an existing application support organization is a tremendous benefit for a PMIS. The ITSM will have a high business-continuity level and will not be permitted to endure long system outages. In the case of an SaaS solution, the IT department will already be managing the vendor and maintaining service-level agreements (SLAs). While the IT department may be looking for ongoing maintenance funding by the PMO, the purchase orders and approvals for ongoing maintenance will be taken care of by IT. It deserves restating that the IT-PMO partnership and its proper management would be critical for this to be successful.

The ITSM may already have integrations in place for data analytics, ERP systems, payroll systems and other functional systems. Integrations will likely also be in place for backend systems to support user authentication and (potentially) authorization, data transfers via flat files, and mobile user interfaces.

Once a complete system architecture is reviewed, the selection team would initially need to only consider additional integration requirements, knowing these systems are in place. During implementation, however, the details become critical. The implementation costs should include costs to study and some contingency to address the existing integrations. The existence of those integrations does not guarantee their suitability as a PMIS. Field-to-field mapping, interface triggers, timing and data quality should all be considered at a minimum during the early design phases.

Whether considering a commercially available PMIS, or an ITSM as a substitute, the selection team should meet with the vendor with the goal of understanding both where the solution is, in terms of functionality, and where it is heading.

For software solutions, vendors typically maintain application road maps, periodically updated as technology advances, to depict where the organization is going to take the product, and/or when it will reach the end of its life. These road maps are typically well-guarded internal documents. Vendors will normally share these documents only with direct customers under nondisclosure agreements and with safe harbor understanding. In some cases, the documents will not be shared under any circumstances.

It is important for a PMO to understand where its support systems are heading. The selection team should scrutinize the road map carefully to verify that priorities are planned for and addressed appropriately. Alternatively, the ITSM may be more focused on service management. In these cases, the needs of the PMO may not be represented at all on a product road map. With IT maintaining its own set of road maps, changes to features and functions to support the ongoing evolution of the organization’s ITSM are unlikely to include the needs of the PMO.

IT will focus on the use of the system as an ITSM, not a PMIS, and IT departments will operate the system at the ITSM criticality level. This has its advantages in terms of uptime and adherence to SLAs.

If the IT department and the PMO are to be aligned, many levels of PM functionality will need to be addressed in the ITSM road map. Because PMO organizational processes and operations are not typically as stable as IT system management, frequent changes to a PMIS will be inevitable. It is thus likely that an ITSM support team will be disinclined to implement frequent changes to its system. Remember, the ITSM supports the most critical system in the organization.

In some organizations, this resistance to both change and testing may flow down to preproduction systems as well. The PMO would need to have in-depth conversations with the IT department to understand exactly how the PMO cannot only use but fully operate inside the ITSM.

When the ITSM or IT department requires changes, it is the IT organization that will move forward as quickly as its members would like to implement the change. If the PMO is given the opportunity to test the change against its configuration, timing will be crucial, and resources will be promptly required. The PMO needs to see that appropriate resources are available to execute testing and maintain the PM functions in any updates. Further, the PMO should discuss with IT ahead of time, and see that defects in the PM functionality will be resolved prior to pushing the update into production. It needs to be understood that a change that breaks PM functionality will not be pushed into production, no matter how critical the defect.

For large organizations, the IT system architecture is very complex. Systems interfacing the ITSM may have their own interfaces with other upstream or downstream systems. Changes to connected systems can impact the functionality of both the ITSM and PMIS. The IT and other business teams need to include the PMO in conversations about upcoming changes and updates so that changes to integrated systems and connected systems do not break PM functionality. The conversations also should address the need to give the PMO adequate time for testing. Likewise, the PMO needs to be prepared to apply resources to testing these changes. This is not to say that this same risk doesn’t exist in a commercial PMIS system, but the inclusion of the PMO could easily be overlooked when using the ITSM as a PMIS.

Applying influence to gain enough organizational support to implement the PMIS is a challenge with standard commercial solutions. While there are likely many individuals within the organization fully prepared to advocate for one commercial solution over another, there won’t be many, if any, individuals in the organization who have used an ITSM as a PMIS and are ready to support the PMO in its decision.

Vendors, system integrators and consultants will all have their own supporting slide decks and materials to help the PMO in its journey to implement a commercial PMIS. In the case of using the ITSM, those same partners will have few to no materials at the ready and will be of little support up and down the organization to help drive the adoption of the system. Within the organization, the pool of influencers and change agents advocating for the utilization of the ITSM is likely to be quite small, and the support they will require from outside parties will be quickly exhausted. The PMO’s decision to move forward with any solution is likely to be examined at every stage in the process. Should the ITSM fail the PMO at any point in production, the decision to use it in the first place will be front and center with the PMO decision team left standing alone to answer for it.

If using an ITSM is to serve as an initial step beyond past practices of using email and spreadsheets and toward implementing it as a commercial PMIS, these principles should be considered:

• Develop an excellent relationship with the IT department.
• Do the research needed for a great understanding of the life cycle of the ITSM.
• Develop a plan of operation for how the PMO will operate in the ITSM.
• See that the ITSM will support the most critical functional requirements of the PMO.
• Develop a plan for how the PMO (and all that precious data) will migrate from the ITSM into the future PMIS.

These same principles would apply when considering other software already acquired by the organization as a substitute for a PMIS. PMO teams should note that coexisting with another department and using software made for a different purpose will be an additional challenge on top of the already monumental task of implementing a PMIS and driving change through the organization.

Reaching a final conclusion should follow this process:

• Evaluate the ITSM vendor’s intentions to deliver as a PMIS.
• Determine whether the ITSM meets PMO requirements.
• Gain a realistic view of the relationship between the IT group and the PMO.
• Assess the IT department’s willingness to collaborate with the PMO.
• Understand the PMO’s tolerance for operating inside IT’s core system.

With those findings in hand, the decision then comes down to costs and benefits. Further evaluation of the pros and cons of implementing an ITSM as a PMIS will serve little purpose without affirmative findings in those areas.

The selection team must then evaluate whether these standard functions can be effectively supported by the ITSM in combination with other systems available within the organization. For example, an organization may have a fully integrated ERP system that supports cost control with procurement and materials management. In a case such as this, the selection team needs to ask itself how the ITSM supports the other requirements, and whether a third system is available to support functions the ITSM won’t.

All considerations of PM functions need to be done in context of time. Consider whether the ITSM will support the function now, whether it will support it in the future after a system update and whether it will support the function when a supporting integrated system changes. For those functions where the ITSM will not support the PMO at all, the selection team should consider whether the functions are critical enough to digitize at this time. In short, how well does the ITSM do what the PMO needs it to do?

Implementing a new PMIS or replacing an existing system will be a lengthy journey and a challenging undertaking for any PMO. Along the way, the priorities and actions of other departments could result in competition for resources and resistance to changing legacy processes. These factors may become distractions that could potentially derail plans to put new systems in place.

PMO teams armed with a great list of well-defined requirements and a sound understanding of the alternatives and their current uses will be able to navigate their way through the selection process and ultimately deliver an excellent system for their project teams and the organization as a whole.