As a Business Analyst, or Project Manager, you often arrive on a new project and have no idea where to start. Things are a bit chaotic for a few weeks and then they gradually start to fall into place. You all figure out your roles, what needs to be done and the real work can begin.
This frustrates me, it’s wasted time, we should be able to start adding value straight away. I think… what would Bear Grylls do on his first day on this new project?
Dropped into the desert, or a high mountain peak, out in the wilderness. He has to get to civilisation and he has to survive using what he can carry and the environment around him. If he doesn’t figure this out quickly he’s got more to worry about than the failure of the project or the termination of his contract!
The first thing he has to do is assess the situation. This isn’t a random investigation but a structured approach that can be applied to a variety of environments so he can quickly start making important decisions.
He’ll look at the sky, where does the sun rise and set, roughly what time of day is it. He’ll look at the ground, are there signs of a water source, what way does the ground slope, are there visible peaks and so on.
Only then does he start to move toward his ultimate goal… civilisation.
A model for better business performance
Over the past few years I have been educated on, and adopted, an organizational performance model (OPM). This has really helped me make sense of a current situation and focus in on problem areas when I arrive on new projects.
This OPM is used by some of the world’s largest companies to understand business performance and improve results. The great thing about the model is its simplicity, but more importantly how it puts everything into context.
When assessing an existing organization, or process, we look at the relationships between each of these areas. You can start anywhere in the model and move clockwise around it to make your assessment. Although I prefer to start at Business Results as these are the results you are most likely trying to influence. Moving back from here you can start to ask why do we see the results we see.
Once your assessment is complete you can begin the design phase, working anti-clockwise around the model.
Business results
The business results, as mentioned above, is about looking at what results you get today. It’s important to understand these so you can measure how they change as a result of the project.
Culture
This describes the values, beliefs and the actual work that people do in the organisation. It’s this that drives the business results. It’s the reality of what people do every day.
Design Elements
The design elements are the structures, such as described processes or org charts, that should influence the business results. Understanding the relationship between this and culture is essential in changing the results. A perfectly designed process is useless if no one follows it.
Strategy
Design elements should be aligned with the strategy. This relationship is often broken as a result of a poorly defined ,or poorly understood, strategy.
Business Environment
The business environment includes factors often out of your control. It may include the market, the competition and the behaviours of consumers. Understanding the business environment is essential before defining an effective strategy.
A simple assessment of these five dimensions will help you focus on the key areas that need attention and the order in which you tackle them. Once you have the results of the assessment you can start working immediately.
If you would like to learn more about how we use the organization performance model (OPM) above please get in contact info@getskore.com.
“The reason most process led change projects fail is that they ignore culture”
I was listening to this during a programme meeting. Some consultants had come to present to us a sure fire way to deliver a successful programme through a focus on cultural change.
My colleagues around the room were all nodding wisely but this statement made me feel a little uneasy. What is a ‘process led change project’… and just because this person says they ‘fail’, do they really?
The conversation moved on to how this approach worked, a ‘process’ they employed to drive cultural change. There were a lot of group meetings, holding hands and singing and somehow the programme would be successfully delivered.
Don’t get me wrong, there were a lot of useful techniques being discussed to help us engineer a culture for success. However, we came back several times to why process was bad. People don’t engage with it, it’s confusing, it’s too rigid and documenting this stuff takes a lot of time.
Just as we were about to throw the baby out with the bathwater I was suddenly inspired by Daniel Pink’s talks on motivation. I remembered a scene where he talks about the contradiction of money as a motivating factor. He describes how money only acts as a motivator up to a certain point. Then its effectiveness drops off and other means are required to motivate workers. He goes on to say “pay enough to take money off the table”. Then you can focus the conversation on other factors such as empowerment, freedom, flexibility, all the things people aspire to once they can pay the rent and put food on the table.
It struck me that process is the same for a change project. Change almost always results in a change to the way we work, the way we do something at work. Therefore process is an essential part of any change.
Just like workers are unlikely to turn up for work in a profit making business without getting paid, a change project isn’t going to work without understanding how things work today and how we’re going to change them tomorrow.
Conversely too much process (too much detail, too much control, too much analysis) will put people off, constrict them, take valuable time away from them. And ultimately impact the successful delivery of the project.
What we need to do is focus on taking process off the table so that the rest of the programme team can focus on all the other aspects of the project in order to engineer a culture of success.
What does that mean exactly? It simply means we help understand the current state in a clear and simple way (even if that means the current state is incredibly complex). Processes should be captured in a way that all members of the programme team, and stakeholders, can use it to communicate effectively.
If process documentation is difficult to read and understand it becomes a barrier and that means it’s still very much on the table as an issue.
The documentation should be at the right level of detail: too much and it becomes too restrictive, too little and it doesn’t provide enough guidance.
Design and validation of changes should involve key people that will help drive the change. If you want to empower people try to get them involved in the design. You can’t include everyone so make sure there is a clear and simple way that everyone can be heard and provide feedback and ideas.
Finally don’t fall in love with the first version of a process you capture. Make use of the freedom to capture multiple versions of the same process and ask people what works well and what doesn’t. The best ways of working will emerge as others share ideas and feel free to discuss how they do it.
Want to learn more about how Skore app can help you take process off the table? Contact us info@getskore.com
We’ve shared before a high level process for implementing software but here I thought it worthwhile spending a bit of time considering how we select the right tool in the first place.
Over the past few years we’ve worked with a number of small to medium sized business implementing new systems. In many cases they have already selected a tool and are simply asking for help getting it setup and running.
It begs the question, if they don’t have time to implement it where did they find the time to choose it?
Choosing the right software is just as important as the implementation. In fact much of the work you do during selection is required for the implementation.
Our experience demonstrates this issue as when asked to implement, without selection, we often discover too late that the new software is missing some critical feature.
Here is our high level process for selecting the right software:
How it works
It goes without saying that a core part of this approach is the capture of process! But only once you’ve defined the objectives, goals, benefits (perceived and real) and, importantly, budget.
These things are essential up front. They may change as you learn more about the solutions you are reviewing but you need something upfront to frame the next conversation.
Work with a number of key stakeholders to capture and understand the current process. This allows everyone to get their concerns, hopes and desires out on the table and documented. In the context of what they do and what they are trying to achieve.
You now have a heap of really useful information that will certainly make your early selection easier. You can start researching potential solutions. Simple things like budget and a rough list of requirements will help you eliminate those that are too expensive or don’t deliver your basic needs.
Getting into the detail
Now it’s time to get hands on with your shortlist. Before signing up to any trials you want to create a couple more resources. Firstly create a list of scenarios. Work with the stakeholders again to understand what are some common and not so common scenarios they deal with.
Here are some example scenarios from a software company looking to implement a support desk system.
User from a small customer calls in to say they have forgotten their password
User from a medium sized customer calls in to say the system is unavailable, they are upset and losing money
User calls in with a question about a feature that is detailed in the help manual
etc
Discuss how these things are handled today and what rules are applied. I hope you are starting to see that you are gathering lots of really useful information here and keeping a track of all the requirements the team have.
It might be worth using Kano mapping to categorise each requirement in terms of ‘must have’, ‘nice to have’ and ‘delighter’.
This list forms the basis of your comparison chart. Create a matrix with requirements down one side and the shortlisted solutions along the top.
As you evaluate each solution against your scenarios mark each requirement with a score (1-10 typically works well) as to how well it met the requirement.
Once the evaluation is complete you can add up the scores. Don’t forget to make notes about other features you find along the way and the general experience.
Create a report
At the end you should be able to present your findings back to the team with both quantitative and qualitative analysis along with your recommendation for the product.
Explain how the solution stacks up against the original goals and objectives. It’s possible that none of the solutions fit perfectly, especially if budget is constrained. It’s up to the business owner to make the final decision.
I hope you find this useful. If you’d like any further guidance please contact us info@getskore.com.
I was on a call and we had this discussion about, supposedly, 2 types of processes:
Process as a “recommendation”: process says A-B-C but you can do A-C-B if you think it’s relevant. Maybe it’s good for a project.
Processes as mandatory instructions: process says A-B-C, you must do A-B-C. It’s best for repetitive processes that need a lot of structure.
Ok… so one is more flexible than the other?
In (1) people use their expertise and experience to know what is best to do and adapt the process to their needs to get the best performance.
In (2) people use their expertise and experience to know that it is best to follow the process in order (A-B-C) to get the best performance.
So to me there is no such thing as a process for “repetitive / structured” activities or a “project process”. We rely on people using the process to know when to adapt and when to comply. The end goal being the same : how can I get the best performance.
We are in the business of creating shared understanding between functions so they can work together in the best way.
Describing a way to do a project as a process helps understanding all the tasks of the project and how they are linked. The role of the project manager is to understand these tasks and coordinate them so they produce what needs to be done.
Traditionally Skore app has been focused on process design and analysis with our view on making it as quick and easy as possible. As we worked with more and more teams they told us that creating documentation with the process information was also very important.
Once you’ve designed a great process it is only really great if your team use it. We provided tools to help create documentation such as image export and save to PDF but we really wanted to do something better.
With Skore app you can create ‘easy to read’ process flows that tell you what happens, who does it and what outcome should we expect from each step. Process flows present the steps visually which makes them easy to follow, especially if the process has choices, alternatives and branches.
On to this we can add further information, detailed descriptions, images, video, audio and links to systems and documents. This means that the procedure is no longer just a static document but provides access to all supporting information presented in a clean interactive flow diagram.
Check out our Learn pages to find out how to build Rich Interactive Procedures in Skore app.
Ever wondered what’s going on after you’ve repeatedly had a bad customer experience with the same company?
How do companies allow themselves to come bottom of the pile in consumer research with the most complaints or the longest call waiting times?
Here’s why that happens and what companies can do about it
These are often larger known brands that rely on a large market to provide them customers. In today’s connected world a bad experience quickly spreads across social media and makes it into mainstream press faster than ever.
So how can these brands allow this to happen? We may think they don’t care, they’ve developed a culture that doesn’t respect the customer.
In the most part that’s not true, employees, managers and leaders want to be successful. The company wants to protect its brand and, in the age of the consumer, it knows it must provide the best service it can to do so.
So why does this keep happening over and over again?
Disruption
We don’t always see the same brands making the headlines, although some are more persistent than others. Generally those that are top of the consumer research ‘worst’ polls won’t be there next year, in fact they are often at the opposite end of the scale.
This shows that most of these organisations take the problem seriously and try to fix it. But how or why do they let it happen in the first place?
These spikes in bad performance are often triggered by a disruptive event. Something unexpected the company wasn’t prepared for.
For example, in a recent interview I had with the Operations Director of a leading energy company he explained that customer growth had taken them by surprise.
“We introduced some new, very competitive tariffs. We expected an increase but nothing like what we saw.” He went on to explain how they made headlines “The number of calls shot up and many calls were dropped due to the sheer volume. This in turn meant customers called in again and things just kept getting worse.”
It wasn’t just call waiting times that were affected. The increase in pressure on the team exposed gaps in their processes. The Customer Service Agents were no longer able to provide the same amount of care to each customer as they normally had time to.
A lot of balls were dropped and this led to a number of complaints making it into local and national press.
Another client I worked with in the telco industry suffered both internal and external disruption. Under two separate strategic initiatives the company created the perfect storm of ‘change fatigue’. The support desk at the centre of these two initiatives was barely able to cope when a major fault erupted on their network.
The call volume spiked and the disruption caused by the two change programmes meant they were unable to get control of the situation and bring the call volume down to a manageable amount over the short term. This led to a number of major customers threatening to move to alternative providers.
In both these cases the short term solution was to throw bodies at the problem. More Customer Service agents Were hired to clear the call volumes and bring things back to normal.
What went wrong
As business returns to normal the old habits return and things carry on until the next major disruption. Everyone breathes a sigh of relief and carries on as they were.
The real underlying problems were acutely obvious just as things got out of control. In those moments immediately before chaos ensues. There is a frantic scratching around to find the answers to questions before we revert to taking the simplest path.
For every individual this simple path can be different. Send it on to your colleague and forget about it. Make something up that sounds plausible. Say what you ‘think’ the truth to be without taking the time to check it. As things get worse we stop asking, we stop seeking answers and just do whatever seems most likely.
When we stop following the process we can’t expect the right outcome to be delivered. In fact we can’t expect the outcome to be the same for each customer interaction.
The vicious cycle of customer experience
When we trip on a staircase the natural reaction is to grab the handrail to steady yourself. But if that handrail isn’t there we grab out at the nearest thing, the wall, a colleague or stranger standing nearby. Like the safety demonstration on an aircraft we aren’t expected to use these things all the time. But they are there whenever we really do need them.
It’s these ‘safety features’ that are often missing in our work that should help us deal with unexpected situations. Like the procedure document created for the last audit and left to collect dust in a filing cabinet, the lifejacket under your seat may as well not be there if you weren’t reminded about it every time you got on an aircraft.
And so this is what happens in a time of crisis. When things start to go wrong and there’s no obvious handrail to grab on to employees will grab whatever they can.
In the examples above this suggests the systems, and therefore the underlying process, were not fit for purpose. They didn’t help the team, they worked against them. This doesn’t fill your team with confidence, especially in times of high pressure.
When this happens it has an impact on employee satisfaction, a key part of delivering a great customer experience. If your front line staff aren’t happy it’s highly likely that will eventually affect customer experience.
Take this together with a worsening situation where the workload is going out of control. Add the fact that customers are becoming more and more frustrated as they are made to wait in endless queues listening to the same maddening holding music over and over and over.
A frustrated customer and an inability to effectively resolve that customer’s problem creates the perfect storm or vicious cycle. The vicious cycle of customer experience is when poor customer experience and low employee satisfaction reinforce each other in a downward spiral.
The image above shows the various interactions in play that can lead to the vicious cycle. Keeping all these things in balance is important to maintain a healthy team.
Being prepared for disruption
As we have seen, under normal conditions a balance is found in the system allowing customer experience and employee satisfaction to stay relatively constant. However, the more ‘brittle’ that system is, the fewer safety features it has, the more likely balance will be lost in the event of a disruption.
Other elements in the system come into play. Being prepared for a disruption means making sure those elements are working. The better they are set up the more likely you will keep balance in the system.
The system diagram has been simplified and there are other aspects that can affect the balance but this shows those that are relatively easy to deal with. It provides us with concrete actions we can take to prepare ourselves for the worst. It tells us what a handrail should look like.
Ensure processes are well designed
Although a well designed process is only part of the story it is the essential foundation.
Are the processes designed to deliver the outcome you expect?
Do those outcomes align with business objectives?
Is it feasible to deliver that outcome with the resources you have?
Do your systems and tools support the process?
Ensure processes are easy to understand
A well designed process needs to be easy to follow. Having your front line staff poring over abstract architectural diagrams, or detailed text based procedure, during a time of crisis is hardly going to make things easier.
Can the process be easily read by your front line staff?
Have you tested these with a broad sample of employees?
Are they unambiguous?
Do they provide enough flexibility for employees to make their own decisions?
Are they kept up-to-date?
Ensure processes are easy to find
Just like the handrail, processes need to be easy to find so that staff can reach out and grab them easily in times of crisis.
How do employees access the processes?
Are they easy to find?
Have you tested that using User Experience (UX) tools?
Do you run regular ‘safety demonstrations’ to help employees remember how it works?
Ensure processes are easy to maintain
If processes are difficult to update then the cost of doing so will quickly become prohibitive.
Do you have a system that makes it easy to update?
Are processes stored in a single place?
Does the process documentation have appropriate governance? (not too much or too little)
Need help with your processes? We can provide a review of your current process documentation based on the above criteria to see how well prepared you are to deal with the next disruptive event. Contact craig@getskore.com for more information. Want to learn more about customer journeys? Check out Instrktiv.
Lack of clarity around roles and responsibilities within an organization, or project, is one of the most common problems we come across. Skore makes it very easy to clarify responsibilities, to define and agree who does what and communicate that to the team. Whether you use RACI, or the alternative RATSI, you can design work and clearly identify the level of responsibility for each person.
This video shows how to configure and use responsibility analysis in Skore app. (Note. this video has been created using our Skore app Professional beta. Although it looks different all functionality is available in all versions of the product.)
Org design is an essential part of any transformation project. A good org design process is also incredibly valuable for building business cases, understanding hiring requirements and even performing training needs analysis. Over the past few years we’ve been using and developing our own design process that we’d like to share here.
While we use, and recommend, Skore app as a support tool in this process it can be done with many existing tools available to the team. Skore app really accelerates the process through its integrated reporting capability. This makes it one of the best tools we’ve come across for designing the work processes, roles and job descriptions in an iterative org design process.
Have you allocated too many resources to the job or have you allocated to many jobs to the resource? Both of these situations are painfully common when implementing a change program. Sadly this results in a miss of either cost saving, when there are too many resources, or efficiency/quality benefits when there are not enough. Some of the most common benefits cited in change programs.
In our experience a key reason for this is due to the design approach taken early on in the program. Typically we start defining the organization structure, the roles and reporting lines either before, or in parallel, with the process design. It may seem logical to do this when you want to define who does what in the process. However it is this approach that causes problems of over allocation and a focus on silos over integration of efforts.
The problem with this approach is that you define roles based on limited knowledge of what the organization actually needs to do. You know it will be doing some marketing, so you add some marketing resource. How do you know what roles to add? Well in another company there was a Marketing Director, three Marketing Managers, a Creative Designer, a Copywriter and an Administrative Assistant. Now you can go start hiring these roles while the design team define the processes. Except how do you really know what sort of person you need and how many of them?
OPM, a model for success
The Organizational Performance Model (OPM) follows the reverse of this approach. Once the ambition and objectives have been defined for the organization the focus of the design team is purely on the work required to achieve those objectives. At this stage the roles required to execute the work are ignored and work is designed in a hypothetical ideal environment.
The benefit of this is that the team is free to design the ideal process to achieve the objectives. So when they do allocate resources they can evaluate to what extent it is even possible to reach those objectives. As opposed to designing a new process based on existing resources which may or may not have any chance of actually achieving the objectives.
A further benefit is that resource allocation is much more efficient. Now you are designing roles to fit the work rather than the other way round. So ultimately you will be assigning people to these roles based on the work required to reach the objective rather than general skills in a given area such as ‘Marketing’. The follow through is that job descriptions and job postings are directly related to the performance of the organization and not some industry standard. Meaning clearer recruiting guidelines and better fitting candidates.
While implementing designs throw up unexpected challenges, that often have an impact on resource allocation, our experience over the past three years has repeatedly demonstrated to us that this approach is both more efficient in application and has higher rates of success in realizing the projected benefits of the program.
If you would like to know more about OPM and how we use it please do get in touch. Reply below or email us info@getskore.com.
If you run a lot of workshops and are confident in what you do then this post is NOT for you. However, if you’re something of a workshop novice then I believe you will find something useful here.
Why run a workshop?
Workshops are a fantastic way to get key people together to figure out problems and design solutions. They are highly collaborative, everyone should be equal and encouraged to freely express thoughts and ideas.
Key decision makers should be present as well as subject matter experts and people affected by the problem or design.
In this way the true issues can be drawn out in an open environment and decisions on how to proceed can be made there and then. Everyone is on the same page.
When do I run a workshop?
There are many reasons that drive the decision to run workshop. It could be that you need to make a decision quickly.
A decision making process has ground to a halt and you need to kick start it.
You need to get a fresh perspective on a problem or need to get buy-in for a proposed change or improvement.
Workshops can, and should, be engaging, open, fun and innovative. That can be a high bar to reach if you have never run one before!
It’s all about structure
For some people running workshops comes naturally, they instinctively know how to start and get people talking about the issue at hand. They guide them effectively, knowing what questions to ask and when. But for most of us this is not the case.
When I talk about structure there are two things you need to consider. Firstly there is the structure of the workshop as a whole. This is the agenda. How do you open, how do you close and what are the ground rules. This is repeatable and you will use this in pretty much every workshop you do.
Secondly, and just as important, is the structure of the discovery approach. Are you using Digital Discovery or a traditional approach. This is going to take up the bulk of the time you are actually in the workshop.
The approach, or methodology, you use is going to guide you and the participants through understanding the problem you are addressing. It will then help you arrive at a solution.
The agenda
I don’t want to focus too much on this, there’s plenty of guidance out there on how to run workshops from this perspective. My main piece of advice would be to communicate regularly and openly with the participants and any other stakeholders that have an interest in what you’re doing.
Regular communication provides a space for any concerns and reservations to arise and be dealt with before you get down to business.
Firstly agree the objective of the workshop with the participants well in advance.
On the day of the workshop make sure the room is prepared and all the equipment you need is there and working. You don’t want to waste time trying to get a projector to work or looking for whiteboard markers while your participants sit round and lose concentration.
Make sure you do introductions as required and reiterate the objectives and timings of the session.
I’ve found ground rules an essential tool and these will vary from workshop to workshop. My basics are; Everyone is equal, one person speaks at a time, unresolved discussions stop after 5 mins and switch off mobile devices.
these out and agreeing them at the beginning will get you respect and make it look like you really have done this before!
At the end of the workshop summarise what you’ve done and revisit the objective. Review and agree any actions and then follow these up afterward.
The discovery approach
This is the bit that they don’t tell you how to do. Most companies that offer workshops as a service have their own methodology and tools that they use. It’s often their competitive advantage so are not that keen to share with you.
This is going to take the bulk of the time and where the value is going to come from. Workshops can seem unstructured but the facilitator is normally guiding you along a path. Structure is important because it gives you a handrail, it tells you when things are going off piste and when it’s time to bring it back.
It may seem counterintuitive to try and place structure on an innovation session but that’s exactly what you need to do. Having a framework that everyone understands, and agrees, allows them to forget about it and focus on the problem.
With a strong and confident facilitator the group will naturally relax as they assume the facilitator has their backs covered. If you don’t think you’re that person then use the projector or whiteboard (or both) to outline the path you’re taking and the progress being made. It could be slides, but don’t turn it into a presentation, the participants need to do the lion’s share of the talking.
You’re only there to ask questions, if nothing else the methodology you choose will inform the questions you need to ask. Who does that? When does it happen? Why do they do that?
The approach you use may depend on the type of problem your are investigating. For example, improving how something works is best done using a process notation to provide the structure. It will guide you to ask the right questions.
When designing new organizations and products you may want to use something such as the Business Model Canvas. This simple, yet powerful, approach has allowed many businesses to literally disrupt whole industries as the structure it provided enabled them to see new opportunities on which to build their business model.
So what type of tool / methodology do I need?
In this case I would suggest not looking for guidance on running workshops but on problem solving. There are many tools available, some are free, some are paid and many can be learnt from books.
In my experience process is usually a good starting point. Everything in business is part of a process. Processes are what we do and the outcomes we achieve. Understanding the process that surrounds your problem will provide valuable context. It may not lead you directly to the source of the problem but it will lead you to the right neighborhood.
What tools do you use to help you run better workshops? We’ve designed Skore to be used live in digital discovery workshops to capture processes, and related information directly to a digital format. This ensures that what you agree in the workshop is what everyone sees later on. Skore also includes the guide rails you need to keep you true, it asks the questions for you, what happens, who does it and what are the outputs. Click below to start a free trial.