Seeking out answers

Sorry this post is a day late – I have been distracted with visitors and the Eurostar Da Vinci Code Quest.

I gave my presentation on Scope Management to the British Computer Society’s Project Management Specialist Group on Thursday, which went well. They were kind enough to give me a souvenir paperweight as a memento and I was bought a glass of wine in the pub afterwards, so it was a fair swap. The questions were really interesting in the discussion afterwards. My favourite question of the night was about involving users in requirements gathering, and different approaches to go about doing it.

This is a tricky thing to give a definitive answer on. It really depends on the group you are working with. In my experience, there are two approaches to try:

• interview users separately, then compile their comments. Review them critically to see if any requirements are wildly divergent. In divergent cases, you will have to bring the two parties together to see if they really understand the objectives of the project – perhaps you have two projects muddled up in one requirements document. Guide people carefully and shape what it is they want, as users notoriously don’t have a clue. For example, the first version of the scope of my current directory project was officially to make it ‘better’. If nothing is amiss, circulate the document (using appropriate version control, of course) and wait the torrent of feedback. If you have a tiny stream I would be surprised. That’s your requirements gathering done.
• interview users together. This approach means you benefit from blue sky thinking and the ability of meeting participants to bounce ideas off each other. However, a drawback is that the quality of the output does depend on how you manage the relationships within the room. A team leader present may mean members of her team are reluctant to comment or disagree. A very vocal person means others won’t have the opportunity to comment without some heavy handed facilitating.

The trouble with projects is that getting answers to anything – including what is in scope and what the requirements really are – is so reliant on the people you are working with and the environment in which you are all working. PM is not a technical discipline, it’s definitely a people discipline. If you can’t get a good set of requirements because you can’t relate to the end users, project team and key stakeholders, you have no chance of delivering anything worthwhile. However good your technical ability to run a risk register or use MS Project, your project is already dead in the water.