Posts Tagged ‘brief’

Requirements Gathering – Finding What User Wants

Tuesday, June 2nd, 2009

Often in big blue sky projects there is no brief. The end users see an opportunity or have a problem and require a solution.

When there is no brief requirement gathering is a real skill and can involve the following tools:

Questionnaires

This is a quick method to get a wide range of responses from a large number of people. There are lots of online tools that will collate the answers for you. However this method is not widely used as it is subject to question bias and most people will not fill it in with enough care.

Interviews

One on one interviews with key users and stakeholders is an excellent way to find out what users really want. Face to face the interviewer (if they are experienced) can really hone in and find out what the key motivations are.

Observing

Watching people in their operational environment can be a good way to identify requirements, Ideo have made this technique famous as a route for innovation. This only works if you are trying to improve a product and not if the product is entirely new.

Focus Groups

Getting different groups of people together and asking them what they want and then really listening to what they say can be very productive in getting to the real requirements. It requires great skill for the facilitator to keep the conversations on topic.

Requirements Testing

Remember that once you have formulated your requirements they should go through thourough testing and review. Once they have been agreed by the sponsor they should be baselined and subject to change control to stop scope creep.

Project Preparation

Friday, March 27th, 2009

As you move forward in your working life, you find more and more success factors that make projects more likely to succeed.

I see a lot of people picking up their pencil to start designing, or opening their IDE to start programming; before they have the relevant project information and before the appropriate analysis has been completed.

Before you begin a project you must have at least the following:

Brief

What are you doing?
What is the scope of the project?

You need to know the benefits or business change that the project sponsor requires, or you will not be able to find the best solution.

Rationale

What is your rationale for the solution you have chosen?
Will it hold up to scrutiny and analysis?
Most importantly does it answer the brief?

You need to know you have found the best solution and done plenty of research to back that decision up.

Conclusion

Extra time at the start of the project for preparation means that you are more likely to have a successful project outcome.

We never start designing or programming until these steps are complete and as a result our pitching success rate has increased and our client satisfaction has increased.