In my last article, I described an approach that you can use to define the purpose of an internal consulting team.

I used Sophie and her BA team as an example and I will continue to do so here. This time I will talk about the “Service catalogue” or list of services that your team provides to stakeholders in the business.

Our approach at a high level

Sophie and her managers have just defined what their team’s purpose is, so it should be easy to create a list of the services that be needed to achieve that purpose. But in reality, a lot of the work done by internal teams is “as per the stakeholder’s request” and not at all aligned to the team’s alleged reason for existence. So we will attack this problem from two angles

• What Sophie and her managers think the team should be doing; and
• What the team are actually doing at the moment.

We will then look at the gap and work out what to do about it.

Sorry, but it turns out to be a long article, so pour a cup of tea for yourself or just read one heading at a time.

The official view of things

Sophie and her managers recently defined their team purpose, but Sophie was a little unsure that it was an accurate picture of what the team really do, so she told her boss it “may need a little work”.

Her boss was happy with the purpose of the team, though he would also like Sophie to “influence quality on projects to ensure consistent good approaches”. Sophie deflected that question and said she would meet with her managers to look at services the team actually provide to projects. She said that a lot of people think the team is just a body shop that finds BA types of people and ships them off to projects. She also added that she wanted to shift the perception of the team to one of adding value through the services they offer as a team. Her boss seemed fine with that and moved onto other topics, like cost cutting and improving employee engagement.

Sophie booked another meeting with her two team leads to discuss the services that they think the team should provide – today and in the next year or so.

Sophie starts by reminding the team of their purpose:

“We clarify what the business stakeholders need from a project so that the project team know what to deliver.

Project managers use our crew because we have the right contacts in the business, a deep understanding of the history, drivers and needs of the business and solid experience in eliciting and managing requirements”.

So what services do they provide? They came up with the following:

• Sourcing and appointing business analysts;
• Eliciting requirements;
• Documenting requirements;
• Managing changes to requirements; and
• Working with the IT crew and testers to support the creation of their work products.

That was easy, thought Sophie. Now they just need to list them in a catalogue.

But John, her team lead commented that some of his crew were now on “Agile projects” and not really doing the work they just identified. He also asked if working for a project manager to write requirements was the same as “uncovering what the business stakeholders need”. They agreed that they should document what they are focussed on now and what they see as emerging needs where they could or should focus the team.

They added the following list of emerging services that they would like to see the team involved in:

• Creating proposals and business cases;
• Facilitating story creation in agile teams; and
• Working with the customer experience team to capture end user needs.

They then realised that the later set of services are not really for project managers, they are for other stakeholders. They decided not to update their purpose statement yet, but decide to capture their services in a simple table to share with the team and the stakeholders.

If you want to run the same session, then this is the agenda:

1. Confirm the team’s purpose.
2. Brainstorm the list of services that you think should be delivered to stakeholders in order to meet the purpose.
   1. List those that are currently being performed, that align to the purpose
   2. If you see some that do not align, then list them but don’t worry too much yet – they get taken care of in the next workshop
3. Create an initial (rough) service catalogue
   1. Refine your wording a little and list the services under a column called “service”. Try to keep it fairly short and use words that stakeholders might recognise
   2. Add a column showing the stakeholders who use these services (you can have multiple groups if you like)
   3. Add a column showing how the stakeholders engage the team in order to acquire these services.
4. Brainstorm (or research) the services that the team is not providing yet, but should be. Add those services that you think will be needed in the future (say 1-2 years out).
   1. Consider services the team wants because they are cool, or good development for the team.
   2. Consider the changing needs of the market and the business
5. Create a future service offering:
   1. Refine your wording a little.
   2. Add a column showing stakeholders.
   3. Add a column showing the likely timeframe when the new services will be in demand.
   4. Create a priority if you really want to (though there will also be time for this later).

The team view – what is really happening?

Sophie and her managers now have a list of what they think the team should be doing on their projects. They could validate this with management and with stakeholders but for now they just hold onto it. Their next step is to have a workshop with the team to see what the team are really doing for their customers.

They call a team meeting and 8 of the 15 team members turn up. Then they create a story map to see what the team are really up to. You can find a great explanation of what that is and how to do it here: http://www.agileproductdesign.com/blog/the_new_backlog.html

For our purposes, they just ask the team to list all the major tasks they complete on a project and then put them up on a wall:

• Each team member lists the key things they do on projects – particularly the project they are on and what they see as a “typical project”. The team capture these ideas on index cards, one idea per card.
• They find a space on the wall, or a whiteboard and create a table with two columns:
  • Frequency – how often do people do that particular task; and
  • Order – in what order do things happen.
• The team put all their index cards up on the wall and then shuffle cards around so common tasks move to the top and uncommon ones move to the bottom. Similarly, if things happen in some kind of order then early tasks on a project go on the left and later tasks go on the right.

