Dilbert
At the risk of sound like a poser posting the one millionth reference to a Dilbert cartoon, here goes...
Scott Adams often hits home with his wit and wisdom.
Requirements...requirements...requirements.
Its almost trite to say -- but we all know requirements can make or break a project.
Today, I offer two opposing viewpoints on requirements gathering and ask others in the blogosphere to chime in with comments--and prove that I am not alone in this interest.
Theory #1:
Customers are NOT capable of providing good requirements.
Sub-theory A:
IT requirements frameworks are too abstract and prevent the customer from giving the information we need in the format we need it.
Sub-theory B:
People that have learned the sacred skill of providing good requirements are not permitted to advance to positions where they would become agents for change and provide them directly.
Sub-theory C:
Good subject matter experts and business analysts are assigned to projects where they do not have experience. Thus, additional time and semantic churn is needed.
Theory #2:
Customers DO provide us with all the information we need.
Sub-theory D:
Developers and architects are poor listeners.
Sub-theory E:
Customers provide dialogue and desires. Developers and architects need to convert that to facts and prioritized assumptions.
Sub-theory F:
Architects should write the requirements for projects to ensure she/he understands them and presents the vision in a manner that optimizes developer understanding.
But what really matters is what YOU think.
Scott Adams often hits home with his wit and wisdom.
Requirements...requirements...requirements.
Its almost trite to say -- but we all know requirements can make or break a project.
Today, I offer two opposing viewpoints on requirements gathering and ask others in the blogosphere to chime in with comments--and prove that I am not alone in this interest.
Theory #1:
Customers are NOT capable of providing good requirements.
Sub-theory A:
IT requirements frameworks are too abstract and prevent the customer from giving the information we need in the format we need it.
Sub-theory B:
People that have learned the sacred skill of providing good requirements are not permitted to advance to positions where they would become agents for change and provide them directly.
Sub-theory C:
Good subject matter experts and business analysts are assigned to projects where they do not have experience. Thus, additional time and semantic churn is needed.
Theory #2:
Customers DO provide us with all the information we need.
Sub-theory D:
Developers and architects are poor listeners.
Sub-theory E:
Customers provide dialogue and desires. Developers and architects need to convert that to facts and prioritized assumptions.
Sub-theory F:
Architects should write the requirements for projects to ensure she/he understands them and presents the vision in a manner that optimizes developer understanding.
But what really matters is what YOU think.
posted by JT at 9:10 PM
2 Comments:
I always teach architects-in-training that the model of 'gathering requirements' like farmers reaping a harvest after planting seeds some months before is flawed. Further, I pose the question to all of my PM classes: how many of you in IT have ever had 100% of the system requirements nailed down up front, and that's what you exactly delivered to the business at the end of the project? The answer, of course, is none.
In the end, it's really a negotiation with the business..and a continued one as projects proceed. Management appears to like the term "continuous negotiation" with respect to requirements changing rather than the dreaded moniker "scope creep," which appears to connote 'evil lurking about' in most cases...:)
Continuous negotiation ..not a bad approach. Guess that assumes the PM can sell that ;-)
Post a Comment
<< Home