Scope Creep
-
Its almost two years since my last post about Scope Creep, It came to me that I do a follow up on the subject. Right! Back then I was more of a Gadget/Tool (Did everything with No questions asked) that wrote code based on a certain specification given to me by either my manager or by the BA (which in most cases it was given by the Manager). yeah! cool, a very nice spec with everything required and ill write the software the way I understood the specification, great! I'm doing what I'm told to do. Now the problem starts when that piece of software gets reviewed but the person who actually requested it, Now here they see how powerful it is and they see more uses and more features to be added to it, or in some cases they see it differently, like its just a complete disaster, which for an actual fact its their fault they didn't really know what the want lol (a part of me had to laugh at that) . So now that they realised what they really want they start changing the flow of the application or changing the design, which is not a problem the developer can do it, but what they usually forget to do is changing the estimated completion time. Where does that leave the person accountable for this? let me tell you, under-pressure, well if you are lucky to find dedicated and hard working developers this is not a problem they do the work, with no questions asked. But the situation also differs when the application is supper cool and they see a potential "New" feature and they don't really want to put a separate request for that feature because that will take time because it still needs to go through the proper channels, being Documented, scheduled, Authorized, Prioritized and all other planning levels and that will cost the client even more. So they try to squeeze it into the current requirement (Jackpot!!). In both cases if you have a product owner or a project Manager that doesn't have "NO" or "Stop" in their vocab that then becomes another problem (Why are they there at the first place? UHMM? that's another day's story). The spec grows even bigger. Ok ok.. I think its safe to say you get the picture. We've been looking at this with developer's eyes, Now lets try and shift the focus, lets say you are now the client, lets say you don't really know what you want, you have the idea but you are pretty sure of what you don't want. Will you pay for something if it doesn't satisfy needs? No! I don't think so. http://izzysharp.blogspot.com/[
-
Its almost two years since my last post about Scope Creep, It came to me that I do a follow up on the subject. Right! Back then I was more of a Gadget/Tool (Did everything with No questions asked) that wrote code based on a certain specification given to me by either my manager or by the BA (which in most cases it was given by the Manager). yeah! cool, a very nice spec with everything required and ill write the software the way I understood the specification, great! I'm doing what I'm told to do. Now the problem starts when that piece of software gets reviewed but the person who actually requested it, Now here they see how powerful it is and they see more uses and more features to be added to it, or in some cases they see it differently, like its just a complete disaster, which for an actual fact its their fault they didn't really know what the want lol (a part of me had to laugh at that) . So now that they realised what they really want they start changing the flow of the application or changing the design, which is not a problem the developer can do it, but what they usually forget to do is changing the estimated completion time. Where does that leave the person accountable for this? let me tell you, under-pressure, well if you are lucky to find dedicated and hard working developers this is not a problem they do the work, with no questions asked. But the situation also differs when the application is supper cool and they see a potential "New" feature and they don't really want to put a separate request for that feature because that will take time because it still needs to go through the proper channels, being Documented, scheduled, Authorized, Prioritized and all other planning levels and that will cost the client even more. So they try to squeeze it into the current requirement (Jackpot!!). In both cases if you have a product owner or a project Manager that doesn't have "NO" or "Stop" in their vocab that then becomes another problem (Why are they there at the first place? UHMM? that's another day's story). The spec grows even bigger. Ok ok.. I think its safe to say you get the picture. We've been looking at this with developer's eyes, Now lets try and shift the focus, lets say you are now the client, lets say you don't really know what you want, you have the idea but you are pretty sure of what you don't want. Will you pay for something if it doesn't satisfy needs? No! I don't think so. http://izzysharp.blogspot.com/[
-
Don't we all have our personal Mr. Scope Creep who regularily visits us with yet another problem we can solve 'while we are at it' or yet another new brilliant idea?
I'm invincible, I can't be vinced
-
Its almost two years since my last post about Scope Creep, It came to me that I do a follow up on the subject. Right! Back then I was more of a Gadget/Tool (Did everything with No questions asked) that wrote code based on a certain specification given to me by either my manager or by the BA (which in most cases it was given by the Manager). yeah! cool, a very nice spec with everything required and ill write the software the way I understood the specification, great! I'm doing what I'm told to do. Now the problem starts when that piece of software gets reviewed but the person who actually requested it, Now here they see how powerful it is and they see more uses and more features to be added to it, or in some cases they see it differently, like its just a complete disaster, which for an actual fact its their fault they didn't really know what the want lol (a part of me had to laugh at that) . So now that they realised what they really want they start changing the flow of the application or changing the design, which is not a problem the developer can do it, but what they usually forget to do is changing the estimated completion time. Where does that leave the person accountable for this? let me tell you, under-pressure, well if you are lucky to find dedicated and hard working developers this is not a problem they do the work, with no questions asked. But the situation also differs when the application is supper cool and they see a potential "New" feature and they don't really want to put a separate request for that feature because that will take time because it still needs to go through the proper channels, being Documented, scheduled, Authorized, Prioritized and all other planning levels and that will cost the client even more. So they try to squeeze it into the current requirement (Jackpot!!). In both cases if you have a product owner or a project Manager that doesn't have "NO" or "Stop" in their vocab that then becomes another problem (Why are they there at the first place? UHMM? that's another day's story). The spec grows even bigger. Ok ok.. I think its safe to say you get the picture. We've been looking at this with developer's eyes, Now lets try and shift the focus, lets say you are now the client, lets say you don't really know what you want, you have the idea but you are pretty sure of what you don't want. Will you pay for something if it doesn't satisfy needs? No! I don't think so. http://izzysharp.blogspot.com/[
It's not just the responsibility of a program or project manager to prevent scope creep. Everyone on the team is responsible - if a feature is requested, you have to evaluate it and see if it can be done with the resources available in the time available. If it can't, either it or another feature has to be cut. This is known as the project management triangle.
Scope ^ / \\ / \\ / \\ / \\/ \
Time ------- Cost*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
It's not just the responsibility of a program or project manager to prevent scope creep. Everyone on the team is responsible - if a feature is requested, you have to evaluate it and see if it can be done with the resources available in the time available. If it can't, either it or another feature has to be cut. This is known as the project management triangle.
Scope ^ / \\ / \\ / \\ / \\/ \
Time ------- Cost*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
It's not just the responsibility of a program or project manager to prevent scope creep. Everyone on the team is responsible - if a feature is requested, you have to evaluate it and see if it can be done with the resources available in the time available. If it can't, either it or another feature has to be cut. This is known as the project management triangle.
Scope ^ / \\ / \\ / \\ / \\/ \
Time ------- Cost*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility