Posted by: kerrywills | May 21, 2010

It’s not a change it’s a missed requirement


My least favorite conversation to have on a project (well, second to the “we’re not going to meet our date” conversation) is the scope conversation. This is the arm-wrestling match over scope elements which business describes as “must haves that should have been part of requirements” and the IT team describes as “not included in the requirements (or estimates).” The conversation usually goes back and forth and results in lots of blaming (see my post on blame)…you didn’t tell me…well I thought I did….we didn’t include it in the plan…but that’s what I meant….and on and on.

it IS is scope.....it IS NOT in scope...it IS...IS NOT....

The way I have historically tackled these types of things is to focus on the facts and take the conversation away from blame. I tell the business partners that regardless of what should have been in vs what really got documented, the net result is that the item in discussion is not included in the estimates. I then proceed to tell them what including that item in the plan would mean for cost and schedule . This way, the business can have an informed decision as to accepting the scope with the associated impacts to the project.

This is why it is so important to have a clear view into scope, get requirements signed off, and provide detailed requirements as to what is in (and out) of scope. It is equally important to clearly link project estimates to scope elements and the associated assumptions. Diligence up front saves time in these difficult discussions later. Another technique I like to use is to put aside effort/dollars for discretionary scope items – for example the business can have 1000 hours of  items not included in the estimates. There will always be scope discussions but being rigorous in requirements management and documenting estimates allows the conversation to focus on the facts.

Advertisements

Responses

  1. The idea of having a contingency (~1000hrs) not included in estimates by business is an excellent idea and something that helps the management wade through unknowns during the course of the project life..


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: