Change Management – Part 3

Why change?

In the second part of this series, we talked a lot about gathering business requirementsthe first phase of any successful project – and the one that is generally poorly executed in any failed project. In this final installment, we will look more at the importance of understanding why the change was requested in the first place.

It is simple common sense to say that we need to understand the business requirements for any new or changed service, but unfortunately common sense is not always that common and many changes fail at the final hurdle because they do not deliver the results that the business was expecting.

Regardless of how well the technological solution has been executed and delivered to the business, if it does not have the desired effect, such as increasing customer retention or acquisition, then the change has failed. Failures of this type can almost always be traced back to a less than adequate business analysis phase.

Talk to the right people and ask the right questions

Who are the right people? Obviously you need to speak to people who will be interacting directly with the new or changed service in order to understand their business processes. These are the most obvious targets for questioning during this requirements gathering stage of the project, and in many cases this is where the investigation starts and finishes. But if this is where your analysis ends you are probably missing the most important people.

Talking to the people involved in the operational side of the business function is important, but it is even more critical that you understand the business strategy that is behind the change request. Understanding the desired business outcomes for the change will enable IT to examine the business problem that needs to be solved, rather than focusing on a technological solution to an issue.

Analyze the problem, not a solution

How often does the business come to IT with solutions instead of problems? A current or potential issue is identified, a possible remedy is seen and a change request comes into IT for a new or updated application.

It is essential to take a step back from the solution and make sure, firstly, that you are actually looking at the right problem, and secondly, that you have explored all the possible solutions.

Decide what you need to decide – sounds straightforward enough, but unfortunately it is not always so simple. Imagine the business comes to IT with a request for a particular piece of software. Rather than do your analysis on this narrow solution, ask ‘why?’…when you get that answer, ask ‘why?’ again. Keep asking until you get to the actual problem that needs to be solved.

Once you understand the underlying issue, you will be able to come up with a selection of possible solutions to be analyzed. The originally proposed change is likely to be just one of many at this stage, it is completely possible, almost probable, that one of the possible solutions will be to do nothing, and the effect of remaining with the status quo should be carefully analyzed along with all other potential solutions.

What are you looking for?

Ultimately, what you want to find out when analyzing requirements is which potential solution will provide the best results for the business. Initially, the technical side of the solution must take a back seat to the business requirements.

Will the possible solutions have the desired effect on the business process and have a good chance of providing the identified business outcomes? Any solution that falls short of these desired outcomes should be discarded at this stage. It is pointless to invest time in a technical analysis of a solution until we understand whether or not it will deliver what the business needs. The best technical solution may not be the right fit for the organization.

Once the solutions that best meet the business requirements have been identified, then the technical and financial analysis can be started. With all this information in hand, the appropriate decision can be made by the business on which solution is most likely to achieve the business results they are after, at an acceptable cost and with technical and infrastructure requirements that can be delivered by IT.

In summary

A well-conducted requirements gathering and analysis phase lays the groundwork for a successful project. If this is not done thoroughly and with reference to all appropriate stakeholders your chances of a successful project are greatly reduced. Putting the work in at this phase of the project will increase the likelihood of a successful outcome.

Conclusion

Change is about so much more than the act of making a change to the way technology operates. Careful attention must be paid to the people side of the change to ensure that it is accepted by everyone who will be affected by the initiative.

It is also essential that every change deliver the business impact that is expected. IT does not exist to change technology on a whim; any change must be made to improve the business.

When you plan your changes with business outcomes in mind, the results can be very different.

Read the series
Part 1
Part 2

ITIL Process Set Download

David Mainville

David Mainville


David Mainville, CEO and co-founder of Navvia, is a passionate advocate of Service Management and a frequent presenter, blogger and well known member of the ITSM community. With over 35 years of experience, David has held progressively senior technical and management roles allowing him to "connect the dots" between the Business and IT. At Navvia, David leads the charge to bring innovative ITSM solutions to market focusing on Product Development, Marketing and Operations.


• Posted by David Mainville on Aug 29, 2016
• Filed under Articles
• Tagged with

Share this post