As our clients’ needs change over time and we seek competitive advantage in delivering against those needs, there is a relentless requirement to manage the evolution of our organisations. This is no easy task and having a framework/roadmap for doing this can be helpful even if only to structure thinking on the topic. This process of evolution can take many forms; we might be developing a new service line, seeking to implement a new technology solution or delivering another important change process.
Some years back and early in my consulting career, a client project required me to develop a simple approach to doing just this. Whilst there were problem-solving approaches around, I decided to develop my own approach (all part of building consulting capability at the time). In this article, I am going to focus on how to use this approach to deliver change in our own professional service firms rather than for client work (…I use it for both).
Developing the Methodology
Although at the time I wanted my own approach, it also seemed sensible not to reinvent the wheel so I decided to do a little research on the subject. I gathered details on well-publicised/proven problem solving methodologies from five top-flight consulting organisations – all of whose methodologies were typically broken into three or four stages.
I then compared these against each other to identify any differences. Five phases emerged each of which seemed to be a logical and distinct phase of a potential roadmap.
The table below is a simplification of how I went about this:
The next thing to do was clarify each of the phases, name them and develop the content required for each phase of the roadmap. Like all good Consultants 😉 , I had to have an acronym for the model. In truth, this was as much about being able to remember it as anything else. I knew, if I had an acronym I stood a good chance in doing this and ended up with S.T.U.D.Y., which seemed to fit the phases and also paid homage to the fact that we tended to call our client engagements ‘studies’ at the time.
So, had I come up with a new methodology? No, not at all, I had simply compared a number of great approaches against each other and developed an approach that encompassed what I saw as the best bits – the principles are nothing new but are helpful.
Using the Methodology
I am now going to walk you through the STUDY process:
At its most fundamental, STUDY is a simple process for delivering work when you want to clarify what you want to achieve, where you are now, help design some form of solution, implement it and then measure its impact. Therefore, this model is applicable to most situations that involve the above steps. It is also important to note, that this approach tends to work better when it is reasonably clear what you are trying to achieve through the process (for example – we want to develop our digital technology capability) – I would deploy other methodologies for less well defined ‘strategy style’ problems (one for another day…).
Figure 1 – STUDY expressed as a linear process
This phase is not necessarily concerned with writing a strategy (although we may do this) but is more concerned with having a clear understanding of what your organisation is looking to achieve through the STUDY process. You should be able to link what you are doing to the firm-wide or business unit strategy. Is this proposed initiative in line with strategy?
In this phase, it is also important to be ‘strategic’ in your thinking i.e. to consider the following things:
- The purpose or ‘why’ of what you are trying to do
- The key objectives/goals of your action – what does success look like?
- Making sure you have a clear understanding of the problem/issue that you are dealing with
- Confirming who the key stakeholders/decision makers are
- Agreeing the scope of the initiative
- Conducting some preliminary assessments and initial meetings/workshops
It is important to get the team together quickly and spend the right amount of time at the start of the process understanding what you are there to do (even if this takes a half day or whole day). In my experience, well facilitated workshops with key people can be invaluable in doing this.
This is the gap analysis & diagnostic phase and you are seeking to identify where you are now (and how that situation came about) against where you wish to be. The ‘where you wish to be’ should have been developed during the Strategy phase.
Typical activities for this phase might include:
- Reviewing existing/core processes
- Performing the gap Analysis – reviewing the difference between desired and actual performance.
- Identify areas where maximum performance impact is possible.
- Conducting benchmarking/reviewing best/leading practice
- Identification of pain points & their causes
- Gathering data
- Assembling priorities
- Setting performance goals
Tip – use the Pareto rule to ensure that you perform enough but not much analysis. Often the work required to get the extra 20% of something would take too much time when 80% is good enough – don’t let great be the enemy of the good.
This phase is fundamentally about utilising all of the resources available to you to design an appropriate solution that fits the strategy and addresses the gaps identified in the Take Stock phase. It is best to co-create the solutions with key decision makers/stakeholders as this will:
- Help to develop a better solution
- Alert you to problems
- Ensure end user/internal client ownership of the recommendations
Remember that any solution design should be based on facts/data as much as possible.
Typical activities may include:
- Reconfirming the vision and strategy
- Mapping the future state/processes
- Analysing data
- Seeking quick wins (high impact and easily implementable)
- Developing appropriate parts of the solution. For example:
- Process re-design
- Assessing the organisational implications of what is being developed. This may include people, process (including ICT) and property
- Assessing costs
- Building a business case and benefits case for the proposed solution
- Developing the delivery plan
- Gaining approval prior to deployment
You may identify the need for pilot studies in order to prove the concept pre-deployment and test the resource levels required.
This phase is about implementing your proposed solution through a carefully managed deployment. This may involve building capability, changing mindsets and also implementation across businesses, functions, regions etc.
A number of different approaches may be suitable, from a full programme management approach coordinating multiple projects through to effective project management – if the solution is packaged as a single project. I won’t go into detail on these approaches here.
Typical activities may include:
- Producing a project execution plan – this should cover timeframes, resources, activities etc.
- Building implementation teams
- Roll out/launch of initiatives
- Management of performance objectives
- Tracking progress
This final phase is concerned with ensuring that you realise the benefits from your activity. This phase may happen during deployment (or even earlier) or at the end of the process (depending on its type).
Typical activities may include:
- Ensure that objectives have been met and how the solution is working post deployment
- Ensure that the client/end users are happy
- Sharing lessons learnt
- Setting up/reviewing KPI’s
- Planning for further activities
In summary, the STUDY process was designed to provide me with a quick way of pulling a plan together in a sensible way where some form of business change was required. It helps to set out potential activities relating to where you want to be, where you are now, developing a solution, implementing it and measuring the benefits. It is down to your individual judgement as to whether the process outlined here is applicable/useful to you.