Comments on: It’s Not A Change Request, It’s A Missed Requirement http://www.pmhut.com/its-not-a-change-request-its-a-missed-requirement Wed, 23 May 2012 11:05:53 +0000 http://wordpress.org/?v=abc hourly 1 By: Kerry Wills http://www.pmhut.com/its-not-a-change-request-its-a-missed-requirement/comment-page-1#comment-21313 Kerry Wills Tue, 25 May 2010 20:22:10 +0000 http://www.pmhut.com/?p=5418#comment-21313 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. 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.

]]> By: Shim Marom http://www.pmhut.com/its-not-a-change-request-its-a-missed-requirement/comment-page-1#comment-21297 Shim Marom Tue, 25 May 2010 01:38:41 +0000 http://www.pmhut.com/?p=5418#comment-21297 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). 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).

]]>