Postcards From the Edge of GBS: Have a Simple Method, Used by All

Complex design work needs a complex approach, right? Wrong, of course! But it does need to be sufficiently organized for progress to be made at an acceptable pace. 

This is the third post in a series on building GBS solutions, or if you prefer, building capabilities as a service. Such solutions combine all the capabilities of a GBS organization to help colleagues in business units answer problems or take advantage of opportunities. For example, it might be building scalable services to lower costs or support growth in areas such as digital marketing, analytics, technical processes, or compliance work. Although the examples I lean on in this series are from the business value chain, I think these techniques can also help with more traditional GBS work scopes, particularly if areas are proving problematic to transform. 

In the previous post, I advocated for having a small but well-formed, specialist solution development team. This post is about the method that this team uses to do the work. It isn’t just their method, it’s used by the whole GBS organization for understanding, designing, implementing, and embedding solutions that meet business needs.

I’ll give you a clue on where we’re going, this isn’t rocket science, and it isn’t that new. The method I describe has been honed by shared services and outsourcing teams over at least three decades. It’s based on common-sense practices, such as clarifying intent, breaking down the big question into sub-components, writing down the answer, socializing, and getting ahead of issues.   

Why a solution development method is necessary

Despite the need for simplicity, this is not easy work, and it is important to have a clear approach. If the GBS team is to be credible as a quality delivery organization, capability builder, or transformation partner, or whatever similar thing you have in your GBS vision statement, you need to be able to do this with few mistakes. Some of the key reasons for having a method: 

• The business need is ambiguous – the GBS organization must lead their colleagues through the clarification of intent and requirements, demonstrating the art of the possible
• Many people and groups will need to be aligned on the way forward – both the colleagues using the solution and those coming together to provide it
• There is almost always a need to move fast – faster than would be possible without a pre-defined way of working
• The costs increase as you progress – at the beginning it’s a small project team, at each stage the costs and commitments grow, it’s important to stop or adjust if they are not justified
• GBS organizations should aspire to a common approach across all functional groups
• The outcome needs to provide a great experience – so that colleagues want to adopt it. 

All these are possible with a commitment to use and continually improve a common method. 

What should be the features of a method?

When I started in my last role, our GBS team had a plan and a small leadership group, but not yet any operations. We had to work out how to build our GBS from scratch.  One key step was to design a methodology to help us shape solutions and manage transitions. We called this method GATE, and it was used more than 1,000 times to govern changes; small things, such as adjusting existing services, and large programs, such as transforming a function, or prioritizing and building multi-domain capabilities, such as data management. 

Although I will not share the details of how GATE evolved, I will set out the features that I think are important if I were building a similar methodology again. I would imagine that if you have got this far in this article you are an experienced practitioner, and you may recognize a lot of this from industry best practices.

Key components: 

• Phases which every project goes through. It is important that the right work is done in the right order, to prevent waiting time (e.g., for compliance approvals), ensure a focus on the critical path (e.g., sourcing, technology, and hiring, all have long timelines), and prevent rework, where things were started on the wrong basis. I think four phases are sufficient, although in GATE we had five.   
• Stage gates between each phase with checklists. There needs to be a clear beginning and end for each phase, typically marked by a steerco. Each stage gate is critical, where the team is seeking approval to commit the organization to work and cost. It is important to be clear when deciding to proceed, or when rejecting. We developed checklists for each gate, that set out exactly what was expected at each point. The meeting documentation served as records of the control points. 
• Template and example deliverables for each phase. Documentation is an important part of solution development. It is important to be clear on what is being built – both so to get buy-in, and to serve as a record of intent once the solution is operational.   
• Links to other methods. Many companies have existing methods, such as a project management approach or change management framework. The solution design methodology needs to fit neatly with them, with people understanding why it is necessary to have a separate approach for this specific purpose. In our case we drew those links, and embedded design thinking and agile ways of working into the method, as those became more commonly used within the company. 
• A process for updating the method. This is key. We signed off Version 1.0 of GATE before we had implemented any solutions. We updated the method at least once a year through formal reviews, building in learnings from the field and extending our checklists and deliverables. For example, we learned which compliance activities had the potential to slow us down, and we made sure that these were considered early in the process. Our internal auditors noted how well we controlled our control, so it helped demonstrate that we knew what we were doing. 

Key impact: 

