A successful digital transformation is largely contingent on how well and effectively you establish a project team. When we're working with clients, some of the most common questions we get is:
What I want to talk about today is what a typical transformation project team looks like and then I also want to shift gears and touch on what a typical transformation team should look like.
The first role on a project team and arguably the most important role on a product team is your executive steering committee. This is typically a cross-functional group of executives within your organization that are responsible for setting the vision for the overall transformation. They're responsible for approving scope changes, or any sort of material changes to the project plan or the budget. They're ultimately responsible for setting the tone and the vision for the overall future state.
The question to ponder on here is, how do we want our operation model to look and what do we want our organization to look like in the future? For lack of a better word, what do we want to be when we grow up? Before I get into the rest of the project team, something that's very important even before we talk about other team roles is who should fill these other roles.
The first thing you want to do is make sure that the steering committee is aligned on the overall transformation, vision, strategy, and objectives. If you start filling out the project team prematurely, when you don't have that alignment and clarity at the steering committee level, you're going to run into trouble that is likely to spark internal conflict and tension because you don't have that clear vision.
Another important thing to know about steering committees is that they are typically responsible for any sorts of project governance, that should be escalated to the committee itself. Things like project scope changes, budgetary changes, and changes to the business process operating model. All those are things that the steering committee should be responsible for.
The next role to be thinking about is your project manager and this is a role that I'm going to come back to because there's the traditional way of doing things and there's the way things should be done. Typically, what happens is you have an internal project manager that's responsible for reporting to the steering committee, and they're responsible for everything that happens on the project.
What some people might not understand is that this is an internal resource, you might have a project manager or project leads from outside consultants or your system integrator or your vendor but ultimately, you need someone internally that's managing the overall project. They're responsible for all the resources, all the workstreams, and everything that we're going to talk about going forward.
The next thing that project teams typically consist of is the technical lead. You might also refer to them as the technical project manager. This is the person that's responsible for overseeing all the functional aspects and the technical aspects of design and testing and everything related to the technology that you've selected and implemented.
Sometimes, what happens is people confuse this role with the project manager role. For example, you hire a system integrator, they provide a technical project manager, and oftentimes organizations think: “well, that's my project manager that belongs here” in the end, that simply is not true.
The reality is your system integrator typically will fill just as one workstream. Within this stream, you're also going to have a series of process leads or functional leads. Typically, you'll have things like someone responsible for CRM, and these are going to be the process leads. They could also be referred to as functional leads.
Depending on what industry you're in, obviously, these functional areas are going to vary, and depending on what the scope of your transformation is - these functional areas are going to vary.
Generally, you'll have someone who's responsible for leading these functional and technical areas for that specific part of your business. Here's where you generally see a blend of resources of internal and external resources, you'll have typically someone that leads each of these modules or functional areas from the system integrator or the vendor.
These people are usually partnering with someone internally from your organization to work together to figure out what the future state processes and the design of the software. They'll be responsible for testing the software, for training people, basically all the things that go into that specific part of the transformation. Then, within each of these little areas here, you may or may not have other supporting team members.
These are typically internal resources that are specific to one part of that functional area. For example, within finance, you might have someone that's responsible for accounts payable. Within CRM you might have an SMI that's just responsible for customer service. You might have someone else that's responsible for sales and another division.
At the end of the day, you're going to have a series of subject matter experts down here, which is going to vary depending on the size and complexity of your organization.
Here's where I want to shift gears a little bit and talk about the difference between what a project organization typically looks like versus what it should look like.
Typically, people myopically focus on this part of the org chart and they sort of hone in on this as the overall project. The reality is this is not the overall project. First and foremost, as I mentioned before, this technical lead is oftentimes confused as being the project manager. What we want to do here is, first of all, understand the difference between these two roles.
In order to be successful, we want to make sure that we're not assuming that the SI is going to fill this role. The SI belongs near the technical lead or the technical project manager. As we're going to discuss here, there's other workstreams that have nothing to do with the system integrator but are critical to the project.
The problem and the thing to think about as you're getting proposals and looking at potential options for how you deploy your new technology is that the system integrators typically in a focus right here. This might mislead you into thinking that's all that is to worry about. The reality is you need to put a project manager over their team. This way, you have another series of project teams or sub-teams that are going to fit in parallel with the technical workstream.
For example, if you're going to have data, you should have a data lead. This is the person that's responsible for making sure that the data gets cleansed, that there is a migration plan, and that the master data management processes to make sure that the data stays cleansed. This is one area you’ll want to make sure that you've changed or modified from that traditional approach.
An area that oftentimes gets overlooked, is the whole change management side of things. Generally, if you're going to have a change, a change lead is important to have. You may even have supporting change resources that support that change management lead. The change team here is going to be responsible for making sure that not only people get trained, and that we're leveraging the knowledge over here from the technical side, but that we're modifying the training to fit your specific business processes and your specific technology that you're deploying.
An important thing to remember is, prior to training, change management's responsible for making sure we've designed the organization the way it needs to be. We've identified change impacts, we've ensured that we have stakeholder alignment, including at the steering committee level, and other change management activities.
In addition, to change management, you typically are going to want to have, not necessarily at this project level, but more off on the side, that's reporting up to the program management office but supporting these different work streams here. One of those roles is the system architect.
This is someone that can look at the overall big picture of technology and identify how integration is going to look, how the different systems are going to be commissioned or decommissioned, and what kind of integration we're going to have in the end. They also work very closely with the data lead to sure that we know where the single source of truth is and how data is going to flow between systems.
The system architect role is very important, especially if you're in a best-of-breed environment. Let's assume here for a second that you're deploying one single ERP system as your core, but you might have other technical leads that are supporting other technologies.
I want to make an important point here on the technical workstream. Let's just say you're implementing SAP as your core ERP system, you might have SAP as your core, but then you might also have Salesforce CRM as part of your CRM aspect of your deployment. In this case, you would have another technical project team that's focused on the Salesforce side of it.
Your system architect would be the one to tie all those pieces together, or at least have that blueprint or vision of how all the technology ties together. You want to make sure you don't forget about that system architect piece.
This leads to another important role that you don't want to forget about, the business process owner.
These people here are typically looking at how are we going to design the software and how we can design workflows within the technology.
We don't have necessarily a framework, a bigger-picture framework for how business processes should look, or how we're going to incorporate changes and improvements to our business processes into our program.
All that stuff needs to kind of come from the top down within the product team. Having a business process lead or someone that's looking at business process management, is very important.
Last, but certainly not least, and arguably most importantly, is another role that oftentimes organizations don't recognize the need for and that is quality assurance.
This is someone that can be sort of outside looking in, identifying risks, mitigating risks, helping the steering committee and other parts of the project team make decisions as it relates to their business, and bringing everything together.
What happens oftentimes, when you're working on a project team, (if you've ever been involved with a transformation, you can probably relate to this), you tend to get so far down in the weeds day to day during a transformation. Things are moving so quickly that it becomes very easy to forget or not have the time to back up and look at the big picture. You must be able to identify all the different pitfalls and risks that are out on the horizon. That's the role that a quality assurance person can provide.
As you're constructing your project team, these are some areas you want to make sure you don't overlook. When you're defining your overall project plan, your resource plan, and your budget, you want to make sure you're not basing it on typical things but you're looking at the whole picture of everything that's required to make the project successful.
I hope this has provided some guidance on how to structure your project team and given you some things to think about as you structure your project team. For more information on this, I encourage you to check our 2021 digital transformation report, which includes a lot of best practices around how to structure an implementation, how to structure a team, how to handle change management.
If you’d like to discuss more on project teams and how it might help your organization, please reach out to me directly. I’m happy to be a sounding board and walk you through the opportunity and obstacles of building a solid project team to help you succeed.
