Bob Lewis
Columnist

Developing, but not deciding anything

analysis
Oct 26, 20036 mins

Dear Bob ... Apologies in advance for a long set-up: Awhile ago I was given responsibility for supporting an end-user developed application. The requirements were not documented. Furthermore, the application was developed in a non-standard tool and not a traditional programming language. End-user satisfaction was extremely low because the end-user who developed the application had moved on to oth

Dear Bob …

Apologies in advance for a long set-up:

Awhile ago I was given responsibility for supporting an end-user developed application. The requirements were not documented. Furthermore, the application was developed in a non-standard tool and not a traditional programming language.

End-user satisfaction was extremely low because the end-user who developed the application had moved on to other responsibilities, and IT never fully embraced the tool or application as its own.

A year later I was successfully supporting the application.End-users seemed happy. I had developed a good relationship with the end-user who developed the application and consulted him on many changes. He also seemed satisfied, communicating to management several times on how well I was doing.

Then we downsized. IT was cut in half, and the end-user who developed the application was placed on the to-go list. I was retained because of the criticality of the application I now support.

Not long after that the site manager was replaced. The new one replaces the IT manager with someone from his former company. Then, six months after the downsizing announcement, within days of the end-user leaving the company (and then meeting with the new head of the site on several occasions), a special position is created for him reporting to the site manager: He is assigned a special project. It’s a business change that mostly impacts the application he once developed.

The end-user starts dictating application changes that go well beyond the project scope, including major design changes and tool upgrades. He begins to micro-manage coding and design efforts – necessary, he says, because IT doesn’t understand how to code in the tool and lacks his experience.

We don’t have major philosophical differences on approach. We end up arguing about petty issues such as variable names and data to be carried between functions in the application.

I begin pushing my management for clarification of roles and responsibilities.

After several meetings I am told the end-user is ultimately responsible for all aspects of the application, including the project/business definition, IT design and coding, and project management. I will “matrix” report to him and IT as this should correct the “problems” the application has been having, and his newly-expressed issues with my past efforts. I am to continue everything I have been doing but allow him to have final say on whether it is okay.

I am frustrated and upset with my management’s lack of support and the end-users lack of trust in my ability. I believe in Business projects not IT projects and IT/Business partnerships, but I wonder how this can be viewed as a partnership.

I wonder what is said behind closed doors, and whether there can be any future for me in this organization.

What do you think is really going on, and what I should do?

– Down and out in IT

Dear Down …

That’s quite a story. It makes me wonder what the story is that neither of us have heard – the story told by the end-user to your management, and their response. My guess is that you have nothing at all to do with this. It sounds more like the end-user is jockeying for position. You’re the one who made him dispensible, by learning the application he built. Before you came along, he was the only person who could support it, after all, even though he had moved on.

He has to position you, and IT, as being less than fully competent to support this application in order to shore up his own precarious position.

There’s also a pretty good chance the new site head is trying to create a situation that will justify establishing a full-time position for the end-user.

That’s how I’d interpret the situation. If this analysis is correct, the worst thing you can do for yourself is to end up with any independent decision-making authority. If you do, the end-user will be in a position to blame you for any problems that arise.

I think your best course of action is to avoid playing games. Sit down with the end-user and ask that he provide you with variable naming and coding standards so you and he don’t have to make every decision by consensus. At the same time, ask for a formal code review and sign-off process. If the end-user objects in any way, explain that he’s running this project differently from what you’re accustomed to, and while that isn’t necessarily a bad thing, it does mean you need to know how different kinds of decisions are going to be made so you neither overstep your authority nor needlessly delay progress by consulting about decisions he’d prefer that you make yourself.

If the end-user refuses to establish any ground rules, telling you everything needs to be handled on a case-by-case basis, point out that it’s his decision. You’re just trying to avoid the delays in the effort that will result from a case-by-case approach. If he’s willing to live with them, it’s his call.

Then, write up your agreements and send them back to him via e-mail, cc: your own manager. Make it clear you’re doing so to make sure you understood everything correctly.

Don’t be testy about any of this. Your job is to be calm and professional. There’s a pretty good chance this will circle back to your management with the complaint that you’re being difficult. You have to be able to say, with complete honesty, that you were simply trying to clarify the process by which the end-user oversees your efforts – how is that being difficult?

In the end, I’m guessing it’s going to come down to the company choosing between you and the end-user as far as who stays with the company and who leaves. The end-user will probably continue to disparage your efforts, based on this understanding. Don’t disparage him back. You don’t have the ear of the site head, so you’ll just make yourself look worse without accomplishing anything useful.

Instead, do something useful: Ask your own manager, still calmly and professionally, whether you or the end-user will be supporting the application at the end of the project, and if it’s the end-user, what role they see for you in the company.

What your manager says is less interesting than how he/she reacts to the question. Based on that, decide how much effort you spend looking for your next opportunity.

That’s how I see the situation based on your description. I could be completely wrong about it. You have to decide what you think is going on in the background based on your own thoughts about what’s likely to be motivating everyone, and choose a course of action that is appropriate to the circumstances.

– Bob

——–