Dear Bob: ...
I manage a smaller-sized IT shop that has a number of specialties in it. This requires a great deal of trust on my part since I am not the technical expert at everything we do.
[ Also on InfoWorld: "In the midst of a tough assignment, don't be undercut by employees" | Get sage advice on IT careers and management from Bob Lewis in InfoWorld's Advice Line newsletter. ]
We started a data warehouse project a few years ago, and I began by hiring who I thought was a solid technical person to initiate the effort. The project initially went well, but I started to feel like it wasn't progressing like it should. Last year, I asked my best operational manager to lead the effort. We later added a second technical staff member to the project.
As you know, data warehousing is a highly technical field that requires knowledge on a number of fronts. I was concerned that my operational manager would struggle to become comfortable dealing with people who perceived themselves as experts; sadly, that was the case. He asked to leave the project. I complied and don't fault his effort at all. He is a solid leader.
Since that time, I have done some digging into the project and, in my opinion, have found some core flaws. I am left wondering if I did not offer the proper vision or direction, even though the entire reason I hired an expert initially was to tell me how to do data warehousing right.
So now I am left with doubts on the direction of the effort, and I am not technically expert enough to suggest a complete solution. My first thought was to bring in an independent consultant to do a one- to two-month evaluation of the entire project, along with a plan to move it forward. The expert would be someone who has been through multiple implementations. Of course, now I am left wondering how I would know if the consultant was really an expert.
Dear Warehosed ...
My first question is about the technical expert you initially hired to lead the effort. I see three possibilities:
- He's fully competent and issues beyond his control are what caused the problems.
- He's technically competent but lacks project management and other organizational skills.
- He's just a bad hire -- looked good on paper and in the interviews, not so good once at his desk.
If the answer is No. 1, then putting your ops guy in charge was the wrong decision. It would have caused bad feelings without fixing the problems.
If it's No. 2, then putting your ops guy in charge was a good decision, so long as you took the first steps in smoothing the interpersonals. After all, few people like admitting that they failed an assignment; many people project their limitations onto others. It wouldn't be surprising if this approach caused such hard feelings that there was no way to recover from them. But while a project manager should be knowledgeable about a subject, he or she rarely needs to be the authority on it.
If it's No. 3, then fire the guy and try again.
Now -- how to recover the project:
Step 1: Figure out if your data warehousing technical expert is salvageable. In particular, find out if he recognizes his own limitations with respect to making the project successful. The simplest way is to ask him to list out the skill sets he sees as being important for the project to succeed, which ones he can provide, and which ones will require the efforts of others. If he doesn't know, he should at least be able to list the skills he brings to the party in a credible way.
As part of Step 1, also determine whether he's still enthusiastic about the project. If what's happened thus far has soured him to the effort, I doubt you'll be able to turn him around this far into the game.
Step 2: You'll either be hiring another employee or bringing in a consultant. Either way, the conversation to have is to explain your company and how it works, lay out your goals for the project, and then ask two questions.
The first is whether they're the right goals -- is this what a company should be aiming for when implementing a data warehouse? Also, are you being too timid? Can you can get more out of the project than you're asking for?
The second is how he/she would organize and lead the effort -- what the tasks are, and in what order, to make something like this come together.
I've seen enough of these efforts to have a feel for them, and I'm sure they easily fall into the analysis paralysis trap. Among the abilities you'll need from the new person is the knowledge of when good enough is good enough, and how to create enough early successes to whip up momentum.
If a candidate doesn't cover these two basic points, you're interviewing the wrong person for the job.
This story, "How to save an IT project after a change in leadership," was originally published at InfoWorld.com.