• The stage gates become tools for driving collaboration. As is it adopted, and people see it working, the whole organization starts to understand why it is important and what is required. This helps people collaborate at important points, such as the design approval stage gate.    
• The magic is not in the phasing itself but in having the discipline to stick to it. This does not come easy.  At first people perceive bureaucracy, but what wins them over is that it works in practice. In our team, colleagues saw that using GATE increased our chance of starting and finishing work, safely, compliantly, and in a timely manner. They recognized that we made mistakes when we did not follow it. 
• Stage gate check-ins helped manage the workload. GBS organizations can do many things to support their businesses, but they are only valuable if the project work is finished, and the solution launched. Demand for solutions often outstrips supply, so GATE helped us prioritize and protect the team, and saved wasted effort by pausing or stopping projects where the conditions were not right. 

The design phase requires a solution planning framework

The design phase is about taking the ambiguous demand and turning it into a coherent plan that people can buy into and agree to build. The output needs to have sufficient clarity and detail to enable a sign-off and the start of implementation. This is achieved through a solution planning framework. The approach I propose has been formed by from my time building outsourcing solutions, as a management consultant, and as the head of Solution Development for a major GBS organization. It contains complementary ideas from design thinking, business architecture canvass design, lean, process design, transition, change management, and agile. 

1. Clarify the need. As most solutions start with ambiguity, the method helps confirm what is really being asked.  It clarifies the context, intent, pain points, ‘must achieve’ list, timing, and scale.  Also, the benchmarks and cost envelope that we need to work within. This could include looking at outsourced options, to understand whether external solutions would be better. A ‘solution design’ rather than ‘lift and shift’ approach, means you can design to cost with a zero-based budget. 
2. Design the experience. Using design thinking techniques to imagine and set out the desired outcome as an experience, a set of services, and guiding KPIs to measure progress.
3. Design the process. Process is at the heart of a business solution. Of all the solution components, it is the best ‘key field’ for a design and can be used to organize other elements. When I review solutions work in trouble, it is often a problem with the process – maybe it is not clear, or too detailed, or expressed in technical rather than business language. The process should be set out in a way that the front line of the business would understand and care about.  
4. “And then a miracle occurs”. I repeat the punch line of the famous Sidney Harris business cartoon, but I will not go into the detail of how to build the rest of the solution, other than to share these points for GBS leaders:
   1. The functional professionals in your team already know how to do this, but they may not know how to do it together. You must provide them with the structure (the method) and the backing (leadership coaching and time) to work together collaboratively.  
   2. The order of components suggested on the chart work well when used iteratively. For example, a ‘make vs buy’ decision is best made before planning the roles and organization – despite this, how many of you have seen stakeholders start with an org. chart?  
   3. If this is to work across GBS domains, there cannot be an opt-out by some teams. There should be no ‘war of methodologies’, where teams have their own standards and find it hard to see past them. If you are building a multi-team business solution, you need to allow your solution development method to ride above and incorporate those other methods, and this needs to be supported from the top of GBS. 
5. Frame the plan. The solution should contain enough information to enable you to start (if not done already) the risk and change management activities needed to get the solution to stick and work. This includes being clear on the accountabilities for each activity, especially when working across geographies.  

The impact: 

• You move from the generic to the specific. To build a solution, you need to move from examples to a precise scope and set of actions. As the design is reviewed multiple times, the detail becomes more accurate and complete as work progresses. The idea is to go through the  solution components on each pass, the first time through there will be many assumptions, in later passes the detail will get filled in. This allows progress to be made, even where key bits of information are not yet clear.
• Documentation is a pain, but it is important. A typical solution plan might have 100 pages of detail, but these will be necessary to bring clarity to the work. It is important to write down a design in a Solution Plan, so that others can check, follow, and build from it, including providing an invaluable fall back later when you come back to review progress and approach. Despite designing 100s of solutions in my career, I find it impossible to hold the details of just one in my head!    
• The solution plan document is an alignment tool. In organizations where people are ready to say: ‘I support this but it will not work here’, the solution plan can help you understand and document their concerns, and then decide what to do about them. If people feel listened to, they are much more likely to get on board. A key technique I use is to break big questions down into more specific elements, to help isolate and recognize peoples’ true objections (e.g., you could break scope into business unit, geography, functional, customer type, to help clarify what the concerns are). 

My goal with these postcards is to give you lessons learned from the front line and tools you can use. I think this one does it, but there is work required fit these methods into your specific organization. If you go down this path, do spend time thinking through why and how you will approach the work, and please reach out to me if you want to talk it through. I wish you the best of luck and would love to hear about your successes of building business solutions. 

Next time, we will look at the identification and prioritization of candidates for solutions.

Tim Palmer, Basel, September 2023  
tim.palmer.gbs@gmail.com