Category: News

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.)

Find out more about what our Digital Discovery platform can do for you. Request a free trial here

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.

http://www.slideshare.net/SkoreLabs/build-better-teams

If you have any questions or would like to learn more about this approach please do get in contact info@getskore.com.

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.

Start Your Free Trial Now

Using Service Level Agreements

If you’re a service provider you probably use Service Level Agreements (SLAs). You want to give your customers confidence that, should anything go wrong, your team will do their best to resolve it within a given time. You define a service level that you feel confident you can meet. Your customer can then plan around that SLA in case the worst happens.

What happens should you fail to restore the service within the period agreed? In many cases penalties and compensation come into play. These will form part of the SLA and act as an incentive to get things fixed well within the agreed time. Some customers may be losing significant amounts of money while your service is unavailable, they’ll want to try and recoup as much of that as possible.

Problems measuring SLA compliance

It surprised to me, then, to learn that SLAs are breached a good deal more often than you may think. And in many cases companies are not pursuing the compensation that they are due under the agreement. For one provider I worked with, the fact this happens was something of a relief. For around 40% of inbound calls we were unable to accurately and confidently calculate the correct SLA. It meant for these calls we didn’t even know if we had breached the SLA or not!

This exposed the company to a significant financial risk, the fact that many customers didn’t pursue compensation had left them complacent. All it would take is one reasonably high profile case and they would have seen a significant impact on brand and profit.

Root cause analysis

It wasn’t that they didn’t want to invest the time trying to fix it. It seems many people had tried to resolve the problem. Various change projects interfaced with this part of the business and all had tried to get to the bottom of why the SLA could not be accurately measured at the point where the customer called in.

I spoke to several people that had attempted this in the past. They had all got so far and had come at it from different angles but didn’t quite join up the dots. It appeared that most of the pieces of the jigsaw were there but it wasn’t clear how they fit together.

Creating a life cycle diagram

To investigate the issue we decided to treat the SLA like any other process and visualize the steps that it went through until a customer ended their contract. We created a  lifecycle diagram of the SLA, from design through to completion.

Services are designed centrally and SLAs are defined by the Product Management team based on a typical implementation. These services are advertised and then sold to customers. Customers use the service and report problems and finally they would stop using the service and close the contract.

We had a five step lifecycle diagram that formed the framework for our analysis. This was a simple diagram that was easy to review and confirm with the various teams involved. Next we took each of those steps and broke them down into more detail. We were now looking at how the SLA was communicated from one team to another by visualizing data flow.

Visualizing data flow

The SLA was documented and entered into the product catalogue. When a new customer came on board sometimes they negotiated different rules regarding the SLA. When the product was entered on to the order management system not all the SLA options were available so operators sometimes had to enter custom SLAs, if they remembered. That data was then imported into another system. The developers of that interface were unaware that customers may have agreed custom SLAs so these were often overwritten.

As the process progressed we saw more and more if these types of issues. All the different conversations I had had started to fit together. As the SLA data was passed from one team to another there was a known issue. Each time this was dealt with by a manual workaround. Each individual team felt they could deal with this effectively using these workarounds.

Shared understanding

It wasn’t until we started to build the full lifecycle visualization that it became clear the extent of the problem. While the instances of an incorrect SLA being introduced at each individual point was low the fact that there were so many places this could happen had an amplifying effect. As a result, when the symptoms presented themselves at the point the customer called in, it was impossible to see a pattern in the data.

The visualization consisted of 6 fairly simple process flows (2 of which can be seen above). One for the high level view and 5 which each represented the 5 steps on the high level. Presenting it in this way meant that all the teams involved were able to easily see where they contributed to the issue. And more importantly gave them a framework on which to build a solution.

The solution was fairly simple but the changes required would have made no sense without the context of the overall picture provided by the visualization. It was easy to reach agreement on what needed to be fixed and how it would impact each team. All it needed was a simple structured visualization to bring everyone together to fix what could have been a very expensive problem indeed.

Creating a visualization like this in Skore is very easy. It’s just as easy to share securely with other team members and have them comment on the diagrams. This provides a single place that describes the flow that can be accessible to everyone. 

Start Your Free Trial Now

Every executive and / or business owner will know just how hard it is to put their vision into practice. The larger the organization, the more moving parts, the harder it is.

