Error: Points Of View Do Not Match. Decision delayed.
During the past years, I've done quite a few projects. As a techie, I was often extremely annoyed at that which is so lovingly referred to as 'Decision Time'. After all, I was the techie, I said how it was to be done and that's the end of it, right ? Right!
Wrong. Unfortunately, there are many more factors involved in projects and the decisions that come with them. There's the 'Stay Off My Turf'-factor, the 'Awaiting Approval'-factor and the 'Yes, But What Does It Do ?'-factor. Three extremely important events in every project and very often, one of these factors is the reason a project totally and utterly fails. Let's take a closer look at these factors and how we can deal with them.
Stay Off My Turf!
Ah, the joy of starting a new job. The wonders of new challenges. Just imagine all the wonderful things you will achieve! Can you see the amazing new technologies you will introduce to the hungry minds at your customer ? I'm sure you can. However, there might be one or two people who will disagree with you. For example.. well.. everybody.
Most projects start with a mandate given by the managementteam at some level. It is suddenly decided that new technologies are desperately needed to compensate for the organisation's inadequacy of dealing with the streamlining of their everyday processes. So, instead of worrying about that, let's introduce some new technology instead. Hurrah! You're sent for to deliver the customer from damnation and certain doom. Nuts optional.
Fresh and fruity, you start the first day. You talk, you womble around, search for the coffeemachine and get to know all about the new people you'll be working with. Very soon, you discover that some are anxious to see you and some are, for some reason not. But why not ? After all, you will release them from the shackles of ancient technology into the free and wonderful world of modern opportunities!
The problem right there would be that that 'ancient technology' is probably what keeps certain people employed at the customer in the first place. They started administering and building it 20 years ago and have become completely unmissable because of it. Nobody knows how it works, the manual is written in ancient Swahili and the only way to get insight into the system's details is to wear a small strawberry-cake on your head on a clouded Tuesdaynight in November, dance the polka with a chair and sing the lyrics to the Dutch anthem in a falsetto voice. Then, and only then, will the veil of obscurity be lifted somewhat. Not a very likely thing to happen, is there ? And so, the people you need most for information and co-operation will deny you all access to their turf, making your work nearly impossible. When during migration you suddenly crash headlong into some vague batchfile that seems only to set the screensaver's time settings to 5 minutes but is also responsible for the complete flow of data throughout the infrastructure, they snigger and grin evilly from behind the large fence that separates their world from yours and say 'Told you so'.
So how do we deal with that ? A good question. The first and my personal preferred method is to gain their co-operation by making them realise that one way or the other, this change is going to happen and that they could benefit from being involved with the project. Surely, a good techie (or even a mediocre one) can gain sufficient insight in new technology by being involved in the setting up and development of the system itself. Trying to develop their enthusiasm by showing them what the new system can do is also a good approach, but you'll first have to figure out what makes them tick. I've succesfully done so a few times by showing GPOs to the system administrator that was constantly complaining about the enormous scripts of registry settings he had to maintain by hand; sold in second.
Awaiting Approval
So, you've got all the techies involved and eager to get started. Everybody's just dying to get started! So what's keeping them ? Well, approval, of course. Managers are often busy people and finding a slice of time in their schedule in which they can give the approval required can be difficult. To a techie, this is the most frustrating part of all. Why wait ? Isn't it obvious that this is the way to go ? Of course it is.
However, managers also carry the responsibility for projects in their department. If the project turns out to be a complete and utter ***-up, it'll be their behind on the line when they have to explain to senior management that 'Yes, we did spend 300K on a system that didn't turn out to work, but hey, we're all human ey ?'. Therefore, managers like to know what they're getting themselves into and will be reluctant from time to time to give approval to something they haven't checked out in every detail.
Dealing with this one can be easy. Though it takes a bit of time, make sure that you've written a clear and easily understood plan of approach. Outline all the products, methods, risks, benefits and costs until you're so sure that everything's included that you'd bet your life on it. Then, either plan a meeting with the manager in question or just assault him/her at the coffeemachine (preferably around 8 am when they're most vulnerable). Talk through the plan and make sure he/she nods at every line. If, at any point, there is a look of confusion in his/her eyes, immediately grind to a screeching halt and go over that part again until the frown becomes, once again, a nod. Don't make the mistake of ignoring the frown, it'll come to bite you in the ass later on.
But What Does It Do ?
Being able to translate a technical plan into a functional one and back is not easy. Sometimes, it can be impossible to describe the use of, say, a backend database upgrade to people that aren't technical or interested. This will turn into the scenario where you, with all good intent, are confronted with a room of people who say 'Yeah, but what does it do ? What's in it for us ?'. One hour later when you've stopped crying in a corner somewhere, you'll get a pat on the shoulder and hear 'Let us know when you've changed the plan'. If, at this point, you work in an office with a balcony at, say, the 10th floor, resist the temptation to take the easy way out.
Instead, sit down and completely forget about the technical details. And I mean completely. They no longer matter. Then, try to imagine all the things that may come from the project. Does it mean less maintenance time is required ? Do licences change and become cheaper with this new version ? Is there suddenly a way to allow users to administer their own rights instead of having to call the helpdesk and wait two days ? Write them all down. All of them. Accost one or two non-technical people at the coffeemachine (really, you should live there at this stage) and confront them. Examine their reactions and place a priority on all the benefits you've managed to come up with (invent one or two if your options are limited, preferably some that aren't really measurable in the first place) and then place them all in your shiny projectdocument. You'll be surprised at the next meeting. Really.
Conclusion
Naturally, there are many more factors involved in projects and the management of them. But these three are the ones I like most so those are the ones I put in. Hah.
What it all boils down to is.. 'communication'. Ensuring that everyone knows what is going to happen when, why, where and by whom is the vital factor to the success of any project. Don't make the mistake of assuming too much; always check every detail as well as you can, or make sure someone higher up has given written approval of ignoring the detail in question. I realise that that sounds like a rather sneaky thing to do, but quite frankly, that's the way it goes.
If that doesn't sound very appealing to you, then I'd advise you not to take up projectmanagement in any form. ;)