Before you create that project schedule you need to know what is going on there, and that means understanding your project requirements.
Increasingly, I’m finding myself work on projects where the requirements are not clearly defined. In some cases you may find that a business analyst has worked on the project before you and done the hard work of finding out what the team wants. Or the project is really straightforward and it’s easy to see. Or, more likely, you’ll be in the same position as me and need to elicit the requirements before you can begin work.
We talk about ‘eliciting’ requirements now, because they aren’t just lying around ready to be collected. Often, the business users won’t know what they want – although they’ll have a clear idea of what they want the end result to be – and you have to work with them to define it.
Here are 5 ways that you can work with your team and stakeholder to gather those project requirements.
Interviews are one of the simplest ways to talk to people about what they want. You can arrange a face-to-face meeting with a stakeholder and let them tell you their objectives, then work together to form that into requirements.
Meetings like this also give you the perfect opportunity to prepare in advance. You’ll know a little bit about the project so you can come up with some questions prior to your meeting to help the discussion along.
Interviews can be time-consuming because you have to meet with everyone individually. They work best for projects where there are only a few stakeholders because at some point you’ll have to put everyone’s requirements together and you may uncover conflicting priorities. That’s easier to handle if there are only a few people involved.
Workshops are requirements meetings for more than one person – a step up from the interviews mentioned above. Get a group together and use your facilitation skills to help them see how to think outside the box.
The aim is to leave the meeting with a comprehensive view of the project’s requirements, although there is always likely to be something you uncover later as you turn those hurried workshop notes into a project schedule.
On The Phone
This isn’t my preferred way of eliciting requirements, so I’d only use it as a last resort. You miss a lot of the body language of face-to-face meetings but it’s better than nothing.
Follow up phone calls are good at checking your understanding after the event. If you’ve recently held a workshop and don’t understand something in your notes a few days later, that’s the time to call the relevant person and talk it through with them.
This will save you time in the longer term because you’ll be checking and amending as you go.
Focus groups are generally used when your project involves delivering something to the public. For example, if you are making a new product: you’ll get a group of customers (or potential customers) together and ask them what they want from the product before you start building it. Then you’ve got more chance of hitting the market’s needs when the product goes on sale.
If you think focus groups would be a good idea to uncover more requirements for your project, I’d recommend getting someone in to help run them. You’ll want to handle the meeting carefully, asking structured questions and maybe showing a demo or prototype. Even if the people attending are doing you a favour (although it’s common to give them vouchers or a small gift as a thank you) you’ll want to leave them with a positive impression of your company.
You can use online tools to help you gather requirements, but working with your team do that using collaboration software can be tricky. When you are all sharing the same view of your mind-mapping software as the result of screen sharing in Skype or similar, then you can bounce ideas off each other. Plus it saves you time typing up the results later!
You can also use collaboration tools and mind-mapping software to capture the output of your face-to-face meetings and workshops as you go, by having it open during the meeting and nominating someone to ‘scribe’ onto the computer.
In reality, you are likely to use a number of these techniques on the same project, sometimes at the same time. You’ll be on the phone with someone and have your project mindmaps open in front of you. You’ll be in a workshop and then break out to talk to one person individually while the rest of the group discusses something else. You have to pick and choose the tools and approaches that you feel will give you the best and most comprehensive view of what the project is supposed to be delivering.
Armed with that knowledge, you can put the details into your project schedule and then share that with everyone using a tool like ScheduleReader, so that you don't have to grant everyone access to your high-powered scheduling tools but they can still see the plan.
Once you’ve agreed your requirements and put together your schedule, you should be comfortable about being able to deliver what your stakeholders have asked for.