“Scope Seep” or what happens if you give a mouse a cookie

if_you_give_mouse_a_cookieMost of us by now know about the consequences of “Scope Creep”

But there is a much more dangerous problem that we Project Managers get ourselves into. It is called “Scope Seep

“Scope Seep” is a term coined by Alan Weiss and refers to situations when you, the project manager, not the customer, allow extra features, tasks, or deliverables to be added to the scope of the project without the customer asking for them.

We all know the consequences of “Scope Seep”, but why do we do it?

Alan explains that the reason we cause scope seep is because we don’t feel we are sufficiently valuable:

We do this because we don’t feel as if we’re delivering enough value or possess sufficient expertise. It is a self-esteem crisis, one of the many which consultants hazard through on tip-toe while holding their breath

To show me the consequences of “Scope Seep”, one of my mentors once gave me a children’s book to read called “If You Give a Mouse A Cookie“. It tells the story of the problem you run into if you happen to give an overly active and demanding mouse a cookie.

In the story, a little boy’s one act of generosity caused him a lot of trouble. “If you give a mouse a cookie, he’s going to ask for a glass of milk. When you give him milk, he’ll probably ask you for a straw. When you give him a straw, he will ask………” And it goes on and on and on until the poor kid is completely exhausted trying to fulfill the never ending requests of the demanding and pushy little mouse.

Derek Huether over at the The Critical Path wrote recently about “How To Prevent Your Project From Hemorrhaging

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I’m not saying changes should not be made.  I’m saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end…customer satisfaction.

Derek is 100% spot on.

Look at it this way:

When you are late on your deadline and/or above budget, nobody remembers the extra stuff you added, because of your good nature, to the scope of the project.

The customer (internal or external) actually forgets often about all those nice things you added to the scope and only remembers that you are late and over budget.

9 times out of 10, if you are an external vendor, the customer will expect you to eat any additional cost.

If You Give a Mouse A Cookie“ should be a required reading for all new project managers as education about the consequences of “Scope Seep”.

Your comments are always encouraged and welcomed.

9 Responses to “Scope Seep” or what happens if you give a mouse a cookie
  1. Matthew
    February 24, 2010 | 5:58 am

    I think there is a problem with talking about the software development life-cycle (SDLC) with respect to scope management.

    This is because the software development life-cycle doesn’t actually manage scope – it only managers the elaboration of requirements, into designs, into code, into tested code, into implemented systems.

    It’s when the SDLC doesn’t work perfectly – which is to say, always – that there are problems.

    So the problem in software development projects is often less about scope creep, or scope seep, it’s about the IT vendor trying to shift the baseline as the project progresses.

    The IT vendor, wants the customer to sign off that the design will met their requirements. The customer wants the system to work like it does in their often undocumented, frequently changing vision of how it should work.

    There aren’t many solutions to this other than commitment to benefits and sharing of risks (and a very detailed understanding of how these relating, that I wont go into here).

    With this in mind I’d agree that ALL change needs to be managed. However, some changes are internal and don’t impact the scope, and other changes are external and do impact the scope.

    • samad_aidane
      February 24, 2010 | 2:57 pm

      Matthew,

      you summed up that paradox so well when you said “The IT vendor, wants the customer to sign off that the design will met their requirements. The customer wants the system to work like it does in their often undocumented, frequently changing vision of how it should work.” I can’t agree with you more on this one. I agree with you also when you said that there aren’t many solutions to this paradox other than commitment to benefits and sharing of risks. I this that lack of sharing of risks that makes us all defensive about scope creep and scope seep. In the absence of shared commitment to benefits as well as risks, each party in an agreement is protective of their interest. It is unfortunately the reality of vendor/client relationships. Thank you so much for taking the time to comment. I look forward to continuing the conversation here and on you blog, http://www.managewithoutthem.com, which I am enjoying a lot.

  2. Derek Huether
    February 24, 2010 | 10:16 am

    Samad, comparing a customer to that mouse in the book is spot on! Now that I think of it, customers are not unlike my 4-year-old, to whom I read that book. They all ask and ask and ask with the hopes you will give in. Don’t blame them for asking. Just learn how to deliver a positive no. If we satisfy their wants in the short term, we often fail to meet their needs in the long term.

    Best Regards,
    Derek
    http://thecriticalpath.info
    http://twitter.com/derekhuether

    • samad_aidane
      February 24, 2010 | 2:50 pm

      Derek, I had to laugh because I have a 7 year old and that’s been my experience. Thank you for taking the time to read and comment. After all, it was you post that inspired this one. So I have to thank you for that as well.

  3. Carol Dekkers
    April 6, 2010 | 4:07 pm

    Samad,

    I enjoy your posts – they compliment some of my own blog postings.

    Nice to see that there are like-minded people involved in software development.

    Keep blogging!
    Carol Dekkers
    http://musingsaboutsoftwaredevelopment.wordpress.con

    • samad_aidane
      April 6, 2010 | 4:35 pm

      Carol,

      Thank you so much for taking the time to read and comment. I look forward to reading your blog and connecting with you in future conversations.

  4. […] The Guerilla Project Manager post on “Scope Seep” – which offers a different perspective on the traditional idea of scope […]

  5. […] may not be scope creep that is troubling your project, but scope seep.  “Scope Seep” or what happens if you give a mouse a cookie is what happens when the project manager allows for […]

  6. If you give a mouse a scope cookie…
    September 24, 2014 | 10:12 am

    […] not be scope creep that is troubling your project, but scope seep. It may be self-inflicted.   “Scope Seep” is what happens when the project team introduces additional scope of work not asked by the […]

