Article Overview
In this "myViewpoint", I take a look at the different levels of "control". I put " around control so as to make sure this is not seen as "command and control". The article discusses the levels of accountability and responsibility within a project as to how much, what, and the key roles involved. However, control is important as projects are business and decisions need to be made and direction and guidance are given.
Table Of Contents
- Decision
- Direction
- Driving
- Delivering
- Fulfilling These Roles
This article looks at the different levels of roles and accountability, therefore responsibilities within our change initiatives. This means from the top down and I believe there are four different levels controls which are,
- Decision-making
- Giving direction
- Driving the change
- Delivering the change.
By the latter I mean at the bottom end, literally doing the development work, whatever it happens to be, the supply work, if you like, providing the solution itself, remember usually in projects.
The reason why I've separated them out is that there is a difference between them, and I think it's quite important to understand what these differences are.
When we talk about "Decision" making, this is a strategic level and it's providing the level of governance needed depending on the change needed, program or project, and usually driven from the portfolio level. These are the guys at Corporate, "C" level, above the PM, (the PM being either portfolio, program, and/or project managers). From a decision point of view, these are guys that making those decisions at the corporate business level about the change itself from a strategic fit perspective. Is it still wanted, is it all going to be built the way they want it to be built and will it actually deliver the benefits, the transformational change, that they're looking for from this initiative itself.
These are the guys that understand the business and the organization, understand its mission, the objects, and therefore the strategies, about making those changes, and ultimately the tactics on how would you deliver those changes through the programs and projects.
The next level down is giving "Direction". The same group of people, the stakeholders, at this level, would also be giving direction and quite often that ad hoc if you like. The PMs could be saying, "well not too sure about this, this is the state of play and therefore what do we need to do next", or sometimes they'll just come along with it themselves.
In another article I've written about capacity appetite and tolerance and quite often the tolerance is about how the "Decision" team are empowering the PMs to get on with the work, so only when it looks like they are going to go past the tolerance, (forecast this by the way!), do they need to first escalate in a sort of informal way, and come up and ask for some guidance for some direction as to what might be the next state of play. Note on the graphic I have included both PM's and above because the PM's will also be giving some direction to the teams below. program managers to the project managers, and the project managers to the guys doing the work.
Then we come to the next level which is "Driving", steering the initiative itself which in a way is guidance but with guiding just to differentiate a little bit. This is from the PM's themselves. They're driving the initiatives, running the changes themselves, the function of project management if you're likely, using project management tools and approaches that do that, driving of the initiative, running through the plans, keeping everybody on track, a lot of leadership involved and helping the teams to work by themselves, or helping/guiding overall, the projects to make sure they're on track and working towards the end goal, and in dealing with anything.
This is where the real agility comes in, at that level, project and program agility, on how we need to flex the changes we've got into the plan and to cope with anything that's going to upset the plan or change the way, the direction of the initiative at that point. That is having that mental agility and the tools to support that. This is the "Driving" level.
Finally, we have the people who are working in the delivery area. These are the guys who are supplying the solution for you. The developers, builders, people putting documents together. It doesn't matter what it is, relocating offices, for example, all these things are part of changes that are going on with the organization. Whether it's changing a local process, adding a new product, these are things that these guys down here will be supplied. Developers, suppliers, the guys that are actually doing the work down in the engine room, as I like to call it: the basement guys. They are actually key to the work and they will take their driving and guidance from the PM's to help them keep on track.
Much of the time they're empowered to do the work themselves and make decisions as they go and only need to escalate or need to go the PM and ask for guidance if there's a necessity to do so because the issue/situation is beyond their authority, power. Again this would be based on "tolerances", boundaries, which I talk about in a video on my YouTube channel, "The Sustainable PM".
These are the four key areas and the reason why write to explain all this is that quite often we have to find the right people to fulfill these key roles. When the roles define, generically, for an initiative, program, or project level, even portfolio, there'll be a generic level of skills, knowledge, background, and understanding about those changes, that apply to changes initially. When it comes to your specific change, of course, that would have an added extra complexity to it because your change will have something that's different from other changes.
Remember each change is unique, each project is unique, each program will be unique and therefore have its own challenges. A relocation is going to be quite different from putting a building up, which is quite different to putting a new process in place or putting a new mobile app out there. Each of these will dictate different skill sets needed for that type of initiative. So there will be an "add-on" to the generic description of accountability and responsibility.
This means we now need to fit the person in there who has those background skills and knowledge and therefore was able to handle those responsibilities and will have that accountability. That's quite important, that is a difference. so remember the role defines who I need to put in it!
The trouble is we have a bit of confusion, as I've mentioned in other articles and videos, about people who say "well I'm a project manager". Well, you act as a project manager in most cases, however, you might well have the skill set to be a program manager, a Project Director, or even a scrum master because the role itself, within the initiative, defines the different needs, and you may well have those skills to fit those needs. This is very important as the role stays in the initiative as a program manager, as a business change manager, as a developer, or a Business Analyst. these role descriptions stay with their particular initiatives. It's the person who will have the skills to fit that who may move around. The tricky bit is that we need to understand what these skill sets are and who will be the best fit for that specific initiative.
Then comes the problem how do I find those people. Well, that's the tricky bit, because you are not always going to find someone's got 100% what you need. Brilliant if you do, and then they might not be available or want to be available! That's one of the key problems, You got to find out who's actually available to do the change and has the nearest set of skills that are needed for the change and where do they fit into the scheme of things. so we have decision-makers for governance, we have people giving direction, give direction therefore guidance. We have those involved in driving the changes themselves, steering it and guiding the guys underneath it and we have our guys doing the work on the delivery, who are developing the solution, building the solution for you, and therefore working with everybody else as a collective/team. The team is everybody involved in it, and quite often a broader picture than that as well. Teams are not just the guys down at the delivery level, it's everyone involved in the whole change initiative.
Realistically, it's the whole organization to some level or another. an analogy I often use is liking it to a sports club. The guys on the pitch are the main team playing (Delivery), the captains are the PMs (Direction/Driving), or team manager if you wish, PMs often sitting on the side a lot of time, or should be, but the club is supporting the whole the game itself. Members of the club (PMO - support) putting fixtures in place, getting the teams out there, getting other clubs to participate, the club executives with the overall view to the clubs' goals and aspirations (Decision/Direction level), everything it takes for a sports club to run effectively, whether it's an amateur club or a big football club there's no difference. At the end of the day, the whole has to work collectively. Just as an organization does.
I have a video on my YouTube channel that discusses this.