Jeremy D Clark's Blog | Projects, people, processes, technology

Hidden stakeholders have hidden requirements

Posted on 19/12/2014 by JeremyDClark

You probably think you know who your stakeholders are. Somewhere in your project documentation, you have a list, with a RACI Matrix to show each person’s level of involvement. If you are using PRINCE2, then it is probably in the Project Brief or the Communication Plan.

However, it is very likely that there are other stakeholders who are not included in this list, who are not involved in the project, yet who have the authority to prevent the project from going into production if they are unhappy with what has been delivered. They are usually technical specialists who have been with the organisation for a long time and are the main subject matter experts in their field. I call these hidden stakeholders and they are the custodians of hidden requirements.

For example, in a project delivering online bills, somewhere there is specialist who knows (and more importantly, cares) exactly how the bill should look. Their knowledge is at a deeper level than defined in the requirements. Perhaps they weren’t consulted when the requirements were defined, or maybe the requirements are insufficiently detailed. If this billing specialist advises the executive management that the project doesn’t meet their requirements, this can cause you a serious problem, even if the project meets all of its documented requirements. The later in the project that this happens, the more difficult it is to manage. Remember, the billing specialist is not trying to hinder your project out of spite, but because they care so much about their subject area.

You should seek out hidden stakeholders as early as you can and if possible bring them into the project team. At the very least, you need to make sure they are informed of everything in the project that affects their technical speciality, and if they seem unhappy, go and find out why. Find a way to get them on your side and document their hidden requirements. Of course, the Change Board (which has the authority of the executive management) can reject these new requirements if they wish.

Whatever you do, don’t ignore hidden stakeholders! They know more than you, (or anyone else in the organisation) does about their speciality and consequently they may wield far greater influence than you expect.

Issue tracking workflows

Posted on 11/09/2014 by JeremyDClark

You probably have a defect or issue tracker for your project (if you don’t, you should): Quality Center, Bugzilla and Jira are popular choices.

When you set up an issue tracker, you have to set up the workflow or modify the default workflow: you need to specify:

Statuses: the list of states in which issue can be, including the initial and final states
Transitions: the allowable status changes
User roles: who is allowed to make each transition

Here is the default workflow for Jira (you can find it at: https://confluence.atlassian.com/display/JIRA/What+is+Workflow)

This workflow has 5 statuses and 12 transitions. It isn’t shown on the diagram, but by default, Jira allows all users to execute any transition, so for the purposes of this discussion, it has just one user role.

Soon after you set up your issue tracker, the Test team will probably ask for new statuses ‘Ready for Testing’ and ‘In Testing’. The Deployment team will ask for ‘Ready for Deployment’ and the Support team will ask for ‘Under Investigation’ and ‘Awaiting Customer Information’. Maybe someone will ask for ‘Awaiting UI approval’. If you agree to all these requests, you very quickly end up with a large number of statuses. And for each one, you need to manage the transitions between them and the roles allowed to make those transitions. That can quickly become a lot of work.

It can also become time-consuming for reporting: you will probably have unproductive debates over whether or not you should count ‘Ready for Deployment’ as an Open defect or a Resolved. These discussions are a distraction from the real work of getting the defects fixed. Only you can decide which statuses are entirely necessary, but always question the need for a new status, and keep the number to the minimum.

Some other suggestions:

Minimise the number of user roles – unless you have some compelling business reason to restrict transtions, allow anyone to make any allowable transition. It is much easier to manage and on the rare occasion that someone makes a transition they shouldn’t, education is far more effective than locking down the system. Virtually all issue trackers log the history, so it is very easy for anyone in the team to figure out who messed up and correct it.
There should be just one final status, and it should be called Closed. If you have more than one final state, you have to spend time reminding people and answering questions about it – it just confuses people.

Remote Working

Posted on 27/08/2014 by JeremyDClark

I am about half way through reading Remote – Office Not Required. The overall message is clear: you need an overlap of around four hours each working day for the whole team, and a comprehensive set of communication and collaboration tools. Beyond that, all inconveniences can be managed and the benefits substantially outweigh the difficulties.

This is exactly my own experience: you have to have sufficient time in the day to synchronise with everyone you work with, and this works fine using realtime collaboration tools such as Skype and Webex. To make the best use of this limited time, you also need a range of asynchronous tools, including document/code repositories, issue trackers and, (of course) email. When the team uses them effectively, they can be very productive, and what matters is the work produced.

The converse is also true: when everyone has to be on site every day, the measurement of performance becomes the number of hours present in the office. Not only is this counter-productive, but it is rather disconcerting to see dedicated professionals become clock-watchers.

Spreadsheets are not collaboration tools

Posted on 16/06/2014 by JeremyDClark

I love spreadsheets: they are great for data analysis, creating charts and sometimes for presenting information. However, I have worked on numerous projects where spreadsheets are used for issue tracking actions and issues. Often this is because they are the only tool available – that’s a management failure – and sometimes because a spreadsheet is the default tool for the project manager.

The problem is that it is very difficult to use spreadsheets collaboratively – telling your team to ‘just update the spreadsheet on the shared drive’ doesn’t work: either they don’t update it, or they add information in an unstructured way and the project manager has to tidy it up later. Either way, the project manager ends up doing unnecessary work gathering the inputs and actively managing every issue within their project – information that is usually well known to the team, which they would share if they could.

If you are the project manager, resist the use of spreadsheets and use a more appropriate tool for tracking your project. There are lots of options available, depending on the size of your project and organisation: for small projects and teams, you might find Trello or Basecamp are perfect. For larger projects consider Jira, which can extend far beyond issue tracking with numerous add-ons.

Of course, you still need a spreadsheet, because you have to communicate to others outside the project team who don’t have access to your collaboration tool: just export the items you want to share into a spreadsheet, apply a bit of formatting and maybe a pivot table, and you have an instant report.

In summary, if you want to produce an insightful table or a pretty chart, use a spreadsheet. If you want a collaboration tool, use something else. The subject of using the right tools for your situation, is something I will return to in future posts.