Postcards from the Edge of GBS: Move Fast and Finish Well

Add bookmark
Tim Palmer
11/02/2023

GBS

Let’s imagine that our executive committee has asked our GBS head to provide improved meetings services for the company. It’s part of a drive to embrace hybrid working and have better in-person meetings. Among the solution elements are AI-assisted booking tools, enhanced physical meeting spaces, the development of a network of in-office studios, a concierge service for town halls, a change management program to explain the approach, and potentially a reduction in travel and agency spend to help fund it. This will require several of our GBS functions to work together in concert; at least our facilities, IT, HR, and procurement teams, and probably also some business process delivery people, compliance, and ESG as well.

This demand has gone through our portfolio management process and has been prioritized for delivery. We have assigned a talented and experienced solution development leader from our specialist team to manage the project. How then, do they organize to do this work well?

Here's a few things that must happen straight away:

  • Clarify the demand, becoming as specific as possible, to enable the specification of the solution
  • Confirm the business case at a high level, and determine the cost envelope
  • Build the team, mobilizing accountable people from the functions that need to take part, and ensuring that they understand the approach
  • Charter a steering group
  • Plan and kick off the work
  • Start the change management. For something like this, visible across the organization, the enterprise change management starts now.

This picture is one where expectations are high, there may be some excited over promising by senior stakeholders, there will be a natural impatience to make progress, and there may be some egos to placate. This adds up to quite some risks as the work gets going.  Set against this is that even apparently simple things can be difficult, for example even getting the right people assigned to the team might take several weeks.

In the rest of this post, I want to talk to you, not as the Solution Design Lead, but as the GBS leadership team, enabling and supervising this work. The project team will have good intent and will do their best. They will drive the work, make mistakes, and hopefully come out the other end with something that works. My question to you, is what are you going to do to help make it so?

Here are three techniques that increase the chance of success:

  1. Set clear and realistic timelines
  2. Move with agility and pace
  3. Follow-through, embed, and revisit

Technique 1: set clear and realistic timelines

It might be a bit old fashioned, but there is nothing like a bit of management expectation setting to get stuff to happen. Setting timelines creates pressure, but as long they are realistic and clear, it will help everyone get going, progress, and ultimately get to the end.

There are two tendencies that I’ve noticed in myself (I’m sure many of you will recognize it in leaders in your organizations):

  • Think that once it’s been talked about in a leadership team, it’s happened.
  • Be impatient when the answer does not appear after the first two months.

It is frustrating, but complex stuff takes time. You may be able to identify the team in a couple of weeks, but there is often a delay between the boss assigning a person, and them showing up on the job. Any sourcing, IT development, or fresh hiring is likely to take about six months. Risk and compliance reviews can slow everything down at the last minute, if not considered early in the process. 

If this work is worth doing, we should do it properly, and invest time in a design activity where we actually ‘go and see’ what good looks like, before setting out how we will make it happen.

So, as leaders enabling the work, we need to set realistic but stretchy timelines. Making a lot of assumptions, for a project like this, I would expect a kick off meeting within the first month, and a design approval steerco three months after the kickoff.

  • An outcome from the kick off would be a full assessment of risk and compliance, so the required actions can be built into a baselined plan
  • Design sprints would start straight after that, lasting for about 12 weeks, requiring the team to be present and engaged
  • Regular stand-ups would be held (2-3 per week), including some where the steerco attends (every 2 weeks).

In this situation, I would put the design approval steerco in the diary right at the start and make it very hard to move. With something as complex as this, there is the potential for the design work to never end, but with a hard deadline, a solution will be ready, at worse at an 80:20 level. If there are still open items, the fixed checkpoint will help settle the design. The steerco can always ask for some further sprints if they are needed.

Technique 2: Help the team move with agility and pace

It is important that solutions are well designed and thought through, but to remain relevant, they must move at the speed expected. If decisions take too much time, reasons can always be found not to continue.  Solution development leaders need to push the pace and get the whole team to take leaps of faith together. The key is to use agile techniques to break complex problems down, get through the steps, act, and adjust if necessary. 

Cross-team solutions development work requires the building and maintenance of consensus. This can be exhausting. I have seen solution leads exasperated when steerco members fail to turn up, sponsors change mid-stream, or they find their colleagues questioning things that were agreed three months ago, because they have either forgotten or more likely didn’t like the outcome the first time.