The results are interesting. According to the team, they are doing project reporting and user acceptance testing more often than actually gathering requirements. They are also acting as product owners on agile projects because the business don’t have time to participate and they would like to acting as iteration managers too. They even do the odd technical specifications for the IT teams, even though another team is meant to be doing that. Sadly they don’t spend a lot of time managing requirements at all.

But at least the team are doing some requirement elicitation and documentation.

Some of the tasks they added to the wall can be aligned to a particular service, while others may need to be grouped together to form an offering. The team sit back and review how they would explain what they do as a list of “services”.

The team then do one more step. They create a new graph on the wall with 4 quadrants in it:

• The left axis of the graph is called “Frequency – How often we are doing something”
• The bottom axis is called “Alignment to our purpose”.
• Both axis start with “low” and then go up to “high”
• The 4 quadrants then become
  • Ignore – we don’t do it and don’t plan to (should be empty)
  • Should – things we should be doing, but don’t really do much
  • Dodgy – things we do, that are not aligned to our purpose
  • Good – things we do that do align to our purpose.

Now the team populate the table with the tasks they do and the team leads add the things they thought should be happening. If relevant they can also add the emerging services that are needed soon.

If you want to do this yourself, the agenda would be:

• List the services the team are actually providing at the moment. Story mapping is a good approach and it is good to get the team to do this themselves.
• Consolidate these into some core services or common headings
• Add the services that the team should be doing, but that did not come up
• Compare the services by adding hem to a table showing which are happening and meant to be, not happening but should be, or happening but not really aligned to the team purpose.

Panic – then relax

You usually find out that you are not quite doing what you and your boss thought you should be doing. You can now plan an elaborate scheme to cover things up or you can deal with it. So panic for a moment and then relax.

Have a coffee break before continuing to let things settle in.

Assess your options and next steps

Sophie and the team have a look at their findings. Sophie can now go off with the managers or work through their findings with the team. In this case the team head off to their next adventure and Sophie stays behind with her team leads.

The work through each quadrant. The “good” quadrant is easy, so they add that to their offering.

The “Ignore quadrant” should be empty, but has one item in it for some reason. So they just throw that one away. It is something they should not really be doing that came up once.

Now for the hard work.

Sophie looks at the items in the “Dodgy” quadrant. The choices are fairly straight forward and she and her team leads decide between:

• Finding a better home for these services. This might involve letting team members join another team or just stopping her crew doing the work and passing it onto someone else. This will take some juggling though.
• Pretend to be ignorant and do these things in stealth mode. This is probably not an approach that is aligned to Sophie’s team culture so she doesn’t take this approach.
• Call these items “secondary” services and just keep doing them.
  • List them as things that can be done but don’t include them officially in any offering.
  • These might actually become current services that will be phases out in time, as the emerging services become more important.
• Stop and see if they are actually adding value. Then potentially change the service offering of the team to include them formally. This might involve a whole new team purpose or it might just involve changing their purpose a little.

There are a couple of items that Sophie decides to push back on and she organises a meeting with the head of the PM pool. But there are also some things she thinks the team need to do as nobody else is doing them. Sophie decides to raise these with her manager and peers to endorse who new plan to expand her official services.

The last quadrant is the hardest of all. There are things that are meant to be happening that the team are not delivering on (at least in theory). Sophie and her team leads must now answer three questions.

Why are these things not happening?

• Is it because these things are not actually needed – in other words, is there an actual demand for them?
• Does the team lack the capability to deliver them?
• Is it a communication or branding issue? Perhaps stakeholders do not believe the team can do this work and they are going outside for help – possibly to kingsinsight consulting J
• Does the team actually dodge this work? Perhaps they team themselves are pushing back on this work.

What has to happen for the team to offer this service?

• Does the team need to bring in new skills?
• Is this a communication exercise?
• Could Sophie use contractors to provide these services while her team focus on what they are doing?

What should happen in the short term?

• What is the priority for this issue – should Sophie lobby for change or just drop it for now?

Wrapping up

I will not go through how Sophie resolves all this because it is probably hard work. But let’s assume she makes some decisions.

Now Sophie reviews her team purpose and updates her list of services.

Team Purpose:  As it was before

What we offer:

Services                                                                    Description and SLA    How to engage us

Sourcing and appointing business analysts.     (none)                            Email or call Mary or John

Eliciting requirements.                                           (none)                           Email or call Mary or John

Not too flash, but I am sure in the real world you could flesh this out a little.

This updated list can be shared with the team and the stakeholders to gain buy-in for the current offering and also the emerging areas where the team needs to develop a capability. Next time, we will look at analysing the services in more detail and then perhaps at analysing the team’s “business model”.

The final part of the story is here in the next link

Defining the value or your internal consulting team part 3 – reviewing your services