This document discusses governance of projects and introduces a new approach called ARGYLE. It describes how traditional governance can introduce many problems or "fifty shades" that cause waste and reduce flow. These include issues with defining benefits, oversight, decisions, and people involvement. It then explains how ARGYLE, inspired by lean and agile practices, aims to simplify governance. This is done by reducing burden, eliminating waste, and improving flow. ARGYLE structures governance around decision gates and focuses on key questions about time, cost, desirability, feasibility and viability to improve priorities and flow.
4. bringing sexy back
… to projects
vettri/terryrichardson/justintimberlakefuturesexlovesounds
5. topics
gover-what?
what we are talking
about
the fifty shades
when projects go bump
in the night
lean governance
Introducing ARGYLE,
the sexy new look for projects
8. Governance means the
laws, policies, rules, and processes of how
we run our countries …
shutterstock/grahamprentice/beehive
9. … how we run our state or city
photobucket/gcholman/schwarzenegger
I told
you I’d
be back
10. … how we operate our businesses
alpinevillaretreat/conferenceroom/boardtable
11. … in fact, it‟s how all our processes are
regulated and controlled
paper/davidjcmorris/IDEF0
12. … that includes change processes
cpsu/dmo/changemanagement
… in other words governance
is how everything is regulated,
not especially projects ... however,
this talk is about how it applies to
change initiatives and projects
13. … balancing delegation of authority with
assurance it is wielded wisely
authority
assurances
14. oversight and support is
many-layered …
many opportunities for „bloat‟
paper/davidjcmorris/wrappers
authority assurances
24. Are there really fifty?
flickr/fabiolug/number50a
… actually, there are hundreds of problems, however we can
group and summarise these easily into fifty shades
25. The types of shade
benefits
• defining
• scoping
• tracking
• protecting
oversight
• monitoring
• assuring
• authorising
decisions
• approval
• intervening
• readying
• closing
people
• culture
• champions
• capability
• assignments
Fifty shades of governance? What’s that about? Well, to answer that, consider the question … do you find governance sexy? If it has you falling asleep, rolling your eyes, or running for the hills then the chances are that you have been experiencing bloated governance. Bloated governance ties our projects into knots and forces them through fixed stages and gates to gain access to money and resources. And when people try to work around this, bloated governance just cracks down harder, punishing and pushing transgressors further toward workaround behaviours. Bloated governance tends to become so big, it ends up as its own cost-centre. Irrespective of our aspirations to be more agile in our delivery approach, with bloated governance around our necks, is it any wonder that serial or waterfall project management still prevails? How does this happen? … and can we do anything about it? ______________________________________________________________________________Image credits are given in the form [source/author/title][istockphoto/petrovich9/businessplan (25%) over shutterstock/ilolab/largegrungetexture]
Fifty shades of governance? What’s that about? Well, to answer that, consider the question … do you find governance sexy? If it has you falling asleep, rolling your eyes, or running for the hills then the chances are that you have been experiencing bloated governance. Bloated governance ties our projects into knots and forces them through fixed stages and gates to gain access to money and resources. And when people try to work around this, bloated governance just cracks down harder, punishing and pushing transgressors further toward workaround behaviours. Bloated governance tends to become so big, it ends up as its own cost-centre. Irrespective of our aspirations to be more agile in our delivery approach, with bloated governance around our necks, is it any wonder that serial or waterfall project management still prevails? How does this happen? … and can we do anything about it?
Before we start, meet Fred … … Fred is a business analyst, and he’s fed up: he has to redo things so many times, he hasn’t got buy-in from his sponsor, and even worse his project manager and technical team are taking decisions that undermine the value promised in the business case … … the views and opinions expressed here are based on some of my nightmares of being stuck in the project governance maze and the lean six-step approach to governance I’m proposing is based on experience of what works …… like Fred, at some point, most of us have been stuck in project hell, so this is a typical story … this talk is prompted by these headaches and whether there is a better way …
There is a better way … lean governance … in this presentation I explain why I am so passionate about getting it right. I worked on many early agile projects and introduced agile practices at several organisations during the ‘90s (especially usingDSDM and XP), and we struggled against serial stage-gate governance processes. I had a moment of inspiration to turn the problem on its head, to throw out unproductive processes, focus on key decisions, and get the organisation to trust professionals to prepare adequately without specifying every step they have to take. Do you want to help your organisation bring sexy back to governance, to overcome obsession with process, free your projects from the maze of endless reviews and gate meetings, and easily review a project at any point in the delivery cycle?
Governance is the laws, policies, rules, and process of how we run our countries …
... how we run our states and cities …
... how we operate, regulate, and control our businesses ...
... in fact, it’s how all our processes are operated, regulated, and controlled ...
... and that includes our change processes.Point I’m making here is that governance is not unique to projects, it’s how everything is operated, regulated, and controlled ... And we’re here to talk about how it applies to change initiatives, to projects
Governance is about the balance between the delegation of authority and the assurance that it is being wielded wisely
In terms of change processes, typically around projects, this looks a little like this diagram – with authority delegated to and assurances given from the change agents (developers in this instance) and the wider project team, which in turn are overseen and supported by some form of steering group that implements this delegated authority through agreed governance processes, from the executive board
So, what about these fifty shades, I hear you mumbling ...... Go on, mumble ...
Shades are visitors from the underworld, ghosts if you like …
Shades are visitors from the underworld, ghosts if you like … So in this case, it’s what haunts our projects … like dementors, it’s what sucks the value out of projects and leads to failure?> are there fifty?
No there aren’t really fifty, there are hundreds … we’re only going to scratch the surface … briefly referencing fifty of the more egregious onesI’ve grouped them into four areas where inadequate contribution from organisations leads to value leakage and ultimately project failure
Benefits - defining, scoping, tracking, and protecting benefitsOversight - monitoring, assuring, and authorisingDecisions - approving, intervening, readying, and closingPeople - culture, championing, capability, and assignments
BENEFITS> Not defining the project’s ‘desired business outcomes’ but relying on the project’s deliverables as the measures of success> Not tracking benefits post project because it is ‘too hard’.> No focus on the benefits once the project has been completedSCOPE> Setting the scope too narrow - missing many valuable opportunities> Allowing scope creep - increasing the size and cost of the project, but not the value>Skimping on the requirements identification step - it always catches up with you later> Allowing frequent changes and ‘good ideas’ to be adopted after the needs have been agreed.TRACEABILITY> Allowing the link between the business case and the delivery project to be too weak> Not focussing the project plans and activities on delivering the project’s value.> Not linking each benefit to one or more enabling desired business outcome so as to be able to track its realization.COMPROMISE> De-scoping the project - reducing the value to fit the time/budget constraints.> Skimping on the agreed deliverables to ‘get the project over the line’> Making decisions that destroy the project’s overall value and purpose
MONITOR> Identifying but then not managing or monitoring the CSFs throughout and beyond the project’s duration. > Delaying the decision - thereby causing the project to be delayed> Ignoring the potential ramifications of potential changesIgnoring the early warning signs> Failing to see what is not in the project reporting.> Not governing the plans for benefits realization>Not tracking the project’s ongoing viability and relevance at allQUALITY> Not agreeing the acceptance criteria, leading to confusion as to whether the project has finished> Not instilling the quality dimension on every element of the projectAUTHORITY> Delegating all decisions to the project team - losing sight of what the major issues and problems are.> Abdicating control to consultants> Relying on the project team to take the necessary corrective actions> Assuming the project management team is across these issues/indicators
APPROVAL> Approving projects on the basis of the influence of the senior executive involved>Approving projects whose business outcomes and benefits are not clear (or even known).INTERVENTION> Letting the project go on too long, burning cash> Not taking action soon enough when the indicators turn bad> Not acting on variances to see when shortfalls can be remediated to generate greater value.> Not questioning ‘Why are we still doing this?’ at regular intervals.READINESS> Skimping on the change activities and going ‘live’ before the business is ready.> Ramming the project in, regardless of the business circumstances> Not doing the ‘obvious’ things to help the organization absorb the changes.CLOSURE> Lessons learned, good and bad, are lost> The focus on the on-going delivery of value is forgotten and the value vaporizes.
CULTURE> Allowing business resistance to go unresolved> Missing or ignoring some key stakeholders > Not acting fast when stakeholder commitment is waning. > Letting the business staff become ‘changed out’ and not accepting of any more changeSUPPORT> Allowing the governance team to be seen as not committed to the project - thereby diminishing staff morale.> Viewing project governance as a ‘once-a-month’ commitment> Being seen to make operational decisions that are at odds with the direction of the projectCAPABILITY> Assuming project governance is an extension of operational management> Assuming ‘everyone must know’ how to govern projects.> Not even knowing this is a key role or what the leading indicators are.ASSIGNMENT> Continuing with a project manager you no longer trust or respect.> Pulling staff off the project too soon> Trying to have it both ways - allocating staff to the project but also expecting them to do their normal jobs too.
This is how it feels Fred feeling ... I think that’s the same for all of us at times
What we've learned from lean/agile approaches- eliminate muddah (waste) - proper planning is good, not too much, just enough- why additional controls do not safeguard, and in fact do the oppositeAlso:Boiling governance down to the minimum- how to trust more, and still maintain control- changing the point/level of commitment- adjusting the time horizons- adopting a VC-syle approach (ref. Alan Key ???)
MudaBoil governance down by removing wasteful things:TransportationInventoryMotionWaitingOver-processingOver-productionDefectsImprove the flow
MuraImprove the flow
MuriReduce the burden
PlanningAlso:Boiling governance down to the minimum- how to trust more, and still maintain control- changing the point/level of commitment- adjusting the time horizons- adopting a VC-syle approach (ref. Alan Key ???)
Well, Fred likes the sound of that ... So how can we do it?
- an approach that does away with a governance process with more steps and rigor than the projects they purport to control- enabling organisations to answer the key questions in a single session, or even not in sessionGates within gates within gates- the origins of the name- as gates are really a series of questions, we can consider these to be gates within gates- with each question, we can choose yes, we want to continue, or no and then decide on alternative action, so gates within gates within gates- styling this with process mapping, we get multi-layer diamonds within diamonds, and hence evocative of the argyle pattern- there are six steps and six letters in 'argyle', so we can borrow from the thesaurus, and bend definitions to achieve a series of steps that result in the acronym - ARGYLEPutting it all together- adding the gates with the portfolio approach, and you have an overall governance approach that is lightweight and robust enough
Assuming that we still want to make decisions as are change initiatives run through our change process, we’ll still have gates ...... The key is to make them as light touch as possible.
If gates are key decision points, how can we streamline it by reducing the number of questions we ask?
All too often, the biggest drivers are how long will it take and how much will it cost ...... these are important ... ... and there are some more important questions to ask first
Before we even start thinking about time and cost, we need to consider these three questions first(we often do, but only at the very beginning) Is it desirable? Do we need or want to do this at all?Is it feasible? How well can we deliver it? Is it viable? How well can we operate it? What is the impact?
Finally, if we’ve answered all the other ones positively, we need to decide, with everything else that we’ve currently got going on, do we actually need to start this one right now ... and if so, should we pause or cancel any others
These simple questions often get wrapped up into more complex hand-off points between siloed teams involved in governance, and examples like this are all too common
Reduce to only six steps* Do we want to do it (or still want to do it)* Have we already planned resources/funds for this* How well can we generate this (whether build, buy, or partner)* How well can we operate and support this* Can we launch it in time
Wanted to represent this graphically even more simplyAs the gate is itself a decision, I decided to show the decision diamonds within a larger decision diamondThe pattern and colours reminded me of the ARGYLE pattern, so as there are six decisions and six letters in ARGYLE, the six decisions have been named to spell out ARGYLE
Now playing that back into the NPD, you still have a straight forward model to work fromAnd, the ARGYLE model works irrespective of the project management methodology you’re following. On agile projects, you’re still asking these questions – do we want to keep going, do we have funds, do we know how to deliver it, what’s the impact on us to operate it, and how do we prioritise against other initiatives. The great thing is, you can use the same approach on less agile projects too. Have your governance meetings on a regular heartbeat, e.g. 2 weeks or 4 weeks, and have your projects report into that too, that way you can assess where projects are against a backdrop of new ideas and other in-flight projects, and more safely take decisions to pause, cancel, or continue
Now playing that back into the NPD, you still have a straight forward model to work fromAnd, the ARGYLE model works irrespective of the project management methodology you’re following. On agile projects, you’re still asking these questions – do we want to keep going, do we have funds, do we know how to deliver it, what’s the impact on us to operate it, and how do we prioritise against other initiatives. The great thing is, you can use the same approach on less agile projects too. Have your governance meetings on a regular heartbeat, e.g. 2 weeks or 4 weeks, and have your projects report into that too, that way you can assess where projects are against a backdrop of new ideas and other in-flight projects, and more safely take decisions to pause, cancel, or continue
cut things as short as possiblereduce sign-offs (number and elapsed)agitatetalk to the CIOvolunteerwe are not humble, we are BAs