PMIS Evaluation: Action Plan (Part 5)
Updated: Oct 30
This is the final post in our five-part series on identifying and evaluating PMIS systems for your organization.
Now that you understand the type of PMIS system your organization needs, it is time to build an action plan to help you identify and select the right software for your organization.
Our recommendations for the evaluation of PMIS software are based on our experience identifying, assessing and recommending PMIS software for our clients. We find that the most valuable and important input in this process comes from the core users (sometimes called the power users or system administrators) who will be using the system daily.
A PMIS action plan should consist of six steps:
Making the Decision
In determining which PMIS software is a good fit for your organization, it is important to start with a set of all the potential software that could meet your needs. There are several websites that list different PMIS software systems and provide basic information about and comparisons of the software. Examples include Capterra.com, G2.com, and SoftwareAdvice.com.
Software comparison websites often rely on unverified third-party sources, so it’s best to use these sites to develop an initial list of options and gather basic information before doing a deeper dive into each application.
Another good source of information is similar organizations in your industry. We recommend reaching out to someone in their project management team and asking them what PMIS they are using to manage their projects. Some organizations might be inclined not to share this information while others are fine with sharing the name of their PMIS and perhaps even providing some information regarding their experience using it.
The bulk of the information about each PMIS system will likely reside on the developer’s website. You should be able to find information about features and specifications, screenshots, case studies, and more. Some developers provide extensive PDF documentation about the software as well as links to videos and webinars where you can see it in action and learn more.
Since the information is coming directly from the developer, it is best to take some things with a grain of salt. For example, you can discard any platitudes (“our software is the best at…”) or marketing language about specific features (“really easy to integrate with…”).
The next step in the process is to develop an evaluation framework. This is a fancy word for a spreadsheet where you list all the desired features and functions of your PMIS. Each of the identified software applications from the previous step will then be scored against the criteria in the spreadsheet.
Here are some possible evaluation criteria; remember to weight these based on your priorities before scoring the software in each category. It is also possible to create criteria with “yes or no” responses as part of a fatal flaw exercise, such that any software that does not meet the desired response would be removed from any further consideration. For example it may be important to the organization that the PMIS have multi-factor authentication, and if the software does not provide this, it would not be included in the ongoing analysis.
How easy is it to understand the pricing and how reasonable is the pricing structure?
What is the resource level of support, training and implementation that the company provides?
Workflow & Integration
How well does the software integrate with the existing business software?
Are the tools robust enough to handle all aspects of project management?
Can the user assess multiple projects simultaneously and make better resource allocation decisions?
IT Security Protocols
Does the software utilize best in class IT security protocols?
Functionality & Form
Is it easy and intuitive to use?
The evaluation framework exercise should result in an overall ranking of the PMIS software. The next step will be to schedule demos with the top scoring PMIS applications. This may include any number of systems, depending on how close the scoring is (and assuming they pass any type of fatal flaw exercise).
Most software developers are pretty responsive when it comes to scheduling demos, although some do have to be prodded a few times. The nature and quality of the developer’s response to the request for demo may be a factor in considering the software (since it portends future challenges with their customer service if they cannot handle a simple request for a demo).
Most sales representatives like to have a pre-demo call to gather information which can then be used to make the demo as tailored as possible. It is good practice to develop a list of questions about the software. For example, the developer’s website may list a specific function for the software, but it does not appear on any other list or in screenshots. These questions can be sent to the sales representative in advance of the demo or they can be asked during the pre-demo call or demo session.
Another pre-demo suggestion is to develop a post-demo survey using an online survey tool (Google Forms is free to use with a Gmail account and Survey Monkey is also very popular). The survey should include a range of questions that require both qualitative and quantitative responses. For example: “Would you feel comfortable using this PMIS to manage your projects? On a scale of 1 to 10, how well does this PMIS address our organization’s construction management needs?”
The survey should be administered immediately following the demo, with as much follow up as needed to secure an acceptable response rate.
Most demos usually go between 1 to 2 hours. The bulk of the session will be the developer’s team sharing the interface, capabilities, functions and other aspects of the software, but there should be at least 15 minutes for questions from the audience. On the purchaser’s side, the core participants should include the core/power users, project team members, and any other staff in the organization who will likely be using the PMIS on a regular basis.
Making the Decision
Before making any decision, it is important to request cost information from the developer. This can include a general estimate of the cost based or a specific quote based on the number of users and/or annual construction volume (ACV). Most PMIS software developers are comfortable sharing a general estimate of the cost up front, with a more detailed and specific proposal later in the process. The general estimate should be good enough for comparison purposes.
With the information that you and your team have gathered from online research, publications, conversations, demos, and costs, it is time to make a decision. It’s very possible that the decision will come down to two or three PMIS systems. You may find that some are stronger in one area but not as strong in others; or that everything seems good with a particular PMIS, except the cost. This is very common.
As discussed in our earlier articles: if you believe the PMIS can get your organization to where it needs to be, then it is not just about the PMIS but rather about doing everything you can to make the software work for your organization.
Generally speaking, it is not the PMIS that prevents an organization from meeting its objectives for successful project management.
Once the decision has been made, it’s time to convince others in the organization that you’ve made the right decision…
The larger the organization, the more layers of approval are typically required for any acquisition that will impact the operations of the company. Securing buy-in is not only about gaining the necessary approvals but also the goodwill from others in the organization who have some involvement in project management, and by association, the PMIS. This list may include accounting, purchasing, engineering, management, finance, operations, and so on.
Every organization will approach this process differently. Some organizations will invite all stakeholders to a meeting with representatives from the software company and consultants to discuss why this PMIS is being chosen, how it will be implemented, other information of interest, and to answer any questions. Others will provide information via the company intranet, messaging system or email. Many public sector organizations require all acquisitions above a certain dollar threshold to go through an RFP/RFQ process, even if the decision about which software to select has already been made.
While going through the proper channels and securing buy-in from all stakeholders may delay the implementation, it is key to the long-term success of the project management team, project management process, and PMIS.
Finally, you’ve gone through all the steps to evaluate, select, and secure internal approval for the PMIS. I’d love to tell you that the journey is nearly complete, but the real hard work is just beginning (implementation!). By doing your due diligence, finding the right PMIS for your organization, and getting alignment from the stakeholders, you have prepared yourself for the rest of the journey to go as smoothly as possible. But before you can embark on the journey, there’s a final step: commercial negotiations.
Note: in this section, I will primarily use the term “price” to denote the cost (or licensing fee) of the software to the buyer, although these terms are used interchangeably in discussions between parties. I also like to point out that the PMIS should be seen as an investment (and a very good one if used properly).
There are three things to understand when it comes to negotiating the cost of your PMIS software:
The cost is negotiable, to a degree; the pricing model is not.
Licensing costs are based on annual construction volume (also called annual capital value or annual capital budget spend), number of users, or both.
You have the most leverage before executing an agreement.
Software has a very low marginal cost. There is, of course, a high upfront cost to develop the software: thousands of hours of software developers’ time; computers and networking equipment; websites and marketing materials; salaries and benefits for sales, marketing, administrative and management staff; offices and data centers; and so on. However, the cost of selling an additional license (to you) is very low; perhaps some time on the part of a salesperson and technical specialist, but not much more than that.
However, venture capitalists don’t invest in software companies for altruistic reasons; they want a healthy return on their investment, and investors love the SaaS (software-as-a-service) model, in which customers pay a monthly or annual license fee for the software instead of purchasing it (although the latter is an option with some PMIS software). These recurring revenues allow investors to project revenues over a longer term, assuming some rate of growth in the customer base as well as annual increases in the license fees.
This all means that it is very difficult to ascertain the actual cost of the software, which also means there is a lot of flexibility in how it can be priced. The initial quote for the license fee is usually just a starting point for negotiations. How much the developer is willing to negotiate really depends on several factors, such as:
How strategic is the customer? Does it provide entry into a new geography, industry, sector or segment?
How promising are the future sales with the customer? Will they have a lot of construction volume or users in the future?
What incentives are available for the developer to make a deal within a certain time frame?
Construction Volume and Users
Most users of business software are familiar with software pricing models that revolve around the number of seats or users. Some PMIS systems also utilize this user-based pricing model, but many of them use Annual Construction Volume (ACV), also called Annual Capital or Construction Value (or a combination of both).
It is very important to pay attention to the definition of ACV as it may differ for each software provider. In monetary terms, there is a big difference between the total budget of all projects loaded into the software and the projected monetary spend on construction activity in a single year. The former can easily be a multiple of the organization’s actual construction spend, especially for renewable energy projects which can spend extensive time in the pre-construction stages.
For most systems, as the basis value increases, the cost per $ million of construction activity decreases. The rate at which this happens depends on the system’s pricing model. For some systems that target larger organizations, the pricing may not be advantageous for those doing less than $4 Million in ACV; for others, pricing may be favorably skewed towards those doing less than $2 Million in ACV.
Every PMIS system has its own variation on the basic pricing model. Since those pricing models as well as the terms and conditions can and do change frequently, it would not be worth sharing details on those here. Once an organization has reached this stage in the process, it should be familiar with the pricing models of all systems under consideration and be able to compare their merits accordingly.
MBA graduates love using the word leverage, so it would be remiss of me not to use it here. In this context, it refers to the power that customers have in any negotiation that requires subsequent negotiations in the future.
Buyers of PMIS software have leverage before signing their first contract because the initial sale is the most important one to the seller; without it, future sales do not happen.
Thus, the PMIS developer is most willing to agree to concessions to close the sale.
Certainly, pricing will be the main focus for any concessions from the buyer’s standpoint, but the three other key areas to consider for negotiations include:
the definition of ACV (e.g. should it include soft costs or equipment purchases?),
the number of user licenses (e.g. how many power users versus standard users are allowed), and
various add-ons or options to be included (e.g. integrations with other applications).
Through clear, direct communication, an agreement can be secured in writing which then leads to a formal purchase order and/or an invoice.
Now the fun part really begins: implementing and using your new PMIS software. We will share insights and advice around that in future posts and videos.
This post was written by Sirous Thampi, the founder of THAMPICO LLC, a consulting firm that provides program and project management support for utilities and cooperatives. We help our clients align people, process, and technology to produce optimal outcomes for energy project development. Our goal is to help our clients deliver more reliable, affordable, and clean energy, which is what the world wants and needs.