Change management's mind?

Question

As a programmer working in an insurance office, I have a nasty little management hierarchy which is making programming much harder.

At current, our IT department rates a three on The Joel Test, which worries me. I'd like to fix this, but management enforces an insanely aggressive release schedule. Basically every project is due "yesterday". As a result basic planning is nearly impossible. Best practices like planning, documentation, and testing are all overlooked on every project we attempt.

So far, I've tried a myriad of methods. Everything from trying to frighten them with worst case scenarios, to referring to industry standards for advice on how to proceed on a subject. I'm at the end of my rope.

So the question is, what methods have worked for other programmers to change how management views programming. My biggest fear is that it is simply impossible to make them see the light, and the solution is "work somewhere else".

Thanks in advance!

Answer 1

Have you read the other Joel Spolsky article called Getting Things Done When You're Only a Grunt?

It is exactly about your question:

It can be frustrating when you're working in an organization that scores low on The Joel Test. [...] life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.

Answer 2

The Joel test is geared more toward an organization that is a software development company. I suspect that if your company's products are not specifically software, than you'd be hard pressed to get anywhere near half the score on that "test".

Just do as much as you can by yourself.

You can always go get another job.

As for management and convincing - the only real case you can make that they would probably listen to is cost. So show them concrete examples.

Again, I think you just have to do things your own way and take the heat and then make a lot of noise and commotion when it works in your favor.

Answer 3

If you can't change your company, then change your company.

Answer 4

Instead of trying to move the whole development team to a new set of practices, can't you try to convince your bosses to let you and maybe one or two guys to at least try some of those better practices in a small-scoped project, for a few months, so you guys can measure the benefits (or lack of) at the end?

Another approach is to be a bit contagious: get books like "Practices of an Agile Developer" or some book on CI and Source Control, and leave them around on the company, recommend them to colleagues, start talking about good practices during lunch time, try to get them infected; start sending interesting links by email or on Twitter, or bring a few of your colleagues to a user-group meeting.

Answer 5

What you have to show them is the intrinsic monetary value of the change. Fear rarely works, because, well, the problem hasn't happened before. Take small steps, and try an implement one idea at a time. Show them the benefit and how it saved money, and made people's lives easier. If you can reduce the "time to market" or the number of bugs found on a project, they will suddenly start realizing how it helps.

One of the key things is leading by example. When they tell you what they want the program to do, write it down, and a couple of hours later hand it back to them. Just ask them to look at it and say something like, "Hey can you look this over? I just want to make sure we're on the same page." Now you started to create a requirements document. It's things like that which affects process.

Answer 6

You'll need to show the value of process to management AND to your users. I've had years of experience coding for insurance people. Sometimes there are things that "MUST BE DONE NOW". Insurance is one of the most heavily regulated industires on the planet.

However, a lot of the time the urgency is just poor planning. Sell the benefit of planning and process. Sell it to your boss and to her boss and to your users. Take small steps and "sell like hell" and before you know it you'll have a process that works.

Remember, that the company makes money by collecting premium and managing claims, not by writing software. Your process will probably never be ideal and there will be many more "MUST BE DONE NOW" projects than you'll be comfortable with.

Answer 7

I tend to agree with Tim. Show them the money/cost of the situation. Everybody understands money. Let them know that in the long run not following good programming practices will only cost them in the future.

Another approach may be to show them the difference. Show them a old piece of software that is very poor due to their demands. Then show them another piece of software that you were able to work on properly. Maybe seeing the different quality will show them the light.

Finally if all else fails, start looking for your dream programming gig.

Good Luck

Answer 8

One thing that comes to mind is, are they project successful even if they are done under such poor management?

If yes, it's more difficult to change because all management is going to look at is cost and if it was a successful project.

If the projects continually have issues or become difficult to maintain then it is easier to change. You'll need to keep track of the money your company is losing and show how much more cost effective changing the methodology would be.

