I this article, we examine the fundamental truths about project and requirements changes: What can we control? What is beyond our control? What are some of the common perils and pitfalls of change-control and iterative development? We discuss how to avoid many of these common pitfalls without creating new ones along the way, and provide a wealth of resources for first-timers to iterative development.
Pitfalls of Controlling Change
I often come across teams in the early stages of learning to deal with changing requirements. They typically run into two pitfalls in the following order:
Pitfall #1: No scope change-management
The very first pitfall they fall into is not having any kind of change-management for the project/requirements. They allow any and all changes in a very reactive fashion without thinking about trying to renegotiate the scope, schedule, or resources for the project/release.
Pitfall #2: Preventing scope changes
The very next time around, they run into the second pitfall: they overcompensate for being burned/bitten by the first pitfall by trying to prevent any and all changes to the scope of their next product release.
They keep insisting that the fundamental problem is they don't have completely stable detailed requirements. If the requirements were detailed enough up-front, they think their estimates would be more accurate; and if only the requirements would stop changing before a single line of code is written, then the schedule wouldn't keep fluctuating so much. It's those darn users/customers/analysts that don't know what exactly they want at the outset. It's all their fault!
This leads to another pitfall:
Pitfall #3: Requirements Analysis Paralysis
They spend inordinately more and more effort analyzing and engineering requirements and specifying them in far too much detail before attempting to validate their results with tangible feedback.
The irony is that the more they try to get stable detailed requirements up-front, the more the schedule becomes protracted: first to get all the gory-details analyzed and specified up-front; and second because so many of the gory-details were either incorrect or still not detailed enough. It becomes this vicious cycle of trying to prevent change with more up-front detail, and yet things keep getting worse instead of better. If the cycle goes unrecognized and unchecked, it can turn into a "holy grail" crusade in search of the perfect and unchanging requirements.
Biology, Stability, Humanity, Uncertainty, and Inevitability
When I encounter a group in the midst of these pitfalls, the first thing I commonly do here is explain the following:
There is a very fancy technical term that biologists use to describe completely stable systems. This highly sophisticated technical term is the word "DEAD!"
I then try to explain that we meager humans (including ourselves and our customers) are imperfect, and we have imperfect and incomplete knowledge: We don't know things, and we don't know that we don't know things, and we don't know how to find out many of those things earlier.
Then I wax philosophically and authoritatively explain the unalterable truth about the fundamental nature of software development and changing requirements. I call it my "tried and true, battle-proven and industry-acknowledged, unchangeable rules of software change ...
The Unchangeable Rules of Software Change
Rule #0: Change is Inevitable!
The Requirements/Plans ARE going to change!
Rule #1: Resistance is Futile!
There isn't a darn thing you can do to prevent Rule #0.
Rule #2: Change is like Quicksand -- Fighting it only makes it worse!
The more you try to deny and defy rule #1 by attempting to prevent rule #0, the worse things will get.
Rule #3: Change is like Quicksilver -- Tightening your grip