Thursday, August 27, 2009

Requirements Planning

What's a good requirements plan?

It's certainly not measured by how thorough it is, in fact too much verbiage could be a sign of a bad one.

It's not the one that results in the most detailed and comprehensive set of requirements.

It is most definitely not the one that gets the project through to the nest stage in the fastest possible time.

So what is a good one? In my opinion a good requirements plan give you

The requirements necessary to define an appropriate solution, documented in a form that can be easily consumed by stakeholders, elicited and defined in a way that is sympathetic to the nature of the organisation and project, that can be executed in a timely and cost effective manner.

Parsing that out there are four essential elements to a plan:


  • Requirements: What requirement types will you elicit/define and at what level?

  • Artefacts: What form will you document these requirements in?

  • Techniques: How are you going to interact with stakeholders to elicit requirements and to validate and designs?

  • Execution: When and who is going to perform this work?



For every one of these except Execution you can pick up BABOK 2.0 and get a list of possible answers

I think it's always worth setting some time aside at the start of the project to come up with a requirements plan separate of the project plan. It doesn't have to be formal document, it doesn't even have to be written down, it doesn't have to (and probably shouldn't) remain static over the project, but it should force you to sit down and understand why this project is different from all the others.

Because if you're not consciously planning, you'll just end up doing the same thinking, and having the same conversations throughout the project and it will take up even more of your time, and you'll do it worse than if you'd thought about it up front.

P.S. I know I've ignored change management, and traceability - but this is a blog not a textbook.

2 comments:

  1. In my opinion you identified and then did not expand on something a lot more fundamental than tracing or change management: Stakeholders.

    After each of your four statements elements, I found myself asking, "...for whom?" Clarity of stakeholders is (in my experience) the most significant factor in successful business analysis planning. Clear plans to identify and engage stakeholders in the project and the solution will help you build the relationships you need to successfully develop and approve your requirements.

    ReplyDelete
  2. Julian,

    Excellent point. I was getting myopic about deliverables because that was the conversation we were having with the client at the time.

    Regards,
    Harris.

    ReplyDelete