In one of my jobs it started off similar. The management just did not know about software so we had to push for what we thought was best. Things like "If we used source control we would not run into these code conflicts and lost old versions." or "If we take more time designing the coding is going to take less time and the result will have less errors."

Answer 9

You need to consider the possibility that you're wrong here and that the strategy adapted by your management is actually the correct strategy.

Not saying this is the case - but you need to consider it. Rationally. If my suggestion makes you angry, you need to take a few deep breaths, get your vulcan mindset on and consider it again.

Assuming that you're in the right here ...

Make sure that you're only working the hours you're contracted to work. Just because you're being given impossible schedules doesn't mean you should work yourself ill trying to fill them.

If your management is telling you not to plan, etc - then you shouldn't plan. Periodically send them evidence to back up your assertion that you should plan. Document situations where the lack of planning has cost your company money.

Try to understand that you have no control over this situation & there is no reason to be frustrated. You care about your job and you take pride in your work, but sometimes you've got to take a step back. It's not your problem. It's not you messing things up.

Finally - You should know that there are a huge number of people in exactly the same situation as you. I.T. is hard for all people concerned. This includes you and it includes your management.

Answer 10

IMO, the only way to change management's opinion is to become management. Things become a lot better (and a lot more challenging) when you are in charge of putting in positive change and following it through.

Answer 11

What are the problems from their point of view? Are projects frequently late? Is the code buggy? Show them how a change in the process will solve their problems, and you'll get somewhere.

If they don't have any problems, then you're spinning your wheels.

Answer 12

...programmer working in an insurance office...

They should understand risk management. Jon B's counter-question is most appropriate; you are trying to solve your problems, but will that also solve their problems?

another angle to consider is: what's in it for you? If you badger them into changing their ways and the payback is not 'fast enough' this might come back to haunt you. Of they'll get tired of the badgering and hire someone a little more submissive instead.

what do you expect to get out of these changes? what do you want to get out of these changes?

i'm not unsympathetic, i've been in your situation several times. It took me a long time to learn that fixing their poor methods are not what they hired you to do. When I fought this fundamental truth, I ended up frustrated and un-motivated. And occasionally unemployed ;-)

Answer 13

One thing that can help change management's thinking is capitalizing on the realization of your problems by people who are new to the organization. New fulltimers and consultants are a good source of this. They'll often come in and say something like "you know, you should really be doing it this way and I have witnessed first hand the benefits of doing so." A lot of times management will respond when they hear the doom and gloom message from someone new.

Answer 14

How about timecards? No seriously, while it sounds awful there is something to be said for tracking time to specific efforts. It allows you to show the cost of doing business without planning. For example, do an estimate on how long it would take (calendar time as well as man hours) to do the project the right way. When that gets shot down, go ahead and start tracking time spent (hours, including support and bug fixes, and delivery milestones) doing it management's way. At the end of the project, provide a comparison of the two which will probably show it cost more hours and was delivered late when done the wrong way.

Answer 15

Disclaimer: Please don't try this at home (or work):

Let's say that you're working at 133.33333% (can't put a line over the last 3 to indicate that it's repeating or I'd have just put 2 of them) more than you normally would, because of all the pressure you have on you, and let's say that you don't get the fulfillment you'd otherwise get from a software development job k. I think that's a fair summation of what you're telling us.

If these numbers were about right, I would (I kid you not, I've done this before):

1. Work even harder to make their deadlines while dropping quality even further.
2. Take 24% of my time and work on my own software on the companies time.
3. CYA in every way you can along the way so as not to be fired when the fan get's hit.
4. Spend that last 1% (which takes your value-add back down to 100%) and look for jobs online.

What will happen is four things:

1. You'll keep your bosses happy for the time being.
2. You'll be happier because you're accomplishing something your way (your own software)
3. $%&@ will hit the fan
4. Your company will A) Quit doing things the dumb way after learning the consequences, or B) Fire your $&%, at which point you'll have another job waiting for you.