“Scope Seep” or what happens if you give a mouse a cookie

if_you_give_mouse_a_cookieMost of us by now know about the consequences of “Scope Creep”

But there is a much more dangerous problem that we Project Managers get ourselves into. It is called “Scope Seep

“Scope Seep” is a term coined by Alan Weiss and refers to situations when you, the project manager, not the customer, allow extra features, tasks, or deliverables to be added to the scope of the project without the customer asking for them.

We all know the consequences of “Scope Seep”, but why do we do it?

Alan explains that the reason we cause scope seep is because we don’t feel we are sufficiently valuable:

We do this because we don’t feel as if we’re delivering enough value or possess sufficient expertise. It is a self-esteem crisis, one of the many which consultants hazard through on tip-toe while holding their breath

To show me the consequences of “Scope Seep”, one of my mentors once gave me a children’s book to read called “If You Give a Mouse A Cookie“. It tells the story of the problem you run into if you happen to give an overly active and demanding mouse a cookie.

In the story, a little boy’s one act of generosity caused him a lot of trouble. “If you give a mouse a cookie, he’s going to ask for a glass of milk. When you give him milk, he’ll probably ask you for a straw. When you give him a straw, he will ask………” And it goes on and on and on until the poor kid is completely exhausted trying to fulfill the never ending requests of the demanding and pushy little mouse.

Derek Huether over at the The Critical Path wrote recently about “How To Prevent Your Project From Hemorrhaging

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I’m not saying changes should not be made.  I’m saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end…customer satisfaction.

Derek is 100% spot on.

Look at it this way:

When you are late on your deadline and/or above budget, nobody remembers the extra stuff you added, because of your good nature, to the scope of the project.

The customer (internal or external) actually forgets often about all those nice things you added to the scope and only remembers that you are late and over budget.

9 times out of 10, if you are an external vendor, the customer will expect you to eat any additional cost.

If You Give a Mouse A Cookie“ should be a required reading for all new project managers as education about the consequences of “Scope Seep”.

Your comments are always encouraged and welcomed.

