Some things you can screw up.
And your project will still be fine.
For other things, you’ve got one chance only.
Get them right or fail.
Defining suitable roles and reponsibilities is one of them.
Why roles and responsibilities matter
Every project is a risky undertaking which can only be brought to success through effective delegation. Everyone on your team must know exactly what they have to do. Otherwise delegation won’t work, and you’ll end up doing the job yourself – which of course, you can’t.
If roles and responsibilities are not clear, your project will blow up like a huge firework. And you’ll be the dumbass who didn’t get things right from the start.
In this article I’m going to show you how to define project roles and responsibilities.
Let’s define roles
A project role is similar to a job type, with the only difference that roles aren’t permanent. A role bundles a set of required skills and responsibilities which belong together.
Examples of project roles:
- project manager
- project sponsor
- software developer
- design engineer
- training coordinator
- project assistant
(Very often, team roles are combined into a generic “project team member” role. So, instead of having software developer and design engineer as separate roles you would only have one ‘project team member’ role).
To come up with a list of roles, ask yourself: What types of people or skills are required to reach the project goal? Go through the project plan and check each task individually.
A ‘roles’ example — from the world of aviation:
Assume you are a business owner who wants to offer flight services between the island you live on and another city. What roles do you need to get the business up and running?
You need at least:
- a pilot to operate the aircraft
- an air traffic controller
- ground handling staff for check-in, baggage, security etc.
That will work for the first year maybe.
However, after a few years this organizational setup may not be sufficient anymore. You’ll need additional pilots, and you want to maintain your fleet of airplanes in-house. So you’ll need additional roles: somebody who manages the pilots (HR staff or a chief pilot), maintenance staff who can perform repairs on the aircraft. Maybe an accountant who does the bookkeeping.
What should you take from this example? You don’t just define roles for the direct workers. Roles are also required for support functions like accounting or HR. And the larger your project is, the more you’ll need management roles or people who handle the communication between teams.
Now, here’s something you need be aware of:
Roles are NOT the same as people.
One person can assume several roles.
Example: In my time as an IT project manager, I also took over the role of a ‘data security officer’. Why was that? Corporate regulations mandated to have this role on every project. And as I had some experience in data security I took over this additional role (it required only a few extra hours every month).
Next, this should be obvious:
Several people can fill the same role.
In a large project, you obviously need more than one person who can do the work: You need ten engineers, ten software developers, five training coordinators etc. All assume the same roles with identical responsibilities.
Adrian’s tips for defining project roles:
- The following standard roles should be represented in every project: project manager (you), steering committee, project sponsor, project team member (= the guys doing the work)
- Look at required skills to get the project done. Not just formal skills but also soft skills.
- Consider the organizational setup of your project or your company. If you work for a parent company with five subsidiaries, you’re probably going to need dedicated teams of sub-project leads or coordinators in each subsidiary.
- Take into account workload when spreading up work to different roles. Your engineer may also be a good coach and could (in theory) do the client training. But if he’s too busy with other work, you may need an extra training coordinator role.
- Check if company regulations demand anyone from legal, HR and other sensitive areas to be involved. Make a proper stakeholder analysis to get that information.
Let’s talk about responsibilities
There are a number of things you expect from your team members. What they have to do. But also how they should carry out their job in order to bring the project to success. That’s what you define with project responsibilities.
Responsibilities are the
things people have to do
but also the how.
Example: Take the example of an engineer, who’s role is to design a new car engine. His main responsibility is to do design work every day. But you want to set boundaries to what he’s designing. So you ask him to stick to the requirements. Every now and then, the engineer may run into problems. The engine may turn out to be too big to fit in the car. So he has to find a way to solve the issue, and you don’t want the engineer to come to you every time he’s stuck. Problem solving is part of his responsibility! However, if there’s a major problem he can’t fix himself, you want him to give you a heads-up.
The responsibilities of the engineer would look as follows:
Let’s summarize what I’ve taught you:
Adrian’s tips for defining responsibilities:
- What and how: A good responsibility description covers both the what and how: What exactly people are supposed to do, and also how they should do it.
- Responsibility to meet deadlines: People tend to miss agreed deadlines. You want to make sure people on your team understand that deadlines are not for fun but have to be met.
- Responsibility for communication: Communication is the most critical factor in a project. If people talk with each other to resolve issues or pass on important news, a project has a good chance of succeeding. You want to instill this understanding also in your team. The responsibility overview should include stakeholders they should communicate with proactively.
Tip: A very effective way to clarify roles and responsibilities is to create a RACI chart.
Roles and responsibilities need to be communicated
Once you’ve come up with a roles and responsibility overview, the next step is to communicate the same to your team.
I like to sit together with each member of my team and explain what my expectations are. People get a chance to ask questions or raise their concerns, and it’s more of a dialog than a monologue.
I also present the roles and responsibilities during the project kick-off meeting, which is like the final briefing before everybody gets on their desk to start working.
Do you have a question for me?
Just post it in the comments, and I’ll get back to you!
Talk soon,
