The Scope Creep and I Mean Me!

I haven’t been doing much programming in the past month and the idea came to me that there was a program I needed to write for myself. I did this because, like the rest of you, I didn’t already have enough to do.  😉  Even my little task wasn’t safe from scope creep.

Most of you have heard the old project manager’s joke that the scope creep is that creep that keeps changing the scope (of the project).

In any case, I felt a bit smug about keeping my programming skills fresh. I got into my Visual Studio, started my C# program, and finished my little program in a short period of time. Since the program was for a specific and extremely limited task, it wasn’t very big.

But then something happened to me and you’ll recognize it – scope creep. Yes, once I got the program doing what it NEEDED to do, I started thinking about what it COULD do. And this is where most of us get into trouble.

The Winding Road to Despair
Once I finished my program, it occurred to me that someone else might have the same need for this program. I was thinking that, if I ran across anyone that needed this kind of program that I would just give it to them. After all, it’s a very small program. It wouldn’t be worth charging them anything for it and I’m the kind of person that’s willing to share. I was feeling especially good about sharing my program because I’m just that kind of person.

Of course, if I give this program to someone else, all the titles and prompts have to be improved. Also, they might want to use it in slightly different ways than I have, so I should provide various options I didn’t personally need. And so on and etcetera! I kept coming up with more and more changes I should make.

AND THEN…(no, I wasn’t yet done being a big creep!) I started wondering whether the person I gave it to might be someone that would want to make their own programming changes (that would be most of you, right?!  😉   ). As such, I started poring over the program agonizing over whether I should change my subroutines (methods) around, change my variable names, change my comments, and more.

You can see where this went – right down the garden path!

The Outcome
Finally, I gave myself a mental slap and stopped before I spent too much time on this. I realized I just didn’t have time for this and didn’t have EVEN ONE potential person to give my program to, in the first place. I was thinking about spending lots of time on something that I didn’t even know anyone needed and doing it “just in case.”

So, I’m not going to share my program and if it makes me a bad person, so be it. No-one will ever see my code to insult it, either! Although, there’s probably not even anyone out there that even WANTS to do that.  😉

In any case, keep this in-mind the next time you start thinking about what you COULD do. If there’s no requirement for it, it’s not needed. If it’s needed, in the future, a requirement will be issued.

And that’s the bottom line to this. If it’s needed, someone will request it and pay for it.

Gloria Metrick
GeoMetrick Enterprises

6 responses on “The Scope Creep and I Mean Me!

  1. Well written Gloria.

    I don’t know whether clients just get their tails up at the mention of Scope Creep because sounds so negative, or because they are being reminded of change controls. Does the negative thing for me, I initially misread the post title as ‘Scope creep brings out the mean me’!-)

  2. The principals you discuss apply to every business. Successful software is not made in a vacuum and it is not made by surveying people who have not invested interest. The best survey comes in the form of payment. If they are willing to pay for it, then it is worth doing. If not, then you would be better to spend your valuable, unpaid time on a hobby that gives you satisfaction.

  3. I’m not sure I’ve run across anyone that finds scope creep to be a positive thing. I hope everyone does find it to be a negative issue and something to avoid.

    In the end, that plus issues such as risk management are part of the project. If you don’t consider these topics, your project will fail. Software projects can’t go unmanaged or they fail and that is true of any but the tiniest of all projects, whether they be software projects, constructions projects or other types of projects.

  4. Scope creep is unavoidable I think, at least to some degree. You can do the best to plan out and design exactly what you want, but I am reminded of a great military philosopher, Helmuth von Moltke (Germany, WWI), who stated “No battle plan survives first contact with the enemy” Sometimes we are the enemy in this context. We plan and then as we develop we see something else that needs doing and as developers we just want to make it the best we can. Sticking to the agreed upon functions in a requirements then design environment can be frustrating to the users who want everything, but satisfying to the stake holders that pay for a successful project.

    Keep writing Gloria, I like your stuff!

  5. Very true William, ‘no plan is perfect’, I estimate by anything between 5 – 15 %? It is not uncommon that overlooked or additional functions are identified mid-project as users come to grips with a new system. Best managed in change control procedures, after analysis, to take adjustments to the specification, financials and schedules into account.

    We are not very successful in convincing clients that they should budget for changes and retain and remainder as bonus if not used…-(

Leave a Reply

Your email address will not be published. Required fields are marked *