In my last couple of articles I described a rough process for creating a value proposition for an internal consulting team. To do this I used “Sophie” and her mythical business analyst team as an example.

Now we are going to go one step further. Sophie can already explain the services her team offers, but now she needs to assess how well the team can provide those services.

Our high level approach

In order to assess the services that the team offers, Sophie will assess:

• The stakeholders or “customers” who use them;
• The actual service and whether to measure it;
• The current and future demand for the service and the number of people in the team who can provide the service;
• The skills needed to deliver the service at the appropriate level of quality; and
• The tools and partners the team can use to be better at delivering the service or at smoothing supply and demand.

Yikes – that is quite a lot of analysis. Many teams never go this far, but if your read on you can cherry pick the components you want to assess. But external consultants normally go to this much trouble and I find it is also worthwhile for an internal team.

The stakeholders

Sophie picks a service to start with and then considers who the stakeholders are. Sophie is not going into too much depth, so she simply lists which stakeholder use the service, why they use it and then what they think of it.

She could have chosen some other approaches including PAC, My own lazy communications plan, Empathy Maps, The Value Proposition Canvas or other techniques that really help to understand the stakeholders and their real needs.

The only other thing that Sophie adds to her analysis is to guess how much demand there is:

The services

Sophie has already listed the services that her team provides. But she could look at them in more detail:

• Should she use the “Net Promoter Score” to see what people think of the service?
• Should she gather performance feedback on her team as part of the service?
• Should there be a service level agreement in place?
• Are there any relevant quality metrics? Are there common causes of failure?

Sophie decides to use an approach called GQM (Goal – Question – Measure), because the manager of the testing team told her it is a cool approach.

Sophie is too lazy (er .. busy) to assess each service so she ends up with a fairly common approach to all services:

• The goal in measuring the service is to achieve two outcomes
  • Find out how to do things better
  • Gather some feedback on her team members so she can do the dreaded performance management stuff she does each 6 months … and maybe even find some development areas
• The questions she thinks she should answer are:
  • What should we do differently?
  • What do you think of [team member]? What development ideas can you suggest?
• So the measure Sophie puts in place is a quick interview
  • At the end of the assignment (or every 6 months) a team leader will sit with the stakeholder and interview them. If the stakeholder does not want to do this then the team leader will send an email with a few questions
  • They will use their standard retrospective approach and then an approach called SCAR or scary:
    • To find improvements in the team approach, ask “what did you expect?”
      • Then ask – How did we exceed or miss that expectation?
      • What should we stop or do less of?
      • What should we start doing or do more of?
    • To assess the performance of the crew
      • Situation – What did you need from our crew member?
      • Challenge – What was the most challenging part of the role (or the most important if you prefer)?
      • Approach – What did our crew member actually do? How did they approach the challenge?
      • Result – What happened?
      • Optional “Why” – why do you think that was the outcome?

Really, Sophie knows that she should go a step further. It would be easy to set up a standard engagement letter to define the expectations for the engagement and it would be easy enough to formalise feedback based on the expectations that were set. But Sophie has a lot on and will be spending time drinking cappuccinos with stakeholders rather than bringing in more formal processes – for now.

The people and the skills – take one

Now that Sophie knows what services she offers, and has guessed what the demand is for the service, the next step is to see if there are people in the team who can provide that service. Hopefully most of the team can deliver some of the services but there might be some that only a couple can do properly.

Sophie sits down with her two team leaders and asks a few questions:

• For each service, what are the core skills needed to deliver it well?
• Are there particular qualifications needed?
  • Does someone need specific experience or certifications to provide the service? Do you need to know the right people?
• Who in the team can really deliver this service?
  • How many people can deliver it now?

Sophie then prepares the following table:

Sophie can also look at what will be happening in a year’s time

Oh dear, there will be a gap in a year. Sophie may need to look at options. So for those areas that there will be a gap she considers three approaches:

• Hiring new people;
• Working with contractors or other suppliers to bring the skill in; or
• Training the team in the skills needed.

