When Project Managers can be dangerous

1. Know too much

This was my problem. Having come from a technical background, I thought I knew something when I only knew part of it. I enjoy keeping in touch with technology and am usually good at knowing when to shut up and let the experts lead. Usually this technical knowledge gives me a good insight to ask questions on approach, probe for weakness. On this particular occasion I could have sent the discussion on a tangent. A position of authority usually brings with it a level of credibility. If you overreach your knowledge there is a risk that people will not challenge it. Project Managers must know their limits. It always pays to have in your team that are willing to ask questions and willing to correct you if you are in the wrong.

2. Know not enough

It may sound like I am trying to have my cake and eat it too. Just as overreaching your knowledge can be problematic, so can be being totally oblivious to problems. Project Management text books will have you believe you need no content knowledge when managing projects. While that can be true, it can only succeed when you have able technical expertise on tap. That is not always available unless the project is of a certain size. The best way to build credibility with your team is to demonstrate you know what success looks like. You can only do that with some content background or the help of a very able lieutenant.

3. Project going too well

Things going too well early in a project is sometimes is just about the worst thing that can happen. It may sound counter intuitive. I have too many occasions where Project Managers get lazy and forget to pay attention to the important things – recording decisions, deviations from scope, paying attention to risks etc. Projects are risky endeavours. Experience tells us that not everything will go to plan during the project. If you have grown lazy with a good start, you can be guaranteed difficulty ahead when the worm turns. When Fred Brooks Jr, the father of IBM 360 was asked how one of his projects got to be twelve months late he responded … one day at a time.

4. Becoming rigid

There is a tendency sometimes to manage by actions rather than outcomes. Our goal is not to deliver the actions in the plan, but the outcome in the business case. Project plans must be living plans. There will often be the need to adjust course to get the best outcome. Sticking to prearranged plans will give you a great Gantt chart with beautiful baselines. Sometimes you can deliver to exact plans and deliver no benefits to your customer. Your plan must have some slack, so as to not fall over at the first risk. Allow yourself the flexibility of not using 100% allocation. Expect some sickness, administrative times, training needs for project team members. Avoid having to hand a change notice every day. Project Managers must understand the difference between being in the right and getting the right outcome.

5. Spreading chaos

There will always be an element of pressure on the Project Manager. We get paid to navigate the team through uncertainties. Sometimes progress is not what we hope for. From time to time we face unrealistic expectations from our own management or customers. There are various ways to handle that pressure. The one thing you must avoid is spreading that feeling of pressure to the project team. Even in most difficult cases if shield your team from some of the external pressures you have a reasonable chance to salvage something out of the situation. If you let your pressures on to your team, chaos will ensue.

No comments:

Post a Comment