TechRepublic columnist Tom Mochal receives dozens of e-mails each week from members with questions about project management problems. Mochal shares member questions and the answers he provides in a column each month. IT pros often tell TechRepublic that they receive the most insight when they learn about real-life situations that other IT pros are facing.
My project manager does not have as strong of a technical background as many other people on the team. However, he insists on making many of the decisions on the specific technology and tools that we will use on the project. Many of us feel that the project will encounter major problems if we continue along this technical path. I hate to be blunt, but how can we keep the project manager from screwing up the project?
I heard a person say once that that his technical skills started to become stale the day he became a project manager. While it is certainly true that no one can be proficient in all technical skills, I think most project managers start to lose some of their prior technical depth. This should not be surprising since the project manager is now busy learning new skills, like how to plan, manage, and control project work.
I try to keep up with the IT industry as much as I can. However, I don’t have nearly the technical depth I did when I was a PL/1, IMS programmer on the mainframe many (many) moons ago.
Even if the project manager has a good grasp of the technology, it is unusual to have technology decisions made by one person. Usually, there is a process in place to evaluate different options and then make decisions on which way to go.
From your letter, it sounds like the project manager is making purely arbitrary technical decisions without input from the rest of the team. That may be the case, but it is also possible that he or she is making decisions based on some other set of factors of which you may not be aware.
Understand why the decision was made
I recommend that you have a discussion with the project manager to find out what his or her decisions are based on. I am not suggesting that you tell the project manager that he is screwing up the project. Rather, I’m talking about a rational discussion to determine what criteria the technical decisions were based upon. There are many factors that could come into play, including:
- Existing company architecture. Many times, the best technology is not used because the company already has an overlapping technology. For example, your company may have a standard database management system (DBMS). Chances are, that is the DBMS you will use, regardless of some specific reasons why another one might be marginally better for your project.
- Cost. Sometimes the company and/or project cannot afford the best technology and will go with something that may not be as strong to save money.
- Integration. Compromises are sometimes made because the best new technology may not integrate as effectively with existing technology.
- Future considerations. The technology may seem wrong today, but the project manager may be aware of reasons why it will be the better choice for the company down the road.
Discuss alternatives and implications
Once you understand how the technology decision was made, you have an opportunity to discuss alternatives if you still think your solution is more viable. You should help the project manager understand the impact of his or her decision on the project today and voice the concerns you have for the future.
You said that the project manager does not have as good a technical background as others on the team. Perhaps if you explain the implications of the technology decision, the project manager will understand your concern and agree with your alternative.
Again, the discussion does not have to be threatening. Just remember to make sure your argument is based in fact, not personal opinion or bias.
Raise a formal project risk
Next, you can raise this concern as a project risk. As such, you can formally explore the consequences of the technology decision and work with the project manager to put a risk plan in place.
This again raises visibility to what you consider to be the wrong decision and gets everyone thinking of the consequences. One of the risk contingencies may be to choose a different technology, but there may be other activities available to mitigate the risk you see so that it does not harm the project. Of course, this assumes that your project is using some formal risk management techniques. If not, your ability to raise a formal risk is limited.
Go up the chain of command
Finally, there is usually an escalation option. You can take the matter to the functional manager of the project manager. The most drastic action is to take the concern to the customer sponsor.
In either case, you need to really have your facts straight and feel strongly about the issue. Obviously, you cannot take this step lightly. But if you feel the success of the project will be in jeopardy and you’ve exhausted other alternatives, you may end up taking this route.
As a team member, you don’t have the ability to deal with this problem as well as if you were the project manager and had a concern about decisions a team member was making. I think your first obligation is to talk to the project manager and determine his or her criteria for making the decisions. Then, use the opportunity to see if you can convince the project manager that your idea is the better way to go.
If this discussion ends unsatisfactorily, try to raise the concern as a project risk. If that doesn’t work, follow the escalation path to see if people in a position of more authority will intervene.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.
Bad project managers
Project managers (PMs) are like any other employees: Some know how to do a good job and others are lucky to have one. If you’re a consultant or an IT worker who has worked with either, send us an e-mail or post your comments letting us know what made your PM good or bad. We’ll use your comments in upcoming articles.