This post is the fourth in the series about the edgy practice of running an internal consulting practice within a GBS organization. I share a final set of lessons from the field and practical techniques, this time focusing on the processes needed to run an internal consulting team.
Key lessons learned from the field
- If you have project-based teams in your GBS, it can make sense to bring them together into a consulting practice. We had a ‘consulting family’ that shared common attributes, and activities such as leadership development, training, knowledge management, and culture building. This included groups such as: solution design, transition, process excellence, management consulting, PMO, some change management, and others. The three standout benefits that made this worthwhile were the enhanced resilience, career development and work collaboration opportunities. Once we had the processes needed to sustain these teams established, we were the logical place to add new project-based teams and capabilities.
- However, it is important to understand the differences. As the leader, I liked the flexibility and diversity of having these teams work together, but I was initially not sensitive enough to the need for each leadership group to be as clear on the differences between them as we were on the similarities. For example, process excellence must work intimately with global process owners, whereas the consulting team may have a different relationship with the same stakeholders. As with any family, it is important to manage the parts as individuals, understanding their specific needs and purposes, as well as what binds them.
- A consulting-style workforce needs different structures and processes. As I discussed in the post about talent and culture, many of the processes needed to manage a consulting team are different to the rest of the GBS team. Project-based teams require agreed approaches to project scheduling, project control, knowledge management, and matrix line management. As team members joined from commercial consulting organizations, they expected this structure to be in place – it was not, but we knew where we wanted to go! See below for a practical solution for tackling this.
- There is the potential to overheat with initiatives, but do not stifle innovation. Consultants like to solve problems. We quickly had many initiatives running, sorting out this need for structure. We let it grow organically and ended up with more initiatives than necessary, but at every business review there was another brilliant idea being driven by a couple of team members. Although there was some wasted effort, local initiatives delivered solutions that were innovative and elegant, and a little overheating was in some way worth it. The things we prioritized as leaders were not necessarily what the team cared about, and we would not have had the same result had we controlled it too closely. One example innovation was an onboarding tool that explained the Company Way of working. It was a Miro board built by the team to explain how the various parts of the company fitted together. It allowed colleagues to quickly orient themselves within the organization, particularly when taking on a new assignment. If we had tried to source this from official channels it would probably be still in construction. Our team built it in a matter of days, in a way that was fit for the need we had. As our teams matured, we increased control over the agenda, rationalizing initiatives and joining up between sites and teams. Getting this right without killing the energy was a delicate balancing act.
Techniques that worked in practice
Build an online operating manual. This is not an edgy idea, but it is effective. It is something I have done several times when shaping operating models or teams. The approach is inspired by a story in Clive Woodward’s book “Winning!” He describes how, in the build-up to England winning the 2003 Rugby World Cup, they created a book where all the agreements about their ways of working were documented. An internal consulting team also needs such agreements. There are many things to get right and plenty of energy to fix things. The operating manual – or maybe you can find a more inspiring title – is a means to harness the energy of the team.
The approach is to break the big question of how to work into topics (small chunks that can be short articles on a SharePoint site), empower a small group to define the approach to a topic, and bring it back to the overall team. Once agreed, you can take the topic off the table. I’ve set out a starter for topics that you might consider:
Key to getting this right is:
- Have a simple standard format that keeps the descriptions short – made for easy consumption and use, rather than ‘standard operating procedures’
- Prepare two or three of them well to act as examples of what you are looking for
- Be clear on the accountabilities for creating, reviewing and signing off the approaches, as well as for continued maintenance – involve the people in the team that have the energy
- Be flexible on timing – you do not have to do it all at once.
Looking at this now, I can see that much of this could also apply to other operational teams.
Keep some of the team back to help build the processes. I learned several times that it is easy to put all the available team on project-based work, ignoring the need to build your own processes. If doing this again, I would plan to keep between 5% and 10% of the people hired to work on team establishment, until the core processes were set up.
That’s it for this post, and lessons learned and techniques. I will make one more post in this series about internal consulting, answering some of the outstanding questions that have been posed and drawing conclusions about the practice of managing an internal consulting team.
Tim Palmer, Basel, June 2023