An example of Governance as a Service

Checking-in with our project sponsors

Richard McLean
3 min readAug 13, 2021

Many people have highlighted how governance can hinder rather than support delivery, particularly delivery of agile/digital projects & products.

But it needn’t be like that. I know from my own experience that governance can be a service that responds to the needs of those who use it.

Nonetheless, beyond helpful principles, practical suggestions of how to improve governance are rare, and in particular I’ve not seen many case studies of things people have tried to make things better. That’s why, a few years ago, I decided to write about what I had done to design corporate governance as a service that adds value. Since then, I’ve seen a few more examples of people sharing the work they’re doing to improve governance where they work (shout outs to Cate McLaurin, Robin Linacre, Bea Karol Burks, and Kylie Havelock — I’ve included their fab articles in a reading list about governance as a service).

I find it helpful to read real-life case studies/examples to know what good looks like, and as I had a really positive experience of some governance this week, I thought I’d quickly write it up and share it.

The internet can feel kinda full of people complaining about stuff, I’d like to end the week with a good news story.

I’m currently part of a team working on a project, and we have monthly check-ins with our sponsors. Our most recent check in was this week and it felt to me like a good example of governance as a service, for a number of reasons:

  • We didn’t have to produce any additional report or material, we simply re-used what we’d already produced for ourselves for our own understanding in the team
  • We got asked some really good questions on our thinking that helped check and clarify things for them and for us — kind of the opposite of ‘whatboutery’
https://twitter.com/JanetHughes/status/1394963638256119815
  • We were given an interesting problem to chew on and challenged to see we think how we might solve it (we weren’t told what to do)
  • We went in to the meeting with three questions for our sponsors and came out with three clear answers. The questions only came up for us as a team last week. (Projects generally, and fast-paced digital work specifically, are more likely to be successful when they have reactive and decisive governance.)
  • They made a connection we hadn’t considered between one aspect of our work another project going on that’s going on, which we will now follow up and has helped us avoid a potential issue further down the line
  • We were given new ideas, which give us a new option to explore
  • We were given backing and encouragement
  • We had spent a few days concerned in case an element of our plan would be unacceptable. Quickly sharing this risk with our sponsors helped us know that we can carry on in confidence that what we’re planning is ok

In summary, and boiling it down to user needs, I think the check-in was effective and efficient governance because:

  • The sponsors got the assurance they needed
  • As a project team, as we got the direction, support and backing we needed, when we needed it.

Coincidentally, Camille Fournier, arguing for some lightweight process/structure rather than none, recently advocated monthly check-ins for guiding critical projects, and there’s much I agree with in her article. She recommended such check-ins as “a forcing function” and highlighted their effectiveness in situations where there is misalignment, or a manager who isn’t getting into the details enough, or for a strategic area where there is uncertainty about direction.

(Camille highlights that these meeting are also a chance for the team “to show off”, which sounds a bit derogatory and I would recast as ‘visibility’ or ‘exposure’, which certainly can be important for people. Indeed, according to Harry J Coleman, it is the biggest factor in who gets promoted.)

My example shows that that the much-maligned monthly check in can be valuable in other situations too. Perhaps the key is whether they follow the spirit of the 12th principle of the agile manifesto:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

--

--

Richard McLean
Richard McLean

Written by Richard McLean

Chief of staff @ElsevierConnect (Academic & Government group). Mainly writing about getting from A to B, teams, & digital product stuff. Personal account.

No responses yet