But the challenge isn’t limited to large organizations, even with a handful of employees you have to take your vision and strategy and have your team turn that into action. They’ll all have their own way of doing things which can change your original intent.

The Process Excellence Network have written about this challenge and share the experience of many companies in this study. One of the most important findings from the survey is that process professionals cited the linkage between process and strategy as their most important challenge.

“It is a rare company indeed that is able to consistently get the balance right between having a clear vision that is understood by everyone in the organization and that is supported by the right systems and processes to achieve the results that leadership is looking for.”

Based on their research it’s clear that the World’s largest enterprises are continuously struggling with this. But this is a challenge that any business faces. Being able to effectively demonstrate how the work we do everyday aligns to the vision and goals of the organization. How do I, as a team member, know that my work is contributing to those goals? How do I know I’m doing the right thing everyday? It’s as fundamental as that!

Translating vision and strategy into action

Part of that challenge is in the translation of the vision and strategy into actions that are recognised and understood by everyone. We’ve heard of executives locking themselves away for days at a time to ‘strategize’. Usually followed by a recorded presentation published on the intranet and then the slew of strategic transformation programs manned by external consultants and expensive experts. Presently the noise dies down and things continue as normal, unless of course you happen to be on the receiving end of one of those programs!

For the rest of us we just turn up everyday and do what we did yesterday until someone or something shows us something better. So how do we fix this? Well the good news is that if you’re a small(ish) growing company it’s a lot easier… but just as important, if not more so, that you get it right. The best CEOs will communicate the purpose of their organization just as effectively with their employees as with their customers and shareholders. Knowing what we’re all trying to achieve is the important first step. But operationally translating that into action is the big challenge.

The magic of shared understanding

At Skore we believe one of the key elements of success is shared understanding. When everyone in the room has a shared understanding on a given topic, such as the company vision. Then, at least, we’re all pulling in the same direction. Through simple process visualization Skore helps teams to reach a shared understanding on how things get done. But when it comes to aligning process and strategy Skore has a magic trick up its sleeve for this very situation.

Communicating the vision with Skore

You need to be able to tell the story of your organization, i.e.  what it does do at a very high level. Use a handful of boxes that tell us the key activities performed. You design something, you develop it, you market it, you sell it and you support it (that’s what we do at a software company at least!).

Now you can start to consider how your strategy will impact how you work. Will you need more people? Will you need to increase development velocity? Are you doing the right type of research? Are you doing the right type of marketing activities?

These are all questions that hang over one or more activities on your high level view. Skore allows you to take each one of those activities and explore it in another level of detail. You literally drill down into the detail and ask those questions again. Given this new level it may throw up further questions. And again you can delve deeper into the detail.

Each time you go deeper you get the relevant people involved and you keep the questions to hand so that everyone has a shared understanding of the impact of the change and why you need it. It’s telling a story that goes down one level of detail at a time keeping the relevant people informed without overwhelming them with information.

With Skore you can quickly understand the impact of your vision and strategy on your processes and communicate those effectively to the whole team so that everyone knows what they need to do in order to succeed.

Start Your Free Skore Trial Now!

Process mapping is a brilliant way to visualize how things work. With a visualization it’s much easier to share and understand complex ideas. Sometimes it can be very hard to identify problems and understand their true nature. The act of creating a process visualization is a very powerful way to understand those problems and design better solutions. However, doing this for the first time can be very difficult to get right. Here are some of the common problems of process mapping and how Skore helps to overcome them.

What are the common problems of process mapping?

If you are using process mapping to solve business problems you will need to consider the following areas:

Methodologies and approaches

One of the things that makes process mapping so powerful, as a visualization technique, is the structure and semantics it provides. There are many different approaches and notations such as the Business Process Management Notation (BPMN), Event-driven Process Chain (EPC) or the Unified Modelling Language (UML). These provide extensive palettes of shapes and icons that represent different types of activities and events. Processes can be described in great visual detail and analyzed in depth or even handed over to an interpreter to create custom software applications.

The problem with these approaches is in this very detail. The documentation is extensive and it takes time to learn and master this visual language. This makes it very difficult for a small team to quickly pick up and run with it effectively.

Tools