There might also be some services that are no longer needed, or that are becoming less common. Perhaps the team do regular training in PowerPoint, but they are now presenting in another tool – or in Sophie’s case, the team used to do a lot of data modelling, but they are no longer likely to be doing much of it. So there are 10 people in the team who can do data modelling, but only likely to be roles for about 1 person to be doing it at a time. Should Sophie worry about this? Yes, if for example:

• Team members see the skills associated with the services (data modelling) as important for their career growth and for future roles; or
• Some of the team are specialists and will not readily be able to move across to provide another service if demand drops for their particular skillset. In this case it might be time to retrain them or help them find another home before their skills become redundant. I often see this where teams look after legacy systems and I think it is poor form for management to leave people supporting the old system with no plan for them when the system finally gets turned off.

In Sophie’s case, she might not be too worried that some of the team have a skill they won’t use. But she might tell her team leaders not to send a lot of people off for training in data modelling.

Sophie prepares a graph showing the demand for service changing over time and presents this to her boss and her team for validation. Hopefully her presentation is a little more professional than mine, but you get the idea.

Skills part two

Some teams create a skills matrix or even a whole competency framework. This is great and now days you will often find that professional bodies have something that you can use.

Competency models can be great for team development and for team morale. But for our purposes we are focussing on those skills that are needed to provide particular services to internal stakeholders.

So Sophie decides to do a gap analysis on the skills needed for the team.

Now Sophie looks at the gap and goes through some standard consulting questions.

• What is the gap?
• Where does it exist (ie all team members, some, etc)?
• Why does it exist?
• How important is it?
• What could we do?
• What should we do?
• What is the next step?

Poor Sophie ends up with a huge backlog of things the team should do in order to deliver their existing and emerging services. I guess she could disband the team and hire a new gang of gurus but that usually fails miserable.

Instead, she looks at training and then using partners to fill that gaps that remain.

For her internal team, she publishes a list of the most wanted new skills. Unfortunately a bunch of her team come forward to claim they are already great at those skills, while her team leaders say that the same people actually lack those skills. What follows are some touch but very valuable career discussions.

On the bright side though, some of the team are already googling training courses and looking at ways to learn new skills on their projects.

Sophie and her team leaders then come up with this template to hold better discussion with the crew. They do a one off exercise to look at what they should do this year and then plan to add a similar conversation into the 6-monthly performance management ceremonies they have to go through.

Sophie and her team leads now digest that information and look for priorities across the team. It looks like an in-house facilitation course would be worthwhile and it looks like some agile stuff might be valuable. Sadly nobody seems interested in learning NPV (net present value), so there will still be some gaps.

Now Sophie and her team leads sit down and look at other options. They may be hiring people during the year:

• Some contractors are rolling off existing projects – maybe they would be a good match to hang onto longer term;
• They might need to hire for the big new improvement project if it takes off; and
• They might have some people move to new roles.

So they keep a list of “target areas” where they want to acquire or protect core skills.

Partners and suppliers

Fortunately there are also about 250 outside organisations looking to help Sophie for a price. They send her resumes every week for contactors and permanent staff.

Sophie ignores most of them but decides to meet with some of those that she trusts. She runs through some of the stuff she has done in all these assessments and then decides to create a “supplier pack”.

In this pack she includes

• Her team’s purpose and core services;
• Those services and skills where she sees a gap now, or in the future; and
• A rough guess as to how many people she might be looking for with specific skillsets.

Some of Sophie’s suppliers are not very innovative and just want to email resumes to her. But some are really eager to work with Sophie on a more strategic basis.

By having access to this supplier pack, Sophie’s suppliers can:

• Highlight the skills that existing contractors or consultants have that might not be used at the moment;
• Look for people with specific skills over time; and
• Have a better conversation with Sophie and her team leads when they are providing services.

Training providers can also benefit from this pack. When Sophie presents her thinking on the changing skill requirements for her team, they can talk about customising their offerings and also about what they are seeing elsewhere. This feedback might help Sophie to offer better development to her team and might also help her to see new trends that she has not noticed to date. But the main benefit for Sophie right now is that she can better align what stakeholders are asking for with the type of contractors she brings in for different projects.

“IGOE” even further though

Sophie can now define the services her team offers, identify and start to fill emerging skills gaps and even better align with partners to deliver her team’s services. But there is still some work to do if she is up for it.

“Igoe” is a term used in process modelling. It stands for “Input, output, guides and equipment”. Sophie now uses this concept to further analyse what she can do to better deliver on the services that her team offers.

For each service, Sophie can define the inputs needed before supplying the services and the outputs that come out of it. For example, for requirements elicitation:

• Sophie and her team leads decide that when they send in a team member to “elicit requirements” they will need
  • A cost centre or authorised person to pay their bills (Sophie has an internal charging model to work with);
  • A list of the stakeholders;
  • A start and end date, if possible; and
  • A goal for the work, along with a rough approach and estimate for some types of work.
• Coming out of the work, Sophie’s team produce a standard requirements document with lots of signatures. They also want to get the feedback that they ask for in order to assess their work.

Sophie finally gives in and decides that she will start using a “letter of engagement”. This can be an email and will be done by either the team leader or the business analyst being engaged. It will help to set expectations at the start of the assignment and it will also help Sophie assess whether they are delivering the services that she expected, or whether things are changing. The letter can also be used by Sophie to clarify what she expects of contractor and consultants, by using the same approach with them.

Of course it remains to be seen whether the team use this letter a lot or whether they just go back to shipping BA’s off to projects to work on whatever the project manager asks for, but hopefully Sophie and her team will use the more formal engagement approach to monitor and improve the services that her team offers.

Igoe also includes two more letters though – guides and equipment.

Sophie’s team have access to several templates for requirements documents and things but it is all a bit chaotic, with multiple versions of multiple templates existing everywhere. Sophie decides to have a workshop in her next team meeting and she will ask the team to suggest some common starting points for “standard deliverables”. These will then form part of the output of the team and will represent part of the value proposition that her team offers to stakeholders.

In addition to templates though, Sophie asks the team whether they can benefit from some guides, standards or “tips and tricks”. This turns out to be a bit unpopular with the team, even though it could have added a lot of value.

But the team suggest something similar. They create a registry of people in the team who have worked with different business areas or done specific types of work. This list of contacts will allow the team to complete some work faster and with better quality, and so it starts to become part of the team’s value proposition to stakeholders.

The team also identify some areas outside their services that could benefit from guides. They say that they could really benefit from some basic guides to using some of the tools that they use, such as excel and word. Soon there are quite a few documents and artefacts floating around. So Sophie modifies her team meeting agenda. Rather than just talking about templates and guides, she organises for a presentation on “information architecture” and appoints a team librarian. This is the start of a basic but useful knowledge management strategy for her team. Sophie does not have time to document this properly this quarter but can see that it could also contribute to the value her team provides to stakeholders and to team members.

Finally, Sophie looks at the equipment the team needs. Apparently they feel that the all need faster, smaller laptops and new tablets. But beyond this stuff, Sophie realises that they all use certain screen-capture tools, modelling tools and other software. Unfortunately contractors often turn up without the right kit and it takes a while to get them all set up correctly. Sophie also suspects that she is paying for lots of licences for an application called “Visio” even though she has paid for a lot more licences in the past than she has team members.

Sophie now comes up with a lot of “things” the team will need when providing services:

Sophie realises that the team can be more effective with some simple training in things like Google Hangouts and their internal meeting room booking system. She does this as part of team meetings and then realises that she could update the “engagement letter” to include a brief induction for contractors and team members doing new types of work.

Good grief

We started with a simple task of defining the team’s purpose and now we have created a whole consulting engagement for Sophie and her team leads. I think this would be a good exercise for any internal team to do over the new year period or as a “spring cleaning” exercise. But I will leave you to work out how much if it is or real value to your team.