Top 5 Blunders with PPM Tools

Having many years of experience in implementing PPM tools for our clients – typically our tool, PM3, I have encountered a number of mistakes or blunders during implementation.

Some of the mistakes are made before a tool is even selected, some are made at selection and some are made during implementation. This blog describes the top 5 PPM blunders!

Blunder 1: We Will Build Our Own

One of the biggest mistakes in selecting a PPM tool is for an organisation to build their own. This decision is usually taken because It is perceived as ‘cheaper’. It may appear cheaper in the short term, but if you factor in the total cost of ownership, building your own PPM tool is a lot more expensive. It is also a lot riskier. If there are people in your organisation that have time to build and support a PPM tool, it does beg the question of whether these individuals should be deployed on other core business activities rather than building software.

Many organisations have a ‘buy not build’ policy for all applications.  Most people would not consider building a CRM system, payroll, contract management system, etc, so why is it sensible to build a PPM tool? Below are some of the reasons why it is better to buy instead of build.

• Faster Implementation. If you have to build your own software there will be a lead time when the software is not available as it takes time to build the software. Buying off-the-shelf software means you can implement your system quickly and derive the benefits more rapidly.
• Lower Upfront Cost and Predictable Total Cost of Ownership. Most software is SaaS where there are no large upfront costs, and the cost of the application is known at the outset. If you build your own software the project can, and often will, exceed the original estimate. Your support costs with packaged software are known upfront and typically capped. Support costs for a bespoke solution are not known upfront, not capped, and can be significant if the software is ‘buggy’.
• Ongoing Enhancements. With packaged software, you will get enhancements as part of the SaaS service model. These are essentially free. Any enhancements to a bespoke system have to be built and paid for.
• Community. With packaged software, there are usually community forms and user groups. Here you can exchange ideas with other software users and learn how to use the software.
• No Development Risk. Building new software is inherently risky. Dates slip, scope increases, and problems are inevitably encountered in the build and testing process. According to McKinsey Digital, over half of “IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns.” And, “17 percent of IT projects go so bad that they can threaten the very existence of the company.” Internal software development functions are typically confident about their ability to deliver every project; however, the evidence contradicts this.

Blunder 2: We Use Spreadsheets

PM3’s biggest competitor is not another PPM tool but the humble spreadsheet. Now spreadsheets are great tools used in many different ways but they are not PPM tools.

The key benefits perceived in developing a PPM tool from a spreadsheet are as follows:

• Everyone knows how to use a spreadsheet so there is no other tool to learn; and
• A spreadsheet is very flexible and can generate some very nice reports.

However, there are significant downsides to using Excel. A recent study found that over 88% of spreadsheets have significant errors in them. Bring so easy to use and powerful there is a high probability that a formula or a macro will contain errors.

A spreadsheet is not designed to be a project planning tool. It does not have dependencies, critical path, and other Gantt or milestone functionality. Spreadsheets tend to proliferate so you do not know what the real ‘version of the truth’ is or which file is the most up-to-date version. If you are audited on your project management processes, it is hard to confirm to auditors that the spreadsheet you are presenting is the single source of the truth; the controls are not built in.  Running million-pound-plus projects using spreadsheets is not only a false economy but the inherent lack of controls is likely to fail an audit and give misleading information on key projects to senior management.

Blunder 3: Wrong Tool

The next big blunder is picking the wrong tool. This can happen when a tender exercise is launched and a requirements exercise is carried out. Rather than thinking of what an organisation needs, a long list of requirements is produced, some of which are not needed. If a tool is selected that meets all these requirements, even the spurious ones, it is likely that a too-complex and too-expensive tool is selected. This will cause problems in implementing the tool and cost more than is necessary.

Alternatively, an organisation can select a tool that is too simple, maybe a web reporting tool. It may suit the current maturity of the organisation but when the project management maturity improves, the tool will be discarded as it does not support the new maturing processes.

What is needed is a tool that matches your current maturity and can switch on more sophisticated functionality as and when you need it. This ensures that you have a long-term investment in a PPM tool that sticks and gives you many years of ongoing payback.

Blunder 4: No Change Management

A PPM tool can deliver huge benefits to the organisation and to the project managers. However, it also represents a change in how people work. With any change, there can be blockers and resistance. For example, some project managers might be wary of their project data being visible 24 x 7 to senior management.

Too many PPM implementations follow a process of installation, configuring, training, and, support. What is missing are the change management activities. These would include stakeholder mapping, identifying change champions, developing a compelling need to change, managing a set of change agents, mentoring, and communication.

Change Management does not stop with implementation but should be an ongoing process.

With the right set of change management activities, you have a good chance of a long-term successful implementation. Without this, your chances of your PPM tool being successful are very slim.

Blunder 5: Big Bang Implementation

 Many PPM tools are selected because of their resource/capacity planning functionality. This can be quite complex functionality and, if you try and implement this functionality at the start of the implementation, you may create change overload. With our PPM tool, PM3, we always recommend implementing PM3 in stages. Stage one is to get the basics right, e.g., dashboards, plans, finance, benefits. Once the team feels comfortable with the new toolset you can add the extra functionality in, e.g., resource/capacity planning. Of course, you need to have a tool where you can easily switch functionality on and off. PM3 does this!

A big bang implementation will often cause ‘change overload’ and a lot of pushback; a phased approach is, in my experience, always best.

Summary

I’m sure that I could have added to this list, but these are my top 5. A PPM tool is a significant investment for any organisation and can deliver significant benefits if these top 5 mistakes are avoided.