Problem Resolution or Project Resolution?

Several years ago a large government department IT section was in almost total stasis with every person desperately running in circles at 110% capacity every day but nothing could be accomplished.

Each person would come to work each day and arrive to problem after problem as management wanted this or that done urgently and a plethora of every day issues like simple user requests kept the IT staff occupied.

It wasn't until the end of the day came and the staff crept away for the night before they were called to another crisis, that they realized that yet again, nothing tangible was accomplished.

I was hired as the process and change consultant to come in and, along with other things, find a way to get things done.

I was there for a number of months trying to find a way around this issue. I had other work which kept me occupied as I oversaw a large project so I wasn't simply sitting in an office (sadly, I'd like one of those jobs sometime ... or maybe not).

At first I looked at the normal things like task management and priority and while this gave a little more clarity, it still didn't resolve the main problem of too few hours in the day. I looked at the logic of hiring more people but already this team was larger than most other IT departments for the size of the department.

I tried several other "normal" and quite logical practices but this government department were set in their ways of abusing the IT staff, and in turn the IT staff were too used to stamping fires.
I was reminded of a saying as I explained the issue to a colleague one time: "sometimes, when you're fighting back crocodiles, it's hard to remember that the purpose of the exercise is to drain the swamp".
It was then that I came up with a fairly drastic idea. I worked evenings and weekends over the next few weeks to fully document my plan. At last I took it to the executive for approval and was pleased to get an OK with their full support.

Over the next few months the IT department were able to implement several major installations and other changes. Yes there were still the same number of problems coming up each day but now, despite these every day issues, major projects were being completed.

What I proposed and implemented was nothing less than a total change in the structure of the IS department. Almost every person had a change in their title and job spec. It was drastic indeed but it worked.

I changed the title of the teams to ""xx Project Team", I changed the titles of the team leaders to "Project Managers", and the team members to "Project Support" or "Technical Project Support".
So why would changing someone's title make that much of a change to the way they work? As it turns out, there are several reasons. Firstly it gives them an amount of empowerment over their work. They now feel that they themselves can make decisions on how they prioritize their tasks.

Secondly they now have a focus. No longer are they coming to work to answer phone calls and being pushed and pulled in every direction. Their direction is clear - the project!

By changing their titles and focusing them on project work they can still "stamp fires" as they occur but now can choose which fires need their immediate attention and which can be left to another time while they concentrate on the all important project.

These people were well qualified and good at what they did, it was just that they had allowed themselves to be rag dolls being pushed and pulled from one event to another and it wasn't until now that they felt any sort of control at all. It didn't matter what a so called "expert" said to them or what procedures he wanted them to do, they never felt they had enough control over what they did to even attempt to follow them. By changing their focus to project work, I had given them that control.

So next time you and your team feel harasses and finding it difficult to get things done, ask yourself if you are out to resolve problems, or projects. Look at the longer term.

It has been said that there are two types of team leaders: one would take their team into the forest and by support, moral-boosting and excellent project control, would cut down the most trees in a day; the other would arrive at the location, then climb the tree to look around, come down and say "guys, we're in the wrong forest we'll need to move before we cut down any trees".

Think about it, plan, and know you're delivering to the correct goals.