Should your PMaaS provider just be “Supportive” in RASCI? Stoneseed explores when it makes sense to own the R and even the A -and why that changes delivery outcomes.
Don’t judge me, my current obsession is a matrix.
Not The Matrix, the 1999 movie (although every day increasingly feels like we’re living its dystopian plot; also, who doesn’t love a Keanu movie?!)
No … A matrix. Actually, any project management matrix.
Love them! So simple and so effective. Genius.
Many Stoneseed clients opt for the RACI matrix for mapping project roles and responsibilities. I think it’s my favourite.
RACI provides a practical grid to map every task or deliverable against team roles. It uses four codes: Responsible (who does the work), Accountable (who signs off and owns the outcome), Consulted (who provides input), and Informed (who stays updated).
My obsession, again, don’t judge me, lies in fathoming where Stoneseed and our Project Management as a Service models fit each matrix. PMaaS isn’t just hiring a pair of hands to help deliver your projects, it works best as a strategic partner, so there is a logic behind my obsession, in case you were starting to think of me as a geeky nerd. (As if- ED)
So far, I’ve worked out Stoneseed’s role in:
RACI-VS
CAIRO
PACSI
RAPID
DACI
DARCI
ARPA
DARE
Oh, and of course …
KEANU (haha – I made this up. Head to the matrix glossary* at the end to find out what it could stand for).
*There is a short paragraph that briefly explains each of these. Who knew there were so many?! (Er, only one person I can think of – ED)
RACI WITH ADDED “S”
Lately, we’ve noticed clients using the “upgraded” RACI matrix that adds an “S”. For Stoneseed, surely?!
Actually, the “S” in RASCI (I’ve also seen RASIC) stands for “Supportive”.
Still, like Keanu in “The Matrix” – it’s the role we were born to play.
I guess the clue is in the “as a Service” bit of PMaaS – PMaaS is deployed to be at the service of the R, A, C and I guys.
Returning to my peak-nerd work, where I evaluated Stoneseed’s part in ALL the other matrices, what’s interesting is: this is the default role we’re given by many clients, regardless of their matrix of choice.
They get all great results, of course, but the clients who are getting the best outcomes are those who elevate PMaaS so it becomes a strategic partner of those R, A, C and I guys.
We don’t mind being S for supportive. It’s a perfectly good letter, some of the world’s best companies start with an “S”. But if that’s the only letter you ever give us, you’re leaving a lot of value on the table, and probably slowing your programme down in the process.
Why “S-only” is a comfortable habit, not a strategy
We get why it happens. RASCI (or RACI, if your organisation hasn’t added the Supportive role) is meant to bring clarity to who does what. Somewhere along the way, external providers like us tend to get filed under “helpful extra pair of hands” almost by default, regardless of what we’re actually contracted to deliver. It’s the assumption that’s comfortable, not necessarily the one that reflects reality.
The trouble is, when you cap PMaaS at Supportive, you cap what we’re allowed to own. Every decision has to travel back up the chain before it can move. Nobody’s clearly on the hook when a workstream drifts. And all that delivery experience we bring, the pattern recognition that comes from having sat inside dozens of programmes just like yours, arrives too late to actually shape anything. It just gets bolted on after the fact.
We’ve seen it play out the same way more times than we can count: a multi-vendor transformation limping along because nobody quite knows who’s allowed to say yes, three suppliers all reporting status slightly differently, and a steering committee that’s become the bottleneck for every decision, big or small. Nothing about that is a resourcing problem. It’s a roles and responsibilities problem, and it’s exactly what RASCI is supposed to solve, if you let it.
Where we’re happiest – owning the R
There’s a set of jobs where we’re not just supporting, we’re doing the work and making the calls within agreed limits. Keeping the schedule honest. Chasing down risks and issues before they become fires. Running the stand ups and checkpoints that keep three or four suppliers rowing in the same direction. Turning the mess of a live programme into a steering pack that actually tells the story.
Give us the R on those and something useful happens: decisions stop queuing up behind a single overworked project manager, everyone gets one place to look for the truth about status and risk, and your own team gets to spend their time on the business change and adoption work that actually needs their fingerprints on it, not on RAID log admin.
Yes, we can carry the A too, with the right guardrails
This is the bit that tends to raise eyebrows. Can a PMaaS provider actually be Accountable? Under the right conditions, yes, and we think it’s often the smartest way to structure the engagement.
It works best when the commercial model matches the responsibility: outcome-based contracts with genuinely clear acceptance criteria, a sponsor who’s happy to delegate a gate or a workstream to us explicitly, or areas like PMO operations and reporting frameworks where, to be honest, we’ve done it more times than most internal teams have had the chance to (owning the accuracy of the integrated master schedule, signing off on go-live readiness within agreed tolerances, that kind of thing).
None of that means you hand over the keys and walk away. It means agreeing up front exactly what we can decide alone, what needs a conversation first, and what still gets escalated, with sensible timeframes attached so nothing sits waiting for a decision that never comes. Put our accountability in the steering pack alongside everyone else’s, and it stops being a leap of faith and starts being ordinary governance.
The C and I roles matter more than people give them credit for
Even where we’re not R or A, being properly Consulted saves everyone time later. We’ve lost count of how many times a quiet word before a scope change gets signed off has saved weeks of rework down the line, because we could see a knock on effect that wasn’t obvious from inside the programme. That’s the outside view working the way it should: when you’re inside the jar, it’s hard to read the label, and part of our job is standing just outside it.
And Informed matters too, if only so we’re never the last to know about a funding change or a shift in priority that quietly invalidates the plan we’ve been working to.
A quick gut check for your next RASCI review
Next time you’re building or revisiting a RASCI matrix with PMaaS in the mix, it’s worth asking a few honest questions. Is there exactly one A on every gate, and have you actually decided whether that should be us or you? Is any single person or team carrying too many R’s that we could reasonably take off their plate? Are there C’s on the chart that have quietly become rubber stamps and could just as easily be I’s? And does anyone know what happens if the R and the A disagree?
None of that is complicated. It just takes someone to actually sit down and ask it, ideally before the programme is already wobbling.
So, supportive is a start, not a ceiling
We’re not precious about being called Supportive.
It’s honest, and plenty of what we do genuinely fits under that heading. It’s just that when a CIO is trying to get a multi-vendor transformation delivering rather than drifting, limiting PMaaS to “S” alone means leaving decision-making authority, delivery ownership, and years of pattern recognition sitting on the sidelines, unused.
Give us the R where we’re best placed to execute, the A where we’ve earned the trust to own an outcome, and the C and I for everything in between, and RASCI stops being a box-ticking exercise and starts being what it was always meant to be: a blueprint for actually getting the thing delivered.
Right, all that RACIng’s given me a thirst, fancy a TEA? (Totally Excessive Acronyms? – ED)
More about Project Management as a Service from Stoneseed
BEYOND RACI & RASCI – A MATRIX GLOSSARY
RACI-VS Adds V (Verifier) for roles that check or test the quality of the work, and S (Signatory) for the specific person who formally approves and signs off on the final output.
CAIRO Adds O (Omitted) to explicitly list who is not involved in a task, which helps prevent scope creep and unnecessary “too many cooks” involvement.
PACSI Swaps terms to focus on governance and agreement: P (Participant/doer), A (Accountable), C (Control/sign-off), S (Sign-off required), and I (Informed).
RAPID Developed by Bain & Company, this framework stands for Recommend, Agree, Perform, Input, and Decide. It focuses intensely on decision authority rather than task execution.
DACI Stands for Driver, Approver, Contributor, and Informed. It clarifies who drives a project component forward versus who holds ultimate sign-off power.
DARCI Similar to RACI but replaces “Responsible” with a Decider or Driver who owns the project path and choice making.
ARPA Focuses on Accountable (business owner), Responsible (execution), Participant/Support (resource provider), and Advisor/Consulted.
DARE Stands for Deciders, Advisors, Recommenders, and Execution stakeholders, designed to streamline fast corporate decision-making.
And … wait for it:
KEANU Keeper (holds the vision/backlog steady), Executor (does the work), Advisor (offers guidance when asked, doesn’t force it), Notified (kept in the loop, no drama), Underwriter (the one person quietly accountable if it all goes sideways). (* While I made this up, I think it would work really well! Remember where you heard it first!!)
SOURCES AND INSPIRATION
I just found an amazing CIO.com article with some brilliant tips and downloadable templates:
FAQ’s
- What does the “S” in RASCI stand for?
It stands for “Supportive” — an addition to the standard RACI matrix (Responsible, Accountable, Consulted, Informed) to flag a supporting role rather than a primary owner. - Can a PMaaS provider be Accountable (the “A”) in a RASCI matrix?
Yes, under the right conditions — typically outcome-based contracts with clear acceptance criteria, an explicit delegation from the sponsor, and well-defined areas like PMO operations or reporting frameworks. - Why shouldn’t external providers only be “Supportive” in RASCI?
Capping a provider at Supportive limits what they’re allowed to own, meaning every decision has to travel back up the chain, nobody’s clearly accountable when a workstream drifts, and their delivery experience arrives too late to shape outcomes. - What questions should you ask when reviewing a RASCI matrix?
Check there’s exactly one “A” per gate, look for anyone carrying too many “R”s that could be redistributed, spot “C”s that have become rubber stamps, and clarify what happens if the R and A disagree.