Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. Tom first describes a common problem scenario, based on a real-life situation. He then offers a solution, using practical project management practices and techniques.
I met with Sandy last Monday to discuss some problems she’s having on her current project. Sandy has a small team working on a new taxing algorithm—an area that she is very familiar with. In fact, she may perhaps be too familiar with the subject.
“Tom, if you had asked me a week ago, I would have told you that this project was in good shape,” Sandy said. “However, now I find that we have a fair amount of reworking to do, and we will probably be over our deadline before we deliver the solution.”
“That’s no good,” I said. “Why did the project turn south in just a week?”
“Well, we delivered the first working model of the new taxing algorithms a few days ago, and they’re not calculating the taxes correctly,” Sandy said. “I am very familiar with the old taxing model, but the new model has some twists that I didn’t anticipate.”
“Did the client provide specifications for you?” I asked.
“Yes, we had pretty good specifications,” Sandy said. “However, it’s impossible to state all the permutations that need to be programmed for. At certain points, I had to make assumptions, and it appears that they were not all correct.”
“When you had questions about the requirements, why didn’t you just ask your clients?” I asked.
“I’ve been working with tax applications for many years,” Sandy said. “I thought I knew as much as the client did. I guess it turned out that I didn’t.”
There’s no question that IT people with business knowledge can be a very valuable resource. These people need less cross-training, and they can speak in the same business language as the client. In many cases, they can make suggestions and improvements to the client based on their dual knowledge of both IT and the business.
In general, having a good knowledge of the business area you’re working with is good. One of the only times that this knowledge can work against you is if you start to take too much for granted. That’s the problem Sandy encountered. She’s very familiar with the nuances of tax policy and, normally, she and her team can make changes to tax applications very quickly.
In this case, however, the new taxing algorithm was very complicated. If a typical project team were working on this effort, they would have called the client to ask how the algorithm should work in certain cases where the specifications were not clear. Sandy, however, thought that she would save her client and her team valuable time by making these decisions herself. Unfortunately, since the algorithm was new, she did not always make the right decisions, and now the team has created a complex program that is not accurate. They are faced with having to reprogram and retest portions of the solution.
A similar situation occurred in another company that I used to work for. A project manager who was very knowledgeable in contracts administration resigned from the company. I was afraid that the client would be upset about the loss in business expertise. Surprisingly, the client manager told me that it was just as well. The client manager said that the project manager had reached a point where she thought she knew as much as the client. She often made decisions on behalf of the client that, in many cases, were not correct. The client manager told me she was just as glad to get a replacement who was not as “knowledgeable” and would ask questions when the need arose.
The bottom line is that project managers with good business knowledge are normally huge assets. However, when project managers place themselves in the role of their clients, they stand to become liabilities for both their teams and their clients.
Tom Mochal is president of TenStep, Inc., a project management consulting and training firm. Recently, he was Director of Internal Development at Geac, Inc., a major ERP software company. He’s worked for Coca-Cola, Eastman Kodak, and Cap Gemini Ernst & Young. Tom has developed a project management methodology called TenStep and an application support methodology called SupportStep.