how to manage a project where roles aren’t clear

Ever managed or worked on a project where it wasn’t clear who should be playing what role, some pieces of the work didn’t get done, and the project languished because no one was explicitly charged with driving the project onward? (If you’ve ever been involved with any project with multiple people, the answer is probably yes.)

One absolute fundamental to successfully managing projects is to set up clear roles from the start, so that everyone involved knows who is responsible for what.

It’s particularly helpful if your project team has a shared vocabulary to talk about the roles people will play. There are different models you can use to do this, but one good one is the “MOCHA” model from The Management Center (so named, they say, because if you do this right your job will become easier and you can sit in a café drinking mochas all day):

MOCHA

Manager: Manager assigns responsibility and holds owner accountable. Makes suggestions, asks hard questions, reviews progress, serves as a resource, and intervenes if things are off-track.

Owner: Owner has overall responsibility for the success or failure of the project. Ensures that all the work gets done (directly or via helpers) and that others are involved appropriately.  (Note: there should only be one owner!)

Consulted: Consulted should be asked for input and/or needs to be brought in.

Helper: Helpers(s) are available to help do part of the work.

Approver: Approver signs off on decisions before they’re final. May be the Owner or Manager, although might be others in the organization (for example, in high-profile projects, your VP or CEO).

Note that in this model, O is the most important role, because that gives you a clear owner who is responsible for the success or failure of the project. And since the owner has final responsibility for the success of the project, it’s crucial that you only have one owner. (Otherwise you’ll find that the overall responsibility gets diffused and people get unclear about their roles again.)

Also note that the manager and owner of a project should be two different people, since the manager’s role is to ask hard questions and hold the owner accountable.

So for example, let’s say that you’re in charge of overseeing a proposal process. You’d be the “O” (owner) and in charge of making the work happen. Your own manager might be the “M” (manager) because she’s managing your work on the project. Other team leaders should be consulted (“C”), and your writer, editor, and research assistant are the “H’s” (helpers). Your manager and the VP of Sales might be the “A’s” because they’ll approve the final proposal.

Manager Owner Consulted Helper(s) Approver
Jane Marco All relevant team leaders: Dave, Maria, Jen Sarah (writing), Paul (editing), Ana (research) Jane (first), Kate (final)

Using a shared vocabulary like this makes it easier to assign responsibilities, because everyone is clear on what roles they and others are playing. Once everyone on your team is using the same vocabulary to talk about roles, you can say things like, “Could you own getting all the content for this together?” or “While Jane is the A and will make the final decision, I’d love your input on this and would like to use you as a C.”

Try this model the next time you’re managing a project where multiple people are involved and see how it goes!