9 Responses to “Scope Seep” or what happens if you give a mouse a cookie
  1. Matthew
    February 24, 2010 | 5:58 am

    I think there is a problem with talking about the software development life-cycle (SDLC) with respect to scope management.

    This is because the software development life-cycle doesn’t actually manage scope – it only managers the elaboration of requirements, into designs, into code, into tested code, into implemented systems.

    It’s when the SDLC doesn’t work perfectly – which is to say, always – that there are problems.

    So the problem in software development projects is often less about scope creep, or scope seep, it’s about the IT vendor trying to shift the baseline as the project progresses.

    The IT vendor, wants the customer to sign off that the design will met their requirements. The customer wants the system to work like it does in their often undocumented, frequently changing vision of how it should work.

    There aren’t many solutions to this other than commitment to benefits and sharing of risks (and a very detailed understanding of how these relating, that I wont go into here).

    With this in mind I’d agree that ALL change needs to be managed. However, some changes are internal and don’t impact the scope, and other changes are external and do impact the scope.

    • samad_aidane
      February 24, 2010 | 2:57 pm

      Matthew,

      you summed up that paradox so well when you said “The IT vendor, wants the customer to sign off that the design will met their requirements. The customer wants the system to work like it does in their often undocumented, frequently changing vision of how it should work.” I can’t agree with you more on this one. I agree with you also when you said that there aren’t many solutions to this paradox other than commitment to benefits and sharing of risks. I this that lack of sharing of risks that makes us all defensive about scope creep and scope seep. In the absence of shared commitment to benefits as well as risks, each party in an agreement is protective of their interest. It is unfortunately the reality of vendor/client relationships. Thank you so much for taking the time to comment. I look forward to continuing the conversation here and on you blog, http://www.managewithoutthem.com, which I am enjoying a lot.

  2. Derek Huether
    February 24, 2010 | 10:16 am

    Samad, comparing a customer to that mouse in the book is spot on! Now that I think of it, customers are not unlike my 4-year-old, to whom I read that book. They all ask and ask and ask with the hopes you will give in. Don’t blame them for asking. Just learn how to deliver a positive no. If we satisfy their wants in the short term, we often fail to meet their needs in the long term.

    Best Regards,
    Derek
    http://thecriticalpath.info
    http://twitter.com/derekhuether

    • samad_aidane
      February 24, 2010 | 2:50 pm

      Derek, I had to laugh because I have a 7 year old and that’s been my experience. Thank you for taking the time to read and comment. After all, it was you post that inspired this one. So I have to thank you for that as well.

  3. Carol Dekkers
    April 6, 2010 | 4:07 pm

    Samad,

    I enjoy your posts – they compliment some of my own blog postings.

    Nice to see that there are like-minded people involved in software development.

    Keep blogging!
    Carol Dekkers
    http://musingsaboutsoftwaredevelopment.wordpress.con

    • samad_aidane
      April 6, 2010 | 4:35 pm

      Carol,

      Thank you so much for taking the time to read and comment. I look forward to reading your blog and connecting with you in future conversations.

  4. […] The Guerilla Project Manager post on “Scope Seep” – which offers a different perspective on the traditional idea of scope […]

  5. […] may not be scope creep that is troubling your project, but scope seep.  “Scope Seep” or what happens if you give a mouse a cookie is what happens when the project manager allows for […]

  6. If you give a mouse a scope cookie…
    September 24, 2014 | 10:12 am

    […] not be scope creep that is troubling your project, but scope seep. It may be self-inflicted.   “Scope Seep” is what happens when the project team introduces additional scope of work not asked by the […]

“Scope Seep” or what happens if you give a mouse a cookie

if_you_give_mouse_a_cookieMost of us by now know about the consequences of “Scope Creep”

But there is a much more dangerous problem that we Project Managers get ourselves into. It is called “Scope Seep

“Scope Seep” is a term coined by Alan Weiss and refers to situations when you, the project manager, not the customer, allow extra features, tasks, or deliverables to be added to the scope of the project without the customer asking for them.

We all know the consequences of “Scope Seep”, but why do we do it?

Alan explains that the reason we cause scope seep is because we don’t feel we are sufficiently valuable:

We do this because we don’t feel as if we’re delivering enough value or possess sufficient expertise. It is a self-esteem crisis, one of the many which consultants hazard through on tip-toe while holding their breath

To show me the consequences of “Scope Seep”, one of my mentors once gave me a children’s book to read called “If You Give a Mouse A Cookie“. It tells the story of the problem you run into if you happen to give an overly active and demanding mouse a cookie.

In the story, a little boy’s one act of generosity caused him a lot of trouble. “If you give a mouse a cookie, he’s going to ask for a glass of milk. When you give him milk, he’ll probably ask you for a straw. When you give him a straw, he will ask………” And it goes on and on and on until the poor kid is completely exhausted trying to fulfill the never ending requests of the demanding and pushy little mouse.