There are two categories of tools; the general purpose diagramming tools and specific process mapping/modelling tools. General purpose diagramming tools are low cost, often free, but do not prescribe a specific approach. They are great for fulfilling many diagramming needs but when it comes to process mapping you need to understand and apply a specific methodology. These tools will normally provide templates and palettes with all the shapes required but with no rules or integrity checks to ensure you’ve applied it correctly. So while these tools offer a low cost of entry you will still need the expertise of the methodology.

There are many software tools that are designed specifically for process mapping and these are normally built to support a specific approach such as BPMN. As a result these tools have comprehensive support for the approach and therefore require a very good understanding of it before they can be used. Alternative specific tools are aimed at large enterprises and are often priced accordingly making them out of reach for most companies.

Experience

Given the complexity of the approaches and supporting tools it’s clear that successful use comes with experience. And experience doesn’t come cheap. If you don’t already have these skills on your team the chances are the only way to get them are through expensive consultants. As an external consultant it can take time to get under the skin of a new customer. At the usual day rate the cost is going to rack up pretty quickly.

Conclusion

So while process mapping can be an extremely powerful way to solve problems, and improve your business, it’s not easy to get started. The approaches are comprehensive but complicated. Good skills and experience are required to make it work. And the current set of available tools are designed to support the experts not those starting out.

Skore has your back

Trying to help teams overcome these challenges is why we created Skore. We were those consultants, we learnt the methodologies and we learnt how to apply them effectively in a variety of different situations with teams of all sizes. We learnt that we could achieve most of what we needed using only a few core components of a methodology. It’s not so much about applying all the available tools but asking the right questions that makes the real difference.

So we embedded our experiences into Skore. You can only build simple flows based on the most important components. When you put a new box on the canvas in Skore it asks the most important questions to ensure you can accurately visualize how things work. Describing how something works, in a way that people will understand, is like telling a story. So in Skore you describe how something works in a very quick and easy way. Then if you need more detail you simply create a detailed view and explore that part of the story.

With Skore you don’t need years of experience, nor do you need to learn a complex methodology. You can create simple and engaging process maps in order to visualise how things work in minutes.

Get In Touch

The democratization of process

Our focus was always to improve communication between diverse groups within any organization to drive successful change. Skore was intended to be easily accessible to any audience, quick to get going and easy to use. We designed it to help clarify complex situations and make them easier to understand. Anyone, regardless of their area of expertise, can use Skore in this way.

While discussing this with a peer recently he commented that Skore is facilitating “the democratization of process”. It sounds pretty grand but he pointed out we were making process accessible. It was no longer about comprehensive documentation, that is rarely used, but a dynamic view of the organization today. Anyone in any organization can describe how things work using a simple common approach. And as such everyone has the ability to easily describe and share business problems and their solutions.

Successful change

I had this in mind while reading this article from McKinsey. The authors argue that successful change is about ‘Change Platforms’ rather than ‘Change Programs’. From my own personal experience in Business Transformation programs I’d have to agree with a lot of it. The front line, the people most impacted by a change, almost always hold the best insight into whether it will work or not and what needs to be done. Without early involvement from the front line it will be as hard as hell to make any change stick, let alone result in successful change.

What the article describes as a solution is not unlike how most small companies tend to operate these days. They have no perfectly defined vision or end state. Instead they head in a certain direction, learn as they go and change course according to what works well. But the key to making an approach like this work within a large enterprise is bottom up engagement.

Making sense of chaos

The problem is when a change is necessary the front line can feel, well a little chaotic. It’s hard to know what to focus on and hard to know exactly what is broken or where change should be made. There needs to be a general agreement between members of the team about what’s broken and what needs fixed right now.

In this sort of situation comprehensive documentation is no use. By the time an accurate model had been built things will have changed whether the team intended it or not. What they need is a rapid way to get to grips with what’s happening right now and make a decision on what to do next.

If members of the team were able to quickly capture a simple view of how they perceived things worked around them, they could quickly compare that with colleagues. The convergence, or divergence, of these views would very quickly start to highlight problem areas and even suggest solutions.

Creating a change platform is essential but simply adding more communication channels is only part of the solution. The front line need a simple way to make sense of what’s going around them and articulate their ideas to the rest of the team.

Use Skore to rapidly capture processes in live workshops in a way that engages everyone in the team. You’ll get the answer faster with more people on board.

Start Your Free Trial Now