We’re ignoring our stakeholders and they couldn’t be happier!

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.

 

Being brave enough to change a process

Today we had to change a large process that wasn’t working.

The State.

A web development being built hasn’t got automated tests written for it and requires an office member to go through and MANUALLY test every item. Basically what Behat or DalekJS should be doing…

Anyway, the tests were all written in 1 document. “When I create a module, it should appear in a student’s list”, “When I select 3 modules, it calculates the student’s points correctly”, etc…

My process to solving a process.

Sometimes improving it can feel a bit daunting, however, as you talk through it with the team, record small sticking points and pains, then the you should start to see a bigger picture.
Always remember, you probably just need an evolution not a total revolution.

Steps…

  1. Remind the team, that they own this process so they will want to find solutions to save themselves time
  2. Talk through the whole process, record EVERY sticking point
  3. Look through the sticking points for the worst offenders
  4. Think of simple ideas to fix them
  5. Repeat 4 until happy 🙂
  6. Talk it through with all the team
  7. Go!
  8. Re-look at it again soon!

Our Biggest Problems were…

  • Testing document, who has the latest copy and where?
  • TheTesting document is really fiddly for comments
  • TheTesting document doesn’t really handle versions very well
  • It’s difficult to discuss the comments inside theTesting document
  • What should the developer work on next?

Some solutions…

  • Testing document has been moved to a Shared OneDrive for all the project Team.
  • Re-named testing document “Testing Document v1” to “Testing Document”, losing the version number indicated its “alive” state
  • All Passes are still recorded in the Testing document with the word “Pass”
  • All Fails are recorded int he Testing document as “Fail”, but no comment
  • All Fails with comments are created as tickets in a Trello board with the unique test id and a description of the fail
  • All Fails are re-ordered in the list by the Product Owner to show importance
  • A Trello list was created for the Product Owner to rack up no more than 5 tickets which the need the developer to work on next

Should you allow clients into your bug tracking software?

I believe yes, you should. With the proper caveats and training, your client should be able to see what’s going on.

The client has fewer surprises, is in on the problems and #FTW’s. They feel more connected to the product and weirdly will start to feel more “onside”.

Sure it might seem scary at first, but after the initial storming, the process does begin forming!

It’s all about improving process through transparency.