Let's say, I've been working on a watch. This is your ordinary pocket watch, it has hands, gears, shows the time...

About a month passes, and they want us to make this into a wrist-watch, still with the analog design, but fits nicely onto your wrist. They don't want to spend the time making a wrist-watch from scratch because we already have a pocket watch-- and they're kind of the same.

After a bunch of work, and an awful mess of gears, the watch is now a wrist watch, somewhat bulky but it is passable as a wrist watch.

Time passes, and they actually want this wrist watch to be a grandfather clock, instead of building one from scratch, because they both tell time.

So I scope out a design that will be easy to make this into Big Ben, so when we're done the grandfather clock we can make the next demand suitable.

Except, they now want wrist watch again, but with a digital read out, not analog. So we have to make the gears display analog time.

This is driving me insane, and I can't find a way to explain that these software projects that all seem similar are actually very different. They don't understand because they have a legacy system that's huge and ugly, as well as a new pocket watch that was small and simple and met the goals as originally scoped out, they want the pocket watch to grow into a LCD version of Big Ben. Instead of designing LCD Big Ben, we're screwing around wasting time working up-hill both ways.

I've attempted numerous times to explain this situation. They don't get it. Even worse, they seem frustrated and stressed out, give me assurances that changing tracks and starting fresh will happen-- "right after this next more change" ... which happens indefinitely.

I'm at a loss of solutions.

Solutions I won't accept:

  • Say what I said here: I did that.
  • Quit: No. That's not a solution.
  • Attempt to wrap them in bureaucracy: I did that.
  • Is the frustration because the project just doesn't seem to end or are you also not being paid properly for the work? Commented Feb 17, 2011 at 15:44
  • Never ending, failure to specify a target. The target changes before the ink is dry. I have no sense of accomplishment. Cash-incentive isn't really a concern I personally feel, as long as I can live my day-to-day life comfortably enough.
    – Incognito
    Commented Feb 17, 2011 at 16:03

6 Answers 6


The problem is here (quoting you): "They don't understand". It's not their fault, it's your fault as a project manager. They should not understand, they should obey your rules of work. Otherwise you're not a project manager, but just a project coordinator without any authority in the project.

This is how you should talk:

- "We actually want this wrist watch to be a grandfather 
  clock, instead of building one from scratch, 
  because they both tell time", - they say
- "No problem, +80% of budget, +60% of time and 
  it's done with originally planned quality", - you answer
- "How about +20% of budget, +10% of time?", - they 
  try to strong-arm you
- "Not a problem, but quality will be 3 times 
  lower", - you answer absolutely seriously

Always remember, that you are protecting the project, not your career.

  • yegor, maybe you answered this with your last sentence about protecting the project but not the career. However, let's say the poster isn't really given 100% of reigns of the project? I have seen this countless times especially if the I.T. Director has their hands in the mix. Then what? In some ways you have to respect your boss even if their decision are illogical. Then what?
    – Brian
    Commented Dec 1, 2011 at 19:25

You're the expert of your project and it's your responsibility to apply that expertise of yours. Don't ask for permission to change track and start fresh, that's an internal strategic decision on how to best fulfil your manager's request.

Be assertive about this. Let them know that you're willing to deliver exactly what they're asking for, but that given the beaten path, it will inevitably take some time. If that means that you're actually starting fresh, then that's a decision you're making because you know the project best. This is exactly the kind of decisions you're hired to make.

You can advise against a request, but you can't really disobey it. Explain to them that their request will take a long time to fulfil, and if they still prioritize like that, then do what you have to do to deliver accordingly.


This appears to be a classic case of scope creep. A couple of "tests" I suggest you put your project too.

  • Have you documented your requirements (SOW, ToR, etc) and has it been signed off?
  • When was the last time this document was updated?
  • Is there a signed off Change Request (including impact, cost, schedule, etc) for each direction change?
  • Is there a deadline and how "hard" is it?

I have found that once the true impact of a request is analysed and made visible to all stakeholders there are considerably fewer raised or approved.

This should not be viewed as bureaucracy or admin, it is the single most effective tool in defending scope, schedule and budget in a project.

  • I find your answer very useful, the problem I'm facing now is a constant demand to cut corners that make life a pain for things we need to do later, and I find it applicable there as well.
    – Incognito
    Commented Dec 1, 2011 at 13:04

Good question. There are actually two parts to this question: communicating this in a way that they will understand, and making the project actually work the next time change is needed.

If this is a software project, then the solution to the second part is to do your best and make the architecture robust enough that it will easily flex to change. This can mean many things, depending on your legacy systems. At worst, this is the best you can do. (Except maybe quitting.)

Regarding understanding -- it seems the problem is not that they don't know, but that you're not saying it in a way that they understand. One suggestion I have is to draft up both designs (from scratch vs. reuse) and estimate both (fairly) and see which one is less time. Then, show them the time estimates, and let them decide.

Finally, it's not always the best idea to start from scratch; you may never get the opportunity. The best thing you can do is try to estimate both versions of the project (from scratch vs. not) and build it the way they want you to build it.

  • I have attempted displaying the difference in time as well. I'm starting to believe this may be a fundamental lack of discipline for sticking to plans that are not intuitive to them. -- Architecture redesign isn't suitable to the deadlines, which is why we need to re-start design, rather than ad-hoc tweaks here and there.
    – Incognito
    Commented Feb 17, 2011 at 16:08
  • It sounds like you're locked in a situation where you cannot effect the change that you would like. You've tried various approaches, all fruitless. Maybe it's time to get a new project sponsor; short of that, I think you're stuck.
    – ashes999
    Commented Feb 17, 2011 at 16:18

If it is a sales-focused company, you're in for pain.

I have no sense of accomplishment

They don't care. Just get it done. They have $£€ signs on their eyes knowing they will be able to sell that wrist-watch that is also a big-ben transformer that can make coffee while playing music.

"but it is passable as a wrist watch." instead of explaining and insisting on the right approach. (Michael Durrant)

What does it mean the right approach? Are you just one of those guys that want to do things by the book? As long as it sells, who cares? They cannot wait 3 months for you to refactor and to it the right way. They want to start selling it next week; they already made the brochures and promised it to some customers.

Yes, maybe the right way would make it easier to expand the product later, or make it more efficient, or whatever, but they probably don't even know what new crazy idea they might come up with tomorrow.

I feel your pain.

PS: Yes, I know this doesn't really answer your question.. and it's full of assumptions. I'd like to know how close I was, though ;-)


It feels to me that your project manager do not accept "your autority"; he (or she) is not listening at all. I am talking about your team member autority. Your project manager will make you pay the price of your collective failure. Your are both fighting an useless battle. You should have an explanation with him; an honest one. If he does not listen again, he will be responsable of the collective mis-organization of your project. If you face a wall, I would talk to the boss of your boss. He won't like it; but you will save a bondel of money to your compagny. You should be the project manager.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.