23 May 2008

Dear Bas - Conversations with the Project Shrink

Bas de Baar is an Author of two books on Project Management. He also writes a blog at www.softwareprojects.org. Bas and I are regular readers of each other’s sites and now we are having a conversation from site to site. Feel free to join in.

Hi Bas,

So to your first question "Why do my requirements keep changing?" The first point I want to make is that I haven't seen any studies that look at why requirements go bad, but there are plenty around that indicate they are a leading source of project problems. So the discussion will only be built around my personal experiences and observations of projects going on around me.

My view on this question is that there are four basic answers.
  1. Clients jump into their solution work before they properly understand their problem
  2. In multi-stakeholder environments (i.e. large organizations) there is rarely one clear voice singing the requirements tune,
  3. The people you put into project management and requirements management roles don't have the right skills and knowledge
  4. The external market conditions are changing fast and it's just hard to get the product lined up with the market

You'll see some of these issues link back to the issues that the old Chaos reports used to call out about project management but are now just more specific to the requirements management work stream. The only one that seems to me to be legitimately out of the client company's control is the last one. A variation on this is in political organizations and government departments where often PR and politics can overwhelm sensible analysis and planning.

So, Bas, you are the Project Management Sociologist. What do you think are the key drivers of these three 'controllable' issues?

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.


  1. Hello Craig,

    Thank you so much for selecting "juicy presentations" to comment on and bring them to the attention of your readers.

    I want to draw your attention to a presentation I published recently using a standardized approach to study teams cycle time, Blue Ocean Strategy and Balanced Scorecard.
    Bas De Baar made several comments on this presentation.

    The link is

  2. I can offer a clear cause for "bad" requirements. It is not the requirements you captured, it is the ones you missed that can kill a project.

    For example: business says we do these things all the time...well, sometimes we do something else, but that hardly ever happens, so don't worry about it...

    That "something else" will happen, trust me, right after implementation... and the proverbial brown stuff will hit the fan.

  3. Dave - Would that fit under the "People don't have the right skills" heading?

  4. Yes, plus the organization does not have an effective process for people to follow.