Disputes about easily-observable facts are actually quite easy to resolve: just observe the facts. If I say “there’s a tree with purple wood outside my house,” anyone able to come to my house can verify the truth or falsehood of my statement for themselves.

If they’re complaining that FuncA used to be in the product and used to work in an earlier version and now it’s not working, and you don’t think it was ever in the product, ask them to prove it. (Or, in more gentle words, say something like “we’re having trouble reproducing the problem. Could you help us out here?”)

Give them a copy of the earlier version if they don’t still have one, and get them in a LiveMeeting, and have them show you how they used to use FuncA. If they can’t do it, then (hopefully) they’re realize that it wasn’t in there afterall and get off your case about it, or at least try a different tactic to get it implemented. (And make sure to get someone from management or PM in on the LiveMeeting.)

This is not an issue that can be dealt with on facts – if you try, you will loose credibility.

First, accept that the software is “broken” – as it it does not do what the users want it to do. Now, accept that the users have a right to have the software do what they want it to do – thats what the software is therefore. So what we have is defective software and an engineer refusing to fix it…..

As a result if the system you run to set priorities, these users cannot get their software fixed by going through the normal channels, so they are using side channels and escalating half truths higher up the food chain to try to out maneuver the system, in the mean time, making your KPI’s look bad(your main concern should be the customers, not your KPI’s) – Your KPI’s are considered “collateral damage” if they like you, or a beneficial side effect if they don’t. However, they do have some control over how much happens – best they like you.

So what is happening is the system is broken, and everyone is trying to manipulate things to get what they want. They want a feature, and you want to keep your spotless KPI’s.

Unless you can fix the system or learn to play office politics real quick, game over: you lose.

Note : None of this discussion involves Dead lines, bug vs feature discussions, who is paying etc. These are Facts – and facts do not matter (well, they sort of do, but they can be manipulated in so many ways….) in office politics.

Organizationally, I sense a problem.

There is a hierarchy that includes the head of IT and your boss. If your organization is traditional (it doesn’t sound like it is Agile), you are a resource and they are resource managers. You have a full time job called software development. If end users are directly requesting features, setting your priorities, and trying to manage your time, your managers are redundant. They may be accountable to end users, but if they are doing their job, you are accountable to them and they need to shield you from going out of focused developer mode into defensive developer mode.

A few points to set the context of my answer:

• Software developers are not time travelers, so the results need to be judged for what they are, not what they might have been.
• If a feature was in a requirements specification, a schedule, and was prioritized above work that was completed, there may be a legitimate complaint. Otherwise, what is the justification to hold you accountable?
• Your punishment, if merited, needs to come from your chain of command. Just as marketing and sales would not like it if product development scolded customers, most organizations have product managers to receive customer wrath (and praise) and convey it through channels.
• Product managers can create extremely difficult relationships if they bask in the warmth of successful parts of projects, but only ever crack the whip when they face toward developers.
• If you delivered functional product with a year worth of work, and it takes a month (or two) to add the desired feature, from what I have seen in our industry, your estimation was above average.
• Solving the problem fairly and productively requires that people put the fingers of blame back in their pockets and make a go forward plan.

You will be able to do much better quality work with better motivation if you are appreciated instead of being the goat in a process that the head of IT should own. It is the fair way and the productive way. I hope you will be managed that way, and sometime in the future, I hope you will manage others that way.

In case of reality failure like this, the best thing is to move forward. Instead of arguing about the past, talk about making it work and how easy or difficult that will be. It doesn’t really matter if the issue is fixing it or implementing for the first time. If management wants A done before B make it so.

Are you the only dev to have worked on this project? Sounds like you answered to someone while making the project. Where is that person in all of this? Where is the documentation for the project saying what was delivered?

There should be a document paper trail. A training doc showing how to use the application. A functional spec outlining what was developed. If a feature wasn’t included, there should be documentation on that too. Someone should have had to sign off saying they accept that.

It shouldn’t be your word against theirs, it should be all in the documentation.

If you don’t have this documentation…then I’m afraid you are going to have to bite this one. Consider it a life lesson. At the end of the day, your users are your customers, and as the saying goes: the customer is always right. Draw up how to add this feature and how long it will take. Have a meeting and say something along the lines of ‘Our records show that this feature was never implemented, but we can get it life in x weeks. Should we go a head?’

And for the love of all that is holy….get the documentation you need to show it was approved.