1. Determine which business problems have the biggest impact.  Key areas to look at include time savings, business value created, benefit realisation, employee experience, and business performance.

2. Avoid having a long and exhaustive list of business problems to address and features to look for.  No one tool will address all needs, so it’s about the must-haves versus the nice to haves.

3. Prioritise the importance of various business problems. Ideally form no more than the top 1-3.  This will help you become focused.

1. Search on Google, using popular search terms such as organisational change management software, change heatmap, single view of change, change management deliverables, enterprise change management software.

Be clear in terms of whether you are after an enterprise or portfolio level tool, or a project delivery type of tool.

2. Review change management software compilation pages such as this, or this.

3. Review any vendor presence in change management associates such as ACMP (Association of Change Management Professionals) or CMI (Change Management Institute).

4. Search or ask questions on Linkedin Groups such as those for ACMP, CMI or Organizational Change Practitioners

To gain the budget and stakeholder approval you are looking for to invest in a change management tool, you need to ensure you have a very clear business case.

1. Estimate the size of the problem.  How much cost is the problem causing?  If not cost, then time saving, benefit achieved, or business performance levels impacted.

Be as quantitative as possible so that it is easy for your stakeholders to see the importance of the problem.  If you would like to calculate the financial benefit of managing a change portfolio visit this article.

E.g. Performance drops can be 10-20% (which can translate to millions of $).  Managing change across the portfolio is one of the few ways to manage this significant risk.  Read more here. 

2.  Identify the top stakeholders most impacted by the business problem and involve them.  For example, if you are dealing with change saturation, find the senior business leader most impacted by this pain and involve him/her in the process to gain their support.

3.  Involve relevant departments that may impact the budget decision such as PMO, business heads, Procurement, IT, etc.

Some examples include:

– Cost savings in analyst support/resources, and manual time required in data collection, cleansing, data entry, data analysis and report production.

– Cost of business disruptions resulting from lack of data to support business decisions.  We’ve found that often one individual instance of using data to make the right business decision can create millions in value

– Building business change capability through the ability to see and prepare for change, and iterate change interventions based on data

– Support speed of decision making and insight generation from weeks to minutes

1.  Link desired features to your prioritised business problems.  In this way you are focused on the most important features that will make the most difference for your organisation.  Don’t be tempted to have a super long and exhaustive list of requirements since this may increase cost, narrow down your vendor choice considerably, or worse, end up with a tool where you may not use most of the features.

2. Balance current urgent business needs with emerging business challenges.  By choosing a tool you are choosing to leverage this in the future.  Be considered in understanding what is needed today, versus what may be needed in 1 or 2 years time.  Ensure your tool will support your emerging needs.  For example, as you start to build more data and insights, does your tool have AI features to support trend analysis and forecasting?

3. Determine what is right for your business in terms of their maturity and practices.  Depending on the tool that you select, it may support your change maturity focus.  Decide not only whether the tool is easy to use for your business stakeholders (who may or may not be familiar with change management terms and practices.  Also, ensure that as you build business change maturity, that the tool can continue to provide value to further the maturity.

4. Build your requirement list, again focused on must-have first before nice to haves.  Examples include: service performance levels, data and security, ease of data access, modes of data input/export, automation, AI/machine learning, ease of integration, etc.

Other than technical features and product design, there are other considerations in determining whether the software is right for you and your organisation.  Here are some examples:

– How long has company been in operations for?

– What’s the background of the founder and how knowledgeable about the subject matter is he/she based on experience?

– Is there a structured onboarding process?

– What are the support channels? (e.g. self-help articles, digital Q&A support, user community, etc.)

– Is there a sandbox to trial the tool before signing up?

– How easy is it to administer and maintain?

– Must I purchase consulting along with the tool?

It depends on your business priorities.  Most businesses will always have multiple priorities.  You need to be clear to what extent the business priority you are solving is critical to the success of your role.

For example, if the business priority is change saturation and limited capacity, then this priority will likely no go away.  Even if there are other important business priorities, your role in the longer term may be measured by to what degree you have solved the organisational pains related to change.

We’ve seen lots of examples where the business directly intervenes to solve their pains, if this was not solved by the change team.  

Using a software is like eating a buffet.  Yes, it might take a long time to be able to sample all the various dishes and feel full and satisfied.  However, you don’t need to eat everything in the buffet to start to enjoy the food.  Pick your low hanging fruit, the ones that will directly address your business pain quickly.  The rest, including building capability, can wait, and will take time. 

Again it depends on where you are and the business problems you are trying to solve.  If you have a mature change practice, and the needs are requirements are very clear through previous systems or tools, then this may be an option.  Ideally you will have crystal clear product design and operating model in mind already.

Be clear about the time you have to solve the business problem.  What is the cost of not solving the business problem swiftly? What is the impact on the change team if this is not solved on a timely basis?

However, note that to build a tool in-house there are several considerations:

– Time and resources it takes to design, and continually improve the product.  Like any system products it needs constant attention and resources for improvement and gradual maturity.  The first iteration will usually not satisfy all your requirements

– Technical resources to design the user interface, technical development, infrastructure alignment, and testing for the product

– Ongoing total cost of ownership including technical development and support, product development, architecture support, infrastructure/system maintenance cost

– Business stakeholder resources for input and testing

– Risk of building a tool that is overly detailed and cumbersome to maintain

– Disadvantage of not being able to leverage industry best practices from constant user feedback that external tools have