How to advocate a different approach to a project when office politics are involved in the decisions?

Question

My group has found itself in the position of being forced to implement software projects in a technology that has proven to be a poor fit for the kind of work that we are being asked to do. Due to this mismatch, projects have not been delivered on time, since we have found ourselves having to work “around” or fight “against” the tool, rather than with it, to achieve the results the clients want.

This has been the case even when contractors who are experts in said technology have been hired to do the work. However, management still insists we use said tool despite the fact that free, widely used and proven tools that would be a much better fit exist. Given this, and other apparent evidence, it looks very political in nature.

Despite this, I was able to come up with a proof of concept using a different technology over a couple of weekends. I know that this alternative approach not only would deliver the same results, but that it would also be more flexible, and allow us to be more efficient with our time.

Given the possible politics involved in management’s decisions, what are some effective and persuasive ways in which I could present my proof of concept without being off-putting?

Edited on 11/8/2012 at 2:27pm to add a bit more detail:

When I have inquired about the rationale for using said tool, the reasons have been different each time. First, it was said that the tool would make us more productive, and allow a faster turn around.

However, when reports came back of clients wondering why it takes so long to deliver, the reasoning then changed to be that the new tool would make it easier for others to do the same work. That has proven to be incorrect as well, as people have not been able to achieve competency with it any more easily than other tools we've used in the past.

The problem, as I and other see it is that the tool is very nice and easy to use within a rather limited 'sweet spot', but all of our work so far falls outside of that narrow range.

Answer 1

You will be a lot happier if you learn about two important business concepts that may apply in your case:

• productivity is not the only goal
• local vs global maxima

Whenever a developer says "I would be more productive if..." and yet they aren't allowed to do whatever that second half of the sentence is, they say it's "politics" and want to know how to force management to let them. And to be fair, sometimes it is politics. The boss came up the ranks using VB and he likes it so everything these days is in VB.NET. The boss golfs with a guy from Oracle so everything is Oracle no matter what it costs. If you're in that situation, give up. Learn to like using those tools or get a new job. But do you know the boss' career background or who he golfs with? There are other explanations.

When you work alone, all that matters is your own productivity. Use whatever tools you like, work whatever hours you like, adopt whatever processes you like. Sometimes you might use the free tool because you can't afford the paid one, but to be honest it's pretty easy to get free copies of expensive tools, especially for a startup. (Eg BizSpark gives startup ISVs all the Microsoft software they need, for an unlimited number of developers, free.) But when you work with others, things like productivty are still important, but they're no longer the only thing. Predictability - everyone's ability to know what is going to happen when - suddenly matters a lot. For example, say you are planning to code a small (4 hour) change Monday, to be tested by your people Tuesday, the client rep Wednesday, and go live Thursday. But Monday morning you have a headache and feel crummy. You realize it will take you 8 hours to get it done that day. You would be more productive putting it off a day. Problem is, even if the others can find just as productive ways to spend their days, you've disrupted their plans. You might find the IT guy refuses to deploy on Fridays so he has to wait till Monday. And that might change a line in your manager's spreadsheet from "deployed week 33" to "deployed week 34" - all because you wanted to be more productive Monday. This is true at a small scale and also at large. Being able to stick to plans has value, and sometimes it's more valuable than productivity.

Other things have more value than productivity too, like manageability and transparency. So if you want to use a free text editor to write your code, but it doesn't integrate into the work item tracking system, it's not ok for you to personally decide to opt out of the work item tracking system in the name of your own productivity.

Then there is the matter of optimizing your own productivity (local maximum) or optimizing the productivity of the team as a whole (global maximum.) To use an example on a small scale, if you want to work midnight to 8am, that might make you more productive, but it means other people who have questions for you have to email them, then wait till the morning to read your answer. The search for your local maximum has moved the team as a whole away from the global maximum. Or if you create docs locally using Word, but the team is all using Google Docs, there will be an impedance mismatch where you don't upload things or download things and others assume yu have. Same problem. This also happens at a larger scale you may be unaware of. That database you all find so hard to work with may be just what some other team needs to do the reporting. Or that service bus that's adding a layer of indirection and making you crazy may be vital for the customer's communications with another partner. There may be a solid business reason why your team operating at a lower-than-possible productivity is in fact best for the business as a whole, just as there is a solid reason why you operating at a lower-than-possible productivity is best for the team as a whole.

Of course, it's possible that nobody ever gave any thought to another way of doing it. Perhaps your proof of concept will be met with opened arms, and everyone will swing over to the new way immediately. It can't hurt to show your boss. But if it's rejected, understand that it may be because of golf or personal prejudices, or it may be for good and solid reasons that you just don't happen to know.

Answer 2

One question you should start with: would you and your colleagues promise project delivery faster and/or cheaper given that you were able to choose a technology freely? Of course I assume the promise wouldn't be ill-willed and you'd strive to keep it.

This is sort double-checking, but I start with this with a reason. I worked in the organization facing a very similar challenge and when it came to make a call the team wasn't sure enough that they would manage and they retreated back to the old hated technology--after all no one could blame them for failing then as it was the standard tool. "No one got fired for buying IBM."

Given that you're sure that you'd do better with a new technology the best you can do is to refer to facts:

• Show your proof of concept and share data confirming that it is faster to build.
• Address concerns that the new technology may be expensive and/or difficult to maintain and may have no support from creators in a couple of years from now (while you will have to maintain your application in 5+ years from now). Usually mainstream technologies are easier to "sell" in this way of discussion.
• Address a risk that only few people across the company would know the new technology. Is it popular? Are people willing to learn it? Are there enough materials on it in the internet?
• Learn what technology constraints you have in this project. It may be the case that there are some things in the contract that strongly limit your choice of technologies. In this case you likely want to act within these constraints. There's no point in banging your head against the wall.

Finally, be prepared that proposition may be turned down, for political reasons. Actually, this is exactly the case of the org I mentioned earlier. Technology-related reasons aren't the only ones that are in play. The company might have high stakes in using technology X even if it isn't best of breed. Actually high technological diversity comes at a price, and not at a small one so be sure you understand why this or that is finally chosen. After all, this may be a driver for you to change a team or a job.