How do I get my manager to understand that our project needs to stop here, and that we have to be on a new track?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 ;-)

Answer 6

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.