I would love for the simple answer to be to say “No.” To stand up for your project plan and combat the forces of evil that are working tirelessly to ruin your brain-child. Unfortunately saying no generally lands you in the dog house with your superior, or fired and replaced with someone who may or may not be your better.

Many of us know that taking the direct approach will generally land us in the unemployment line, and so people generally tend to do nothing. I’m not saying it doesn’t work, but I can say that you have to be on very good terms with whoever you are dealing with if you want to pull a stunt like this. For the record: clients like this even less than bosses, so you can easily swap the two. If the client drops you because of your nay nay attitude, you could still end up in the unemployment line making my visual just as real.

So what can you do?

Talk it through

You can always try and talk them out of it, or at the very least discuss the validity of adding their new bauble to the project at all, let alone so late into it. This option is usually attempted in the “last-ditch” phase of everything, which is a shame because that is when it is least useful. Try this tactic first if only for the fact that it poses the least amount of backlash. The ensuing discussion could actually lead to different approaches or insights that may actually help you with the newest addition, or even another part of your project. You may end up doing it, but at least everyone knows where they stand.

Bargain.

This doesn’t always work, but it is generally worth a shot. The most painless and the easiest to approach, try bargaining with your client/boss to see if you can avoid their addition, or add it to a later release. I suggest the latter because if the suggestion isn’t utterly retarded, then you have a goal for the next release which will make everyone happy. If, however, it is bat-shit insane to add then try and talk them down from their idea.

Make sure the request isn’t documented anywhere, and other devious things

This way you can “forget” either willingly or by taking advantage of your piss-poor memory. I don’t personally suggest this because unless your cliboss (made it up, and I’m going with it) shares your goldfish memory, they’ll probably neglect to mention it until you think you’ve gotten away with your scheme, and now you’re stuck doing the late shift. This will also probably make you look like an idiot, and send you down on the foodchain. From what I have seen, experienced, and otherwise know, I can honestly say that subterfuge works the least in almost any professional situation.Unless you’re a professional con-man, you’re probably going to be seen right through. Save yourself the agony and try a more legitimate approach.

Suck it up buttercup

You could of course do the work. This is an option, and one that many people are stuck doing. Sometimes you can’t get out of it, and it will hurt you inside every time. This is doubly so if it is legitimately your fault. If you missed something in your analysis phase, it makes you feel more like a moron when you’re burning that midnight oil to meet your cliboss’ (still using it) expectations. An easy way to help avoid this is to make sure you do a solid and thorough job on your information gathering and analysis. Make sure you involve the required parties to actually cover the angles needed. This won’t stop scope creep every time, but at the very least you can be safe and sure that it is not of your doing. Bitterness is better when it’s not directed at yourself.

Stick with “No”

If none of those work, you can still say no. The only way this can work is to back up your negativity with solid proof that by including feature X into your doodad, you will not be able to hit the deadline. You’ll generally need to back this up with graphs, numbers, and strong reasons as to why it can’t be done. You’ll still get the skunk eye, but at least you can feel better knowing that you can back up your stance with information to support you. This also has the added bonus of making sure that someone in charge is informed, which takes much of the responsibility out of your hands. Granted this may not add up to doing anything more than wasting time, because some times the addition just has to be in there. It sucks, but sometimes you’re boned either way.

Sometimes you’ll end up getting screwed over and end up working late or whatever you need to do to get the job done. It’s not really avoidable in ever scenario. You can limit how often it happens though. The best way is to make sure you’ve covered your bases throughout the entire process with sign-offs and cliboss interaction. The more they are involved from the start the more personal responsibility they will feel, and the more information you can work with from the get go.

Fast forward to my current job. I can assure you that there are a plethora of examples that I could choose from for the point I will be making here, but one strikes me as perfect. You see when we developers started there things were volatile, unstructured, and pretty much a mess. My now fellow programmers and myself were hired in the wake of a collection of other developers leaving for one reason or another. We were also thrust into a project pretty much from the moment we sat in our chairs.

This was all fine and good, and we build what we thought we were supposed to build. Three days before we showed it to the client, we went through a run-through with the manager, only to find out that what we built was not what the client wanted. Well okay parts of it were, but for the most part it was off the mark. The result was months of us working grueling hours of overtime, wherein time became an abstract concept and my world knew nothing but code.

What the hell happened?

We didn’t have a process.

We built what we were told to build at the start, but things changed. The functional spec. was updated and we were never told. On the flip side, we also never went looking. Communication was sub-par at best, and the short of it is that there was enough blame for everyone.

We thought we had a process, but the debacle that we ran headlong into demonstrated that whatever process was in place either wasn’t working or was never initiated. The result was everything blowing up in our face. As it turns out, if you do not learn from this mistake, it will happen again and again. I could pull from more examples, but I’ll refrain… sort of.

I am on a new project, in fact I am the lead developer of said project. It’s my first time doing this and I’ll admit that it is a daunting task, but I set about doing my best. I was given a functional specification, which I thought odd because I’m pretty sure I’m the one that’s supposed to build that. I was told to add my section to it and that was that. I did so, to the best of my ability, with the information I had available to me.

It was okayed, and I started handing out tasks and the development cycle began.

Then I was told that the way things were supposed to work wouldn’t work that way anymore. This was after we had built stuff. This is generally a bad design move, because now any development that was already done now has to be reviewed and possibly scrapped. I updated the spec. again, and away we went. Then I realized that something wasn’t covered with the information I was given, so I asked a question. One question, I swear to God I only asked one but what was the end result? Another overhaul. Another attempt at the functional spec.

This has happened a couple times, and is not how the process should work. In a perfect world, the functional spec. is completely done before a line of code is written. The world is not perfect of course, and we have to make do with what we got, but damnit, I wasn’t about to go and take another stab at anything only to have it change on me again. So I went back to my college roots, and I made a decision:

I will make the process work again.

How can I do that though, when everything has apparently been thrown to the wind? It’s easier than I thought… well sort of. It still requires effort, but I’d rather expend the effort where I did fixing the process then rebuilding anything three times.

I sat down with my other main developer, and we went through everything. We went through every aspect of the functional spec, screen designs, and data sources, and figured out how it all works. We asked all the ‘hows’ and ‘what ifs’ as well as all of the ‘what the hells’ that subsequently came up. We went through every resource, created or not, and decided what was needed, what information had to be stored, etc.. We created use cases for the complex cases, and walked through more processes then I would care to count.

The end result? I spent ten hours (minimum) in a board room with a print-enabled white board and wrote everything down. I’m pretty sure we have at least 15 printouts of notes and questions and diagrams and use cases which helped clear up the utter ambiguity that surrounded the project. They get it now, and so do I. It’s no longer a matter of “how does this work?” but a matter of “what’s the next task?” Yes I have to update the functional spec. again, but at least now I know what to add, and where. The document is finally useful, and the project is understood. The process exists once again.

I’ve also taken it upon myself to write all of those tasks down in a shared location, so that whoever is on the project can take on new tasks as the run out of their assigned ones. That way no one has the excuse for not knowing what is next.

So yes we lost a day of development, but we have saved ourselves days of effort of unneeded rebuild time. Do it right the first time, and you’ll save time later.

On a side note, Sorry Mr. Miller turns out you were write all along about Analysis. My Bad.