It’s Not A Change Request, It’s A Missed Requirement
By Kerry Wills
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 article 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.
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.
Kerry Wills is a proven Program Manager/Portfolio Manager with an extensive background in Project Management, consulting, and application development. Kerry has consistently demonstrated the ability to plan and implement large and complex projects on time and on/under budget. Kerry runs a blog, Adventures in Project Management.
Hi Kerry, when looking at the title of your post I assumed your point will be about the fact that any scope change is a result of missed requirement. That, obviously, is NOT the case.
The point mentioned in the body of your post is somewhat different and related to the fact that more rigour applied at requirements gathering stage (while scope is being determined) can reduce arguments at a later stage. That is correct.
One point worth mentioning though is that no matter how much effort we put into documenting and verifying our requirements they will never ever be 100% solid to the point where subsequent disagreements get completely eliminated. This is not because we lack in processes or methods of collecting, organizing and signing off of these requirements; it is simply because no human process is bullet proof (at leat not without expending vasts amounts of energy and money).
Shim – great comments. The title was meant to simulate a discussion with the business. In my original blog post I have a picture of an arm wrestling match where business says “missed requirement” and IT says “change control”
Agreed that all requirements will never be considered up front which is the reason that diligence is so important – around documenting assumptions in initial estimates and having contingency for unknowns.