Craig Brown writes a blog at BetterProjects.net. Craig and I are regular readers of each other’s sites and now we are having a conversation from site to site.
Hi Craig,
Thanks for your opinion on why you think my requirements keep on changing. I agree with you on all accounts. You left me with three reasons for the changing requirements and asked me in return:
“What do you think are the key drivers of these three ‘controllable’ issues?”
Photography by t3rmin4t0r.
Many books have been writing about the subject. I am going to take a shot at them in a single blog post. So, this is a “shooting from the hip” and a “tongue and cheek” version of my answer. I will answer each reason separately, and will start with listing the argument you provided.
ONE
“Clients jump into their solution work before they properly understand their problem.”
The most common reason to start a project is that people want to get rid of a problem. People hate uncertainty. By putting instantly a cause to their problem, with associated solution, they have eliminated a big question mark in their mind. Sadly, business situations are getting more and more complex and cause-effect chains can become almost invisible.
Another reason is what I call the “busy beaver syndrome“. People that take immediate action are considered “good managers”. You see a fire, and you take out the old hose instantly. It’s business ethics from the 80s (last century!) but still in fashion all over the globe. If you want to gain respect and get ahead in an environment thriving on “busy beavers” you find yourself building dams in no time. However, sometimes you may find that building dams is not always the best solution.
The answer lies in educating managers in assessing problems in complex and global situations. Showing them how quick fixes can backfire and make matters worse. Learning clients to inhale-exhale before shooting from the hip.
TWO
“In multi-stakeholder environments (i.e. large organizations) there is rarely one clear voice singing the requirements tune.”
I must admit that this is normally the point where I start comparing management layers with Baboon Hill, where the one with the red ass wins. Perhaps I have seen too many situations in which disagreement was used simply to disagree. This is office politics in its purest form. This is about power and status. By emphasizing the difference with others, people try to place themselves above others in some kind of invisible office game ranking system.
There is of course also the possibility that they really see the situation differently. It is like the story of the blind men and the elephant. They all touch the same animal, but “see” things differently: one the trunk, another the tail and someone a leg. The solution to this problem is equal to item ONE.
Putting a stop to the negative effects of the pursuit of power is a whole different ballgame and consists of a wide range of social skills.
THREE
“The people you put into project management and requirements management roles don’t have the right skills and knowledge.”
Project Management and Requirements Management are real professions. I am amazed why people still think it is some kind of neat trick that you can master with a “full day of training”. It is no rocket science, but it’s still a real job. I think it’s a problem with the role of “management” in general. It’s being regarded as “chatting with other managers”, “telling the little people what to do”, and “making some vague decisions”. So with the generic image being “everyone can be a manager” it’s not hard to see why these roles are quickly filled.
Project Management and Requirement Management have a “branding” problem. It should be promoted as real and proper skills.
To summarize, I see as key drivers
- lack of knowledge about true cause-effect-chains, and
- mimicking the behavior of a certain group of people to be associated with that group.
Is this something you recognize? You live down under, so people should be more relaxed.. 
Cheers
Bas
Bas and Craig have a weekly conversation, back and forth on their respective blogs, Project Shrink and Better Projects. With blog titles like that, you don’t have to guess what the topic will be. Feel free to join in.
I agree with your three main reasons and I find that it is more important to focus on the process of change and handling this process than to try to avoid change (although it is also important to define the best possible requirements up front). To manage the change process effectively we need a great tool for managing requirements including input from users and others and the abilty to trace every change and every decision back to its origin. one such tool is available at http://www.requirementone.com for free as a web-based fully hosted solution.
This is a fantastic and illuminating reading.
In addition to what Bas stated, I would like to add the following remarks:
“In multi-stakeholder environments (i.e. large organizations) there is rarely one clear voice singing the requirements tune.” This is consistent with the brain-opener book entitled ” The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations, first published in 2004, by James Surowiecki. As we rely sometime on intuition, the sense of the crowd becomes important.
“The people you put into project management and requirements management roles don’t have the right skills and knowledge.” This is very wisely stated. People lack practical application of how to manage complexity. How to tune the findings of complexity into the diary of managers is still problematic. Most managers get scared of complexity and stick to their comfort zone. Avoidance will not solve any problem; yet many people continue doing that.
Thanks for bringing the topic up.
The challenge of changing requirements does not exist for a project that lasts half a day… For projects that will last 10 years (like a Spaceshuttle program)….
1. One reason why requirements change is, that the environment (the world around us) continuously changes. So, why, do we expect that requirements can be frozen?
2. I also believe that in the requirements phase analysts should put themselves in a position to conclude that the set of requirements given to them, may not be mature. In other words, based on the set of requirements analysts should say to their managers: do not start the project. For instance, because we miss requirements about “exstensions”, etc.
3. An attempt to provide assistance in the requirements phase is “Requirements Assistant”, see Website: http://www.requirementsassistant.nl
Herman,
I particularly liked your second point.
Not all analysts are comfortable with the greyness of immature requirements. How do you deal with that?
PS – nice photo Mr de Baar!
Craig: are you referring to your own gravatar picture with the beer
or the cliche photo of a kangaroo on an posting that is aimed at an Australian ? 
Like them both though.
Thanks for the cofusion_ is the man with the beer Bas? In this case I see a great example of metamorphism or transformation.
HAHAHAHA. I don’t drink beer hehehehe
Well, I may get drunk without drinking!!!!!!!
[...] Anil, S.Srinivasan [...] The Secret To Coping With Change: MIND + NETWORK 2 Ali Anani, Helen Dear Craig – Why Requirements Change 9 Ali Anani, Bas, Ali Anani, Bas, Craig, Craig [...] Go To The Spike And Become Adaptive 5 Ali [...]