What techniques are necessary to convince (upper) management to abandon a project once time has been invested?

Question

I want to convince my manager and (probably) his manager that a project needs to be scrapped and we need to purchase an off-the-shelf solution.

Somehow it was recommended that, rather than use a pre-built solution like FogBugz to do our task/issue tracking, we should roll our own. Now, this is definitely not a core service for us. The current price to purchase an unlimited site-license for FogBugz for our server is $15,000 USD for the Kiln-integrated version. $10,000 for the standalone version.

At the current rate we charge per developer hour we have now spent $35,000 on our project which is nowhere near as useful or complete. Even if you're just looking at "actual" developer cost (just our salary) we've spent at least $17,500 USD. I know there are other related maintenance costs, but they'd be closer to $2,500 than $20k. Of course our system isn't even close to as full-featured as FogBugz.

---

Now here's the real issue - I'm an extremely junior developer (< 6 months, fresh university graduate) at my company, and employees who've been working since before I went to college are the people who made the recommendation that we do the development in-house. A system that has close ties with our project is my direct manager's baby, and I'm not sure how much he emotionally has invested in this - he did do some initial leg work before we started the project.

I'm worried that my junior position makes me fairly vulnerable, but more particularly that I'll come off looking like a snotty-nosed know-it-all. I know that I might be discounting some of the other expenses here, such as servers (cheap!) and administrators (not so cheap) to maintain the system, but I'm almost 100% certain that I'm not discounting it to the tune of around a half-years' salary.

I have a fairly good repoire with my manager, so I'm sure that will help. I'm also aware of decision fatigue, so I'll make sure to bring it up in the morning or right after lunch. What other skills/data should I bring to the table to increase the chances that I'll be taken seriously?

Answer 1

In no particular order:

• Make sure you understand clearly what your intention is, and convey that at the start of the discussion as an opener. It helps if your intention is tied minimally to your own emotions, and has the company's interests in focus.
• Even if your environment has an open door policy (come in and talk any time), send out a meeting request with what you want to discuss. That way you know your manager isn't going to be in a rush to get to something else. And it lets them not be blindsided.
• You've got a clear idea of how much has been spent, do you have an idea of how much it is going to cost to fix the issues that remain with the in-house solution? What has already been spent is gone. It is important to compare the costs going forward on each path.
• Be willing to honestly listen to their side, don't interrupt. You may pick up some information you weren't aware of. And if not, at least you have been polite.
• See if any of the more senior developers agree with you. If none of them do, see if there is a pattern to why not. If you find an ally, it can be beneficial.

Answer 2

Do the management of the company have a history of shelving projects which won't pay back for themselves?

If they do, then you'll probably find that they are already considering this.

If not, then you're not just talking about getting one project cancelled - you're talking about changing the culture of an entire company. There may be all kinds of things which you're not aware of that cause the anti-pattern you're seeing: management bonus schemes, a culture of blame, a desire for control over the code, etc.

To increase your chances of being taken seriously, go in with an attitude of curiosity, rather than a desire to change. Ask your manager what he thinks, and empathize with what he says. If the project is cancelled, will he still have a job afterwards? How about his manager? What other benefits are the team getting from being able to code this themselves? Are they learning useful skills? Are there any other projects that they could be working on that might be more valuable?

If you decide that you'd like to try changing the culture, then what could you do to create an environment in which change, learning and experimentation were accepted? Small things can be powerful. Can you run a workshop? Arrange for you and your peers to attend a conference? These are the kind of things you probably have the authority to do. Once development teams start to value learning, managers will start to listen and you'll have the backup you need from your peers.

You could also benefit from reading books like Robert Cialdini's "Influence", the Heath's "Made to Stick" or Mary Lynn Manns' and Linda Rising's "Fearless Change".

I've worked for a while now as a change agent, and the first thing to do is to listen, appreciate the context, and only then start to create an environment in which change can happen. Also, appreciate that change comes slowly. Really slowly.

You're probably not going to be able to do anything about this project - but you could help prevent the next one from going the same way.

Answer 3

While it often appears folks up the chain of command do not know what they are doing, in most cases, they have information you do not and they do know what they are doing despite the seemingly glaring contrary evidence. Being just less than six months into your career, you have at least five more years of some significant learning before you would have an ounce of credibility to challenge decisions made, and even at that time you would be advised to tread carefully.

If I were you, I'd keep my mouth shut except to ask questions with the intent to learn, not to challenge.

Answer 4

Given your level of experience, and that you've only presented your view of things, we have no real way of knowing if you're correct. So in this case I would suggest you heed David's advice and err on the side of caution. You're in no position to "convince" anyone of anything.

Having said that, there's nothing wrong with pursuing this, but you must do it from the right perspective. You DON'T know the why's, so ask. Ask if you can talk to your manager, with the stated intention of learning more and understanding the decisions. Tell him that you realize you're new at this, and from where you sit it doesn't make sense, so there must be something YOU'RE missing, and would he help you understand it? Most people are happy to walk you through their thought processes and explain how they got to some conclusion.

And who knows. Maybe you're correct in your thinking and a conversation like this turn on a light bulb in them. But only if you're genuinely doing it from the postion of learning and trying to help, not arrogance.

Good luck.

Answer 5

In general such a question should be more of "What to do now ..." than about "How to tell management..." that changes everything. Here is what i would recommend.

1. Be very clear about the problem - initially, i would rather raise the questions only about existing approaches. Point out all laps and issues that are arising that are measured/observed by everyone and agreed upon issues. If what you see as issue, is seen by others as great way or only way to do things- chances are suggesting alternatives is looked like trying to fix what ain't broken!

2. Focus on CORE issue. I mean here, is that what is one fundamental (try maximum 3) reason why things are wrong. My boss here always puts a point as "give me one reason to change things - not 10!". The reason is at times there are so many reasons to change things but none are significant to affect the status quo; that doesn't help.

3. Make sure that the reason you find is generally an accepted problem by all. When people disagree that such a problem exists, it would backfire. When finance people disagree that project is unwanted cost -management won't take anyone's advice. And unless customer's formal complain piles up people wont believe that services are not delivered properly. This is generally a case, because whenever there are certain things supported, there has always been long running beliefs in the favor of the project.

4. In no way, a suggestion should look a counter prejudice about promoting some other project. (In your case FogBugz) Else usually, the argument might go against the alternative you are suggesting rather than the core issue.

5. Most important - make sure to be objective. Any discussion, debates, one must stick to agenda of a clearly defined objective and purpose. When people perceive you to be biased, no further argument from your side might ever help.

This might sound as if putting management on the darkest side of the work.

Answer 6

A Build vs Buy discussion is one that I hope would have taken place for something as common as an issue tracking system. Prior to booking a meeting or lunch meeting with your manager I would dig a little deeper into the "somehow we built this..." aspect of your question.

Are their aspects of the tracking system you are building that are very specialized to your core business needs?

If there aren't I would book a meeting keeping the points that Kyle already mentioned in mind.