{ 21 comments… read them below }

  1. The Other Dawn*

    This is very timely for me, as I’m just starting on my very first multi-person project. The company I was at for 17 years was so small that it was normally me, myself and I on a project so didn’t have to manage multiple people. I’ve been pretty nervous about how I’ll handle it and keep track of everything, so this came at exactly the right time! I’ve also started a spreadsheet listing out all the tasks I think need to get done, who will do them, what resources we need, a Comments column, and then numbered all the tasks so we can do them in the right order. Hopefully I’m on the right track.

    1. Monika*

      Keeping everything on track is the bread and butter of projectmanagement. Tools like MSProject or the opensource ProjectLibre are really really helpful for that. I esp. like the Gantt view, because it’s easy to see when there’s a time problem/conflict.

  2. Stuck in the Snow*

    I think this is causing me to having traumatic flashbacks to a PM training where we each had to bring a project we were working on as our individual case study for the class. After I was done explaining my project, a senior-level officer asked me “are you being set up to fail? because from my perspective, that’s what it looks like”. It was simultaneously embarrassing and the most helpful thing I’d ever been told at this job (aka, the people I worked under couldn’t manage their way out of a paper bag).

  3. Jamie*

    I love the acronym. From the beginning of time I’ve never run a project without each owner and approval clearly communicated as well as deadlines and checkpoints. Need to know who is waiting on what from whom? Check the gantt chart, workflow, spreadsheet…whichever is my medium du jour.

    Years ago in my first project meeting with a new boss I saw him insist that every task have an owner and a deadline and made sure someone documented that and sent it to all relevant parties. At that very moment I knew we’d work very well together.

    1. land of oaks*

      I think I would be more likely to use this just because the acronym makes me think of Chocolate…. Mmmmmmm, mooccccchaaaaaaa…….

  4. Cath in Canada*

    Our Projects team spent the (relatively) quiet summer months of 2013 doing a detailed analysis of roles and responsibilities within some of our common processes. We used the RACI system (responsible, accountable, consulted, informed), rather than MOCHA, which looks somewhat similar. We each led the analysis for one process and took part in the analysis of two others, and we presented our work back to the wider group in our weekly team meetings. It was actually a really valuable exercise that’s made these common processes flow much more smoothly, and helped new hires come up to speed faster. And it’s kinda fun filling in the matrix of roles for each sub-task – like a logic puzzle! Definitely worthwhile.

  5. Ama*

    I often find prescriptive models not flexible enough for my needs, but this is a really good one. It makes me realize that a big problem at my previous job was asking coworkers to do what my boss (the Manager) and I considered Consultant or Approver type roles, but the coworker interpreted as a Manager role. If we’d had clarity up front about those being different and distinct roles it might have saved everyone a lot of confusion and bruised egos.

  6. ThursdaysGeek*

    I’ve been on projects like that, but I was just the helper. So I started asking questions, taking responsibility for getting things organized, and keeping things on track. It needed to be done, and while I would have been happy if the manager were taking the reins, or the owner were keeping people on track, I was willing to pick up the slack I could see. I made sure things worked together, did the dirty work that others didn’t want to, did the finish work that others didn’t want to, and made sure it was actually done and available to the owner, the way they wanted and needed it, rather than just generally mostly kind of done.

    At LastJob, where that happened, I called myself the mortar. My team lead had the vision to see where a wall needed to built, and worked with the owner to get the materials (us). My co-workers were the pretty rocks that made up the wall, building their pieces of the solution and being visible. And I was the mortar, holding things together, integrating, not very visible, but absolutely necessary to make a strong wall.

    Too bad when they had layoffs, all that our management could see were the rocks in the finished walls, and thought that’s all they needed to make more.

  7. Jaydee*

    This is wonderful! I have never fully understood our structure for some of the projects I work on because they aren’t often laid out this clearly. But now I can think about who has what roles on each, which will make it easier to figure out what I’m supposed to be doing (or not doing, in some cases).

  8. PoisonIvy*

    This is bang on time for me. We have several projects on at the moment where the owner role isn’t clearly defined, and my colleague and I are kind of left to figure out which one of us is the lead (owner).

    There’s been two projects that I thought I was to be the owner that he’s assumed my role on, much to my frustration (one came up while I was on vacation, the other I’d prioritised for later that month and he decided to make a start on it without telling me). I raised this with my manager and at first she suggested I assert myself more but then she said, “Perhaps I need be clearer at the outset who’s leading which project.”

    I have a meeting with her tomorrow. Does anyone think it would be out of line for me to suggest MOCHA? (I’m not based in the USA so I doubt this acronym would have come up here.) She’s mostly a great manager, but I think both my colleague and I are more senior than she’s managed before so I think sometimes she just leaves us to get on with things when a bit of structure would be better..

    1. Ask a Manager* Post author

      I think you definitely could! Frame it as “I came across this and thought about our conversation and thought it could be really useful for us.”

    2. TCO*

      Since you say your boss is a good one, she’d probably be pleased and impressed that you proactively brought a new tool to her that will make your team’s work better.

      1. PoisonIvy*

        Quick update – I shared this with my manager and she thought it was great!

  9. John R*

    Interesting. This is similar to the RACI Matrix (Responsible (Owner), Accountable (Manager), Consulted, Informed) model I learned in a PM class but has a separate role for Approver and the “Helper” role replaces “Informed”. How is someone who is consulted different from a helper?

    1. Jillociraptor*

      We usually define “consulted” as getting their perspective, while “helper” actually does some of the work. So if you’re planning a conference, you might consult the Director of another division about a plenary session (asking for their perspective on what should be included on their area of expertise), but the Helper would actually take that feedback and help to design the session. Consulted’s output is feedback, Helper’s output is a work product. Not sure if that’s MOCHA-scripture :) but that’s how we do it.

    2. Ask a Manager* Post author

      Consulted is just giving input or being a sounding board, whereas a Helper is actually helping to do part of the work. So I might say to someone, “Before you start work on this, talk to Jane, because she’ll have strong opinions on the messaging portion and we want to be sure we incorporate her input.” Or “Talk to Bob because he’s done a lot of this in the past and can tell you what pitfalls to avoid.” Jane and Bob would both be Consulteds. Whereas if I said, “Fergus can handle registering guests at the event,” Fergus is a Helper.

  10. Caryn*

    We were fortunate to have the Management Center come and do our management training. We are an ambitious nonprofit with a bunch of brilliant, overextended and very kind people on our staff and we often defaulted to “everyone plays every role on everything.” Sometimes I think it was simply to avoid hurting feelings (“you’re just a helper on this project, Wakeen, not an owner or approver.”) We were growing quickly and it was really getting in the way of moving forward (in my opinion, anyway). We’ve adopted MOCHA organization-wide and while institutionalizing it takes time, holy cow does it ever work to make things clearer and run more smoothly.

    (As a side note, when Alison’s book, Managing the Change the World, showed up at every chair before we began the first management training session, I may have geeked out a little…!)

Comments are closed.