In our example case, we are supervising and supporting the solution team. We need to watch for signs that the work is not moving quickly, and be prepared to step up and help resolve the causes of a lack of pace, such as:

  • The core team is overloaded
  • There is not enough technical (business and other areas) expertise in the team
  • The team is trying to make the solution too perfect
  • Critical path items (e.g., compliance, sourcing, IT, hiring) are getting in the way
  • The GBS funcitons are not playing well together
  • The solution lead is not suitable for the job – rare, but it does happen.

Solution leaders need (I stress this) authentic coaching from senior leadership to help them think through the complexity and plot the right path. Here are five open questions that we can use to help check the situation and support solution leaders through their issues:

  1. What is your honest forward-looking status? This should go together with an open approach to status reporting that is about risk to outcome rather than what has been done already. In our team we knew we had problems when our status reports were all GREEN, and right from the top of GBS, our leadership set the standard that RED reports were expected without personal risk, if they were accurate.
  2. Take me through your solution story, using your current solution plan. Using the working design pack specified in the methodology, allows you to see how complete the story is and where the major gaps are, without adding to the team’s workload. It will help them go back to the beginning, to their clarified questions, the desired experience, and the guiding KPIs. This helps remind them why we are doing the work and allows you to question whether we will meet the original intent.
  3. When is your next gate review (steerco)? People who get stuck sometimes delay the formal reviews, preferring to sort out issues before sitting in front of a senior team. This is dangerous; a monthly meeting can move to two monthly or longer and issues can go unaddressed. You can follow-up by asking for the agenda and offering help to prepare.
  4. I cannot move on because… If they report a blockage, make an Ishikawa analysis (Herringbone) to help think through the interrelationships between solution elements. For example, I cannot move on with the software prototyping because we have not yet chosen the preferred tool, because the procurement team is still in negotiations. You can use this to work out how and where to break cycles of inactivity, by making assumptions and moving on.
  5. What stakeholder issues do you have? The stakeholder lens is different from the substance of the solution, and it can be the hardest to work through. Through this you can also access personal, political, behavioral, and commitment issues. Follow-up questions can be putting on the shoes of the other people, questioning their motives, and working out tactics to influence their approach.

Technique 3: Follow-through, embed, and revisit

Once the solution is designed, it needs to be implemented, embedded, and continually improved.  Our role as GBS leaders is to ensure that:

  • The focus stays on the work to the end
  • The change management gets fully executed – including in this case, our active sponsorship and role modelling of the new approaches
  • We keep perspective, especially where there are teething issues
  • The hypercare period is taken seriously
  • We use the guiding KPIs to track value creation
  • Time is taken to come back and review the solution once it is fully operational.

There are different models for this. In my team we kept the accountability for implementation with the Solution Development Lead, who adjusted the staffing for the detailed work of localization, roll-out, change management, and risk management. We passed the accountability batten to the nominated Solution Delivery Lead at the go-live gate. The project work would then continue alongside the live delivery in a hyper care period, ensuring that the outcomes were as intended. In complex solutions this might be extend for a year, to help ensure that the teams and processes are working well. We would only close the project after initial issues are resolved and a project retrospective held. 

It is tempting to think that design and implementation are ‘one and done’ tasks, with no need to revisit.  In most cases, the solution is likely to require continued attention to refine, adjust and improve over time. In fact, where the solution development process goes well, there is normally a follow-up by colleagues to implement extensions. Our most mature solutions operated for over 10 years, and had multiple updates, keeping them appropriate for long-term use. In the best cases, the same Solution Development Lead and Solution Delivery Lead would work together for several years, setting the strategy, prioritizing the next things to develop, and fixing issues.

A closing note: culture and workstyle

This article brings this series of posts on building GBS solutions to a close. We’ve looked at the edgy practice through the lenses of:

I will close with a thought about the culture and work style necessary to make this successful. Complex solutions require the team to manage through initial ambiguity, build coalitions, and stay with it for the long-term. Three overarching things are needed to make this work:

  1. Courage, on behalf of the solution leader, to put their hand up and say, “follow me!”
  2. Active support and empowerment from the GBS leadership team
  3. Collaboration, between all the teams, to agree to work together and resolve inevitable issues that will be encountered along the way. 

This requires the right type of culture, one where risk taking is valued and the leadership team understands that its role is to help their teams be successful. In my team we worked hard to build the right mix of high support and high challenge behavior.

I hope this series has whet your appetite for the opportunities for your GBS to add value across the value-chain of your company. It is worth the effort, bringing benefits to both the company and those leading the charge.

Next time, I will start a new series. Please let me know if you have anything you’d like to see covered.

Tim Palmer, Basel, November 2023

tim.palmer.gbs@gmail.com


RECOMMENDED