Welcome to EMC Consulting Blogs Sign in | Join | Help

BI Tester

Testing all things BI

The Requirements Track

Requirements costs money - it describes what the client needs, and determines how much they are willing to spend, we as the Project team need to work out how we fulfil this need - if we get it wrong - we fall into the trap of a vicious cycle of delivery where we deliver with both client and team feeling it’s a lose-lose situation and no repeat business.

Several easy steps to take are

  1. To make a requirements list (or user stories).
  2. Agree with the client what the priorities are (MoScoW approach will help).
  3. Ensure your team trace requirement from inception to delivery tracing all requirements through the system.
  4.  Present to the client your deliverable with full understanding of what requirements were delivered.

This is a nice and easy flow very idealistic not likely to be as straight forward in reality.

The realistic part of writing a Requirements list is this - it helps to manage change - change is inevitable and the client has to be coached about the (changes) and the impact of change and how we (client and team) manage this within certain boundaries

Boundaries

Project process

Allow the client to add, update or descope requirements within certain boundaries, one of them being disruption of the project process. These boundaries coach the client not upset team productivity, and it gives the team a steady stream to row over, till the next change.

Business process

New requirements should be analysed from its own business impact and check what the ROI before hotfooting it to the team, knowing what the cost benefit, helps you see whether this upheaval is worth it, to your business and giving that information to your team helps them see how important and more importantly create test cases for your ROI so see if its testable, and able to show the true value when delivered.

Note that requirements are everyone’s responsibility (client and team)

Do an informal gap & impact of change for each change the client requires

No impact - can be done during current process no impact on project (no impact on timescales)

Minimal impact - can be done during current process but with some impact on project    (time scales affected)

Major impact - can’t be done during current process major impact on project delivery and timescales   - change request

Critical impact - affects the whole delivery - an abrupt stop (as in scrum) or terminate

In each scenario coaching or carrying your client along is important - an honest update about the costs to them and to the team.

 

 

Published 31 October 2008 11:19 by jennifer.orji
Anonymous comments are disabled

This Blog

Syndication

News

Locations of visitors to this page
Powered by Community Server (Personal Edition), by Telligent Systems