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.
Jerry is getting toward the end of a project to implement a set of major enhancements to one of our manufacturing inventory control solutions. The project has been a challenge, and the project team is currently overbudget and past the original deadline. This situation is contributing to Jerry feeling pressure to implement his work—perhaps too soon.
“Tom, the last few months have been a little rocky,” Jerry said. “But we’re finally getting to the point of implementation. If you had asked me a week ago, I would have said that we would be ready to go live in two weeks. However, our user testing has uncovered a couple of last-minute problems that we’re still trying to resolve.”
“When is your targeted live date?” I asked.
“We’re scheduled to go live over the next weekend,” Jerry replied. “But we have a ‘go/no go’ meeting tomorrow, since it will take us three days to prepare for the implementation.”
I asked Jerry to describe the problems.
“That is where I get nervous,” Jerry replied. “I thought we tested these changes pretty well. However, the users encountered a number of problems toward the end of testing that hadn’t appeared before. The scary thing is that we’re not sure what exactly is causing the problems.”
“How serious are the problems?” I asked.
“Well, in both cases, the entire inventory transaction was lost. If it happens when we go live, inventory quantities may become inaccurate,” Jerry said.
“What does your client think about this?” I asked.
“Actually, they’re sympathetic to the problem, and they know that it’s hard to predict and test every scenario,” Jerry said. “They say that no system is ever perfect, and they’re inclined to go ahead and implement the changes. However, they’re impatient since we have had to delay the project 30 days already.”
“I don’t know the motivation of the client or the pressure they’re under,” I concluded. “But I think you should try to get one more week to resolve this problem.”
Here we have a situation where last-minute quality problems may force a further delay in a project that has already gone over its deadline and budget. The interesting thing in Jerry’s case is that it’s the client that’s pushing to implement and the IT team that’s nervous. In my experience, it’s more common for the IT team to be overly optimistic and say it’s ready, only to encounter problems after implementation.
To start with, let’s acknowledge the client’s understanding that no solution is ever perfect and the fact that they’re willing to go live even with these flaws. In a sense, I agree with them. If we always waited for solutions to be perfect before implementation, we would never get anything into production.
But I disagree with the client’s opinion for two reasons that the client must understand:
- First, the team doesn’t understand the cause of the problems. If it knew why the transactions were being dropped, everyone could make an intelligent decision on the risks. But the cause of these errors hasn’t been determined. Therefore, there is nothing to lead us to believe that the problems wouldn’t occur again in the production environment.
- Second, there’s a risk that the errors that have surfaced are symptomatic of a larger problem that is yet to be uncovered. Since these errors never occurred before, something might have changed that would have implications elsewhere as well.
Understandably, the client wants the system changes in. But they also don’t want to have to deal with the long-term problems that this type of error might cause. My advice for Jerry is to continue to work to understand the nature of the problem and the cause. Of course, I want all solutions to move to production defect-free. But I’m also a pragmatist, and I understand that nothing is ever guaranteed. The first priority is to determine the cause of the problems. Without understanding the cause, the client cannot make an intelligent decision on going live.
If Jerry’s team cannot determine the cause today, I suggest he push for a one-week delay to give the team more time. If the implementation is successful, in three months, no one will remember the one-week delay (or the entire five-week delay from target). On the other hand, if the project is implemented with this type of error, without knowing what the cause is, the client may be dealing with additional problems and reconciliation issues months in the future.
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.