Derek Huether over at the The Critical Path wrote recently about “How To Prevent Your Project From Hemorrhaging

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I’m not saying changes should not be made.  I’m saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end…customer satisfaction.

Derek is 100% spot on.

Look at it this way:

When you are late on your deadline and/or above budget, nobody remembers the extra stuff you added, because of your good nature, to the scope of the project.

The customer (internal or external) actually forgets often about all those nice things you added to the scope and only remembers that you are late and over budget.

9 times out of 10, if you are an external vendor, the customer will expect you to eat any additional cost.

If You Give a Mouse A Cookie“ should be a required reading for all new project managers as education about the consequences of “Scope Seep”.

Your comments are always encouraged and welcomed.

9 Responses to “Scope Seep” or what happens if you give a mouse a cookie
  1. Matthew
    February 24, 2010 | 5:58 am

    I think there is a problem with talking about the software development life-cycle (SDLC) with respect to scope management.

    This is because the software development life-cycle doesn’t actually manage scope – it only managers the elaboration of requirements, into designs, into code, into tested code, into implemented systems.

    It’s when the SDLC doesn’t work perfectly – which is to say, always – that there are problems.

    So the problem in software development projects is often less about scope creep, or scope seep, it’s about the IT vendor trying to shift the baseline as the project progresses.

    The IT vendor, wants the customer to sign off that the design will met their requirements. The customer wants the system to work like it does in their often undocumented, frequently changing vision of how it should work.

    There aren’t many solutions to this other than commitment to benefits and sharing of risks (and a very detailed understanding of how these relating, that I wont go into here).

    With this in mind I’d agree that ALL change needs to be managed. However, some changes are internal and don’t impact the scope, and other changes are external and do impact the scope.

    • samad_aidane
      February 24, 2010 | 2:57 pm

      Matthew,

      you summed up that paradox so well when you said “The IT vendor, wants the customer to sign off that the design will met their requirements. The customer wants the system to work like it does in their often undocumented, frequently changing vision of how it should work.” I can’t agree with you more on this one. I agree with you also when you said that there aren’t many solutions to this paradox other than commitment to benefits and sharing of risks. I this that lack of sharing of risks that makes us all defensive about scope creep and scope seep. In the absence of shared commitment to benefits as well as risks, each party in an agreement is protective of their interest. It is unfortunately the reality of vendor/client relationships. Thank you so much for taking the time to comment. I look forward to continuing the conversation here and on you blog, http://www.managewithoutthem.com, which I am enjoying a lot.

  2. Derek Huether
    February 24, 2010 | 10:16 am

    Samad, comparing a customer to that mouse in the book is spot on! Now that I think of it, customers are not unlike my 4-year-old, to whom I read that book. They all ask and ask and ask with the hopes you will give in. Don’t blame them for asking. Just learn how to deliver a positive no. If we satisfy their wants in the short term, we often fail to meet their needs in the long term.

    Best Regards,
    Derek
    http://thecriticalpath.info
    http://twitter.com/derekhuether

    • samad_aidane
      February 24, 2010 | 2:50 pm

      Derek, I had to laugh because I have a 7 year old and that’s been my experience. Thank you for taking the time to read and comment. After all, it was you post that inspired this one. So I have to thank you for that as well.

  3. Carol Dekkers
    April 6, 2010 | 4:07 pm

    Samad,

    I enjoy your posts – they compliment some of my own blog postings.

    Nice to see that there are like-minded people involved in software development.

    Keep blogging!
    Carol Dekkers
    http://musingsaboutsoftwaredevelopment.wordpress.con

    • samad_aidane
      April 6, 2010 | 4:35 pm

      Carol,

      Thank you so much for taking the time to read and comment. I look forward to reading your blog and connecting with you in future conversations.

  4. […] The Guerilla Project Manager post on “Scope Seep” – which offers a different perspective on the traditional idea of scope […]

  5. […] may not be scope creep that is troubling your project, but scope seep.  “Scope Seep” or what happens if you give a mouse a cookie is what happens when the project manager allows for […]

  6. If you give a mouse a scope cookie…
    September 24, 2014 | 10:12 am

    […] not be scope creep that is troubling your project, but scope seep. It may be self-inflicted.   “Scope Seep” is what happens when the project team introduces additional scope of work not asked by the […]