Tag: HTH

The following is a set of techniques that at WMG, Warwick University I have led and implemented on various digital projects to great success. Stakeholders are happy with it, and they’re not inadvertently altering the success chance of the projects.

You’ll recognise this. Every project you run, has a plethora of stakeholders involved. In some large organisations too, you’ll find they enjoy a rather flat structure where everyone’s opinion is valid and should be considered.

So when you invite lots of people to a meeting, you come out with a mess of features and a confusing array of project actions which possibly didn’t need chasing up. Because of this we need a framework that will allow for ideas from all people, but only qualify the ones which are “goers”.

Here’s 4 tips that I use with my teams at WMG to both keep the stakeholders happy. It makes but the project the most important success factor, not egos. It makes everyone nearly equal.

1. Have a shared Product Backlog or the “the duff idea buffer”

Headline.
This is a place where all ideas are held and are accessible to every stakeholder. This isn’t an obtuse Word Document you keep emailing round with “Track changes on” and forgetting to CC (Carbon Copy) people in, but more like a shared pinboard on Trello.com which you can export every so often to Excel.

Reasoning.
The reason for having a shared Product Backlog is more to do with human behaviour than anything else. Often in a working group of many, you’ll find most of the angst is whether or not someone’s personal idea was set down and recorded. Some / most of the suggestions will be pants, off-topic and not worth the keystrokes you took to record it, that’s natural, we all do it.

However, if it’s fairly recorded somewhere you can move on, rather than discussing its use-fullness there and then.

Often you’ll find that the person who raised it, after a couple of days, gets some perspective and realises they don’t think the idea’s any good anymore.

1. Have a Product Owner (the gatekeeper)

Headline.
This is 1 person. Not two, three or 12. Just 1. It is 1 person who was voted by the stakeholders as the “best decision maker for the project” and who always decides what’s the most important action for the project next.

Reasoning.
So sure, the stakeholders have now had their thoughts recorded into the backlog, but let’s be honest, quite a lot of that might not be immediately urgent or produce the highest business value. So a Product Owner is voted in by the stakeholders as the person best placed for making decisions on the product.

They have authority. They were voted in by their peers, and so can yay or ney actions confidently. Also, if you’re worried about someone being voted in that’s a bit power hungry, it’s good to know that this role has a lot of responsibility, so their decisions have to be good, they’re picking how the project progresses.

3. Be strict.

Yup. They’ll hate this bit, but you need to vote in someone who can stick to these rules and keep to the rhetoric of, “Great idea, put it in the Backlog”, “You don’t get to pick, it’s the Product Owner’s choice”.

This way, no stakeholders can adjust how the project goes as they agree to the rules of the Product Owner says what’s next. By staying strict it helps fight the “culture eats process for breakfast” saying and starts adjusting how you work together.

4. Keep everyone updated, frequently

Every 2 weeks, re-present to the stakeholders what’s done so far. Then chat about what they think is important next. Invite them all every time, and after a while you’ll see they more just want to leave you to your work and don’t turn up. Allowing the process to move on.

The Product Owner can then make the decisions based on feedback about what’s next.

I hope that helps!

Note…. In the title, I mean, “happier” with our process, I imagine their first child or standing on a surfboard might also be a happy event.

Often when you’re devving’ forms in Laravel a quick refresh of the page rightly errors on the CSRF token. This is a bit of a bummer if you want to keep testing the same request, so all I do is…

Goto App/Http/Kernel.php and comment out,

// 'AppHttpMiddlewareVerifyCsrfToken',

Then you can dev to your heart’s content, just remember to un-comment it! Maybe write a unit test to check it’s on before allowing you to push or create a merge request. Like one that alters the hidden field and submits.