Numerous companies use Excel as the default option to display reporting and planning processes – mostly for convenience (“we already have it and it doesn’t cost anything”). But in the end most people come to a point where the Excel “pain” becomes too much and they need a specialist CPM solution. But choosing the right one is easier said than done.

In my role as an analyst at BARC, I have been helping companies select Business Intelligence (BI) and CPM solutions for the last seven years. In this time, I have seen the same mistakes occurring in software selection processes with remarkable frequency. These are not trifling mistakes but serious errors that can massively endanger the success of a project.

To help you manage these dangers in your project, I have summarized what I regard as the three most common mistakes with some handy tips to avoid them.

Mistake #1: Messy requirements analysis

The basis of each software selection process is a solid requirements analysis. However, astonishingly many companies fail at this first step. Recurring classic fails include:

• IT is searching for a ‘suitable’ tool for business departments without involving them in the actual requirements analysis.
• Requirements are only gathered in restricted areas of the company, without consulting all relevant departments.
• Thinking too short-term: A tool is chosen simply because it addresses the biggest pain points without considering likely future requirements.

If you find yourself in one or more of these situations, alarm bells should be ringing! You are at risk of conducting a limited requirements analysis. My tip: produce a thorough functional, technical and organizational requirements analysis in all the business units that are expected to work with the software. This should embrace business departments as well as IT to help prevent acceptance issues when the tool comes into use.

• Absolutely necessary and desired functions, as well as the user-circle of the software, should be identified within the functional requirements analysis.
• The technical requirements analysis is concerned with data security, required and achievable performance, platforms and operating systems as well as database technology.
• The number of users, as well as the support of different user types (power user, ad hoc user, end user) through tool functionality, is based on the organizational selection criteria.

As a result of the requirements analysis, a complete catalogue of criteria is produced, with which the software solutions under consideration can be evaluated and qualified. Since not all criteria will be equally important, each single requirement should be weighted. Only important criteria should be applied for the preselection (‘short list’) to efficiently narrow the market based on a small selection of relevant assessment points. Other less important criteria should be considered later in the detailed evaluation of the short list of products.

Following these guidelines will help provide a solid foundation on which to choose a suitable CPM solution later in the project.

Want more like this?

Want more like this?

Insight delivered to your inbox

Keep up to date with our free email. Hand picked whitepapers and posts from our blog, as well as exclusive videos and webinar invitations keep our Users one step ahead.

sign up

By clicking 'SIGN UP', you agree to our Terms of Use and Privacy Policy

SIGN UP

By clicking 'SIGN UP', you agree to our Terms of Use and Privacy Policy

Mistake #2: Choosing the vendor, not the solution

Focusing only on “big” and well-known software providers from the beginning is a mistake many companies make, especially in small and medium-sized businesses. “Smaller” and specialized software providers often have very good solutions and a more thorough understanding of requirements based on factors such as geographical location, industry sector and enterprise size.

It’s understandable that companies might have concerns about opting for a “smaller” vendor. For example, when considering the security of their investment, decision-makers may feel it’s more likely that a smaller vendor will be acquired or go insolvent. However, the size and profile of a vendor should not be a KO criterion in the selection process. Bear in mind that the continuity of a product cannot necessarily be guaranteed just because it is provided by a “big” vendor. Also, the size of a vendor and the quality of its product do not always correlate with each other.

For your selection decision you should principally consider the following: Bigger is not necessarily better – supposedly “big” providers are not inevitably superior in all respects compared to their “smaller” rivals. The pure size or prominence of a vendor is not a valid decision criterion.

Does the overall package of technical and functional support based on your organization’s demands contribute to a reasonable price-performance ratio? Factors such as on-site support services, how the vendor treats its customers, local language support and regional/industry-specific knowledge are just a few of the considerations you should not underestimate when selecting software. Our experience and research consistently shows that “smaller” providers usually outperform the “big” global vendors on these counts.

Mistake #3: No proof of concept

It can be risky to skip a detailed evaluation of the solutions on your short list because of time constraints or financial reasons. Solutions should be examined with regard to all relevant requirements (and costs) and put to the test as part of a detailed evaluation. This helps create security of investment and minimizes the risk of making the wrong decision.

The goal of a detailed evaluation is to obtain an accurate picture of the capabilities the software has to offer. Test installations, structured software presentations and prototype creations (“proof of concept”) are appropriate here, ideally based on performance requirements and data which are as realistic as possible in terms of how the organization ultimately plans to use the software.

It is also advisable to consult external consultants and reference customer talks to glean feedback on providers and products from other projects and companies. In particular, the feedback of other users working with the solution on a day-to-day basis can be extraordinarily valuable in shedding light on potential problems and challenges that may arise once the solution goes live.

Conclusion

Finding an appropriate CPM solution is not rocket science. Take these tips on board and you will increase your chances of an accurate and successful selection process.

Important: Avoid making the mistakes I have outlined above and be mindful of the warning signs. Actively steer the project back on track if you notice something is going wrong. Knowledge of the best practice approach to software selection, as well as the common pitfalls, will significantly reduce the chances of making a bad decision or the project failing.

Armed with these tips, nothing should stand in your way towards a successful CPM software selection project. I wish you great success in your own flawless selection process!