How to plan the resources and budget needed for an OSS transformation project

OSS Transformation Resourcing Questions

Have you ever had to wrestle with the conundrum of organisational change when embarking on a major OSS transformation? How many people will I need? What tasks will they do? What skills will they require? Who are the best people to get involved in the transformation? How much budget needs to be assigned?

These are all questions I get asked on a regular basis because the org chart (and responsibilities) before a transformation often looks quite different to the org chart after a transformation. Sometimes there’s org chart growth, where the transformation is designed to facilitate a company’s next growth phase. Sometimes there’s org chart contraction, where a greater amount of automation is expected as a result of the new OSS.

Whether growing or contracting, there’s almost always some sort of org chart, responsibility matrix or ops model change that results from an OSS transformation.

Transformation Project Framework (TPF)

When mapping out a transformation, we always go through the transformation project framework (TPF) below:

  • Evaluating the current state (WBS 1.2)
  • Projecting forwards to the desired future state (WBS 1.3)
  • Determining the gap between those two states (WBS 1.4)

That’s true, whether we’re looking at state change in technology, people, process, etc – including org chart change.

In addition to the organisation chart changes (what I refer to as the BAU, or business as usual, org chart), we also need to consider the project org chart required to complete the transformation itself. This is the team of people required to do the scoping/planning and delivery / implementation phases above.

It’s common for people to have multiple roles – a spot on the BAU org chart as well as one or more roles on the project org chart.

Org Chart Mapping Technique for OSS Transformations

There’s a great technique I use to help plan these changes, whether that’s for BAU org charts, project org charts, changing ops models or even for changes within PAOSS itself. It’s a technique I learned from a fantastic book that’s now nearly 30 years old – The E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It by Michael E. Gerber. [BTW. It’s one of the books in my “uncommon list of great OSS books“]

The technique involves drawing up an org chart as it will look in the future (black boxes), but with the names of the people currently doing the role (red names), like below:

As you’ll notice, Person 8 is currently wearing 8 separate hats, but has to because the company only has 12 people doing everything. This helps to highlight just how overloaded Person 8 is and therefore needs help if the company adds head-count.

The best way to overcome weaknesses in your org chart is to hire complementary skill-sets rather than hiring people who are good at the same skills you already have and are already familiar with (as we’ll see with Person 8 in the worked example below – there’s no point hiring more people with Transmission Network SME capabilities when there are other more important skills to onboard).

A Worked Example

Then I overlay a heat-map to show the capability / competence / interest in the role for each person. If we just overlay a heat-map for Person 8 in the org chart below, we see that their real expertise is in Transmission Networks, but they’re actually not very interested / capable in Network Systems or Service Design. Therefore, if we decide to hire someone new to help Person 8, then we’d focus on finding someone with Network Systems and Service Design skills / interest.

 

Now, let’s take the same technique and layer in the Transformation Project Team org chart (as shown in the dotted light-blue box). You’ll see that it is made up entirely of existing BAU team members, in addition to a new project coordinator.

This is often the way that OSS transformation project teams are built. The company just assigns team members from the BAU team whilst still expecting them to perform their BAU activities. The project team will also call upon other resources (inside the dotted pink box) to support the core transformation project team (eg with data, insights, decisions, preferred OSS solution configurations, etc, etc).

Note that the Core Project Team is also likely to be engaging with third-party resources like OSS vendor implementation teams (which is represented by the blue “External” box, but not shown on this sample org chart map, for the purpose of keeping things simple).

The Problems of Building a Core OSS Transformation Team

There are usually three problems with this approach of assigning BAU team members to the core project team though:

  1. The BAU team members are often already at peak capacity (eg we’ve just added two more roles to Person 8’s responsibility list)
  2. There are significant mindset differences between the roles in the pink box (ie repeatability and optimisation and ensuring networks and services remain available) and the roles in the light blue box (ie creating something new, imagining possibilities, re-inventing). This makes it very hard to task-switch between pink and light-blue boxes. I’ve only seen a handful of people who’ve been able to seamlessly switch between mindsets in 20+ years of OSS transformation projects
  3. Because of this task-switching problem, team members will often tend to overly focus on the activities that they’re best at or think are most important. For example, person 8 might be passionate about Transmission Networks and believe that their priority is working with Person 9 to ensure all the networks remain highly available. If there’s an outage, then all transformation project activities are justifiably put on hold, but this then impacts the transformation project timelines and the core team members who are dependent on Person 8

It’s common that the most useful and in-demand people for the transformation project are also highly depended upon for BAU activities (eg Person 8). You can’t just assign new people to the core project team because they won’t have the all-important tribal knowledge about the network, services, operations models, org structure / people, processes, politics, etc, etc. That tribal knowledge only comes from experience performing BAU activities, often for years!

Therefore it’s a really delicate balance to build a core project team with the required tribal knowledge who are also removed from BAU load activities, but still remain connected enough to the BAU team to represent their needs when building the OSS. Like so many aspects of OSS transformation, there’s no single right or wrong way to build the teams. It might even require some trial and error to work with the unique personalities involved and find a team approach that works.

In the inevitable situation where there is a person or people who overlap between BAU and Project activities, there has to be awareness / empathy from the project champions, executives, sponsors and other stakeholders involved. It’s likely that they will be called upon to make tough decisions on whether BAU or project activities take priority as scenarios arise during the course of the project.

Calculating Resource and Budget Requirements for your OSS Transformation

As you can see from the E-Myth org mapping technique above, we can quickly show the as-is and to-be organisation / resource requirement gaps. We can therefore use this technique to calculate how many new resources are required, their necessary skill-sets and therefore expected costs that must be budgeted to hire and onboard them.

The heat-map also helps to prioritise if there’s a sequence of hires to be made over a period of time via a time-series map. This also helps us build a resource and cost profile as the team evolves over time.

For example, the team might grow so quickly that Person 8 can be back-filled by 9 other people at a rate of 1 new hire per month, allowing them to revert back to only doing the Transmission Network SME role that they’re most interested in and competent at.

Please leave us a comment if you like this approach or would like to share the other techniques that you use.

Also feel free to drop us a note if you’d like help planning any of your upcoming projects.

PS. As an aside, I believe that doing multiple roles like Person 8 is a great opportunity to learn and compound skills quickly (if it doesn’t burn you out). I’m a strong believer that hard work and skills development compound in a similar way to compounding interest (the financial concept). That is, the earlier you do it, the more the benefits pay off over the longer term. Tripods, the people I refer to as the most valuable of all OSS resources, tend to be built from the opportunity to develop a multitude of skills like Person 8 and their willing to embrace these combined challenges.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.