Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Fred Brooks

When Project Managers can be dangerous


When project managers can be dangerousAs Project Managers we are in the business of control and order. We are placed in a position of trust to achieve the desired outcomes. Most actions we take usually reflect this. The other day I was nearly caught out by something and was rescued by my architect. The worst consequence would have been some lost time in discussion. That made me think, can project managers be dangerous on projects sometimes? I think yes. Here are my top 5.

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.

I’m sure there are many other ways we can compromise a project. I would be keen to hear your thoughts.

Image Credit: http://www.techweekeurope.co.uk

5 Questions every Project Manager must ask


5 Questions Project Manager must askProjects are inherently risky endeavours and require plenty of shepherding to ensure successful completion and the desired results. Key to successful project management is clarity of understanding on what you are trying to deliver. It is easier said than done. Different people can read the same requirements and have different impressions of deliverables. I’ve been thinking about some of the strategies I have used and seen successfully applied. Following is a set that I have found very useful. I find asking some, if not all of these questions consistently gives me best chance of success.

Q1: Can I focus on outcomes rather than outputs?

Most projects in my experience are too preoccupied with delivering the outputs. Predominant procurement methods are partly to blame for the culture of judging project success by its outputs. For example, an output may be a new software but the desired outcome is faster processing of orders. No one has monopoly on good ideas. In many instances requirements are gathered prior to projects starting, where assumptions fail on first inspection. Ask yourself if you have the ability to go back to the stakeholders if you were faced with such a scenario. If it is output that you must produce regardless of outcome, then your chances of success are low. On the other hand, if you know what the desired outcome is, you can articulate why a particular option may have more merit than another.

Q2: Do I have enough sponsor involvement?

I see plenty of projects languishing with project managers struggling to get buy in from various stakeholders. Any organisation is a political one by nature. There are stakeholders with various views. Some may have been keen to undertake the project; others may not have been so enthusiastic. Organisations have to prioritise their portfolio and you may require contribution from those that had their projects or ideas passed over. If you try to manage your way out of that, there is little hope of success. This is where involvement of your sponsor is key. They are usually in a position of authority to ensure cooperation, provide you with strategies to work within the organisation and remove obstacles before they become showstoppers.

Q3: Am I working to artificial deadlines?

I see many instances where projects are running to particular deadlines not because of level of effort required, but because someone in management has undertaken to have the outputs delivered at a certain date. Fred Brooks Jr, father of IBM/360 is one of my favourite authors. In his book “The Mythical Man Month” he gives a great example – It takes nine months childbirth. You can put nine women, you’ll get nine children, but it’ll take you nine months (paraphrasing). The effort is what it is. If artificial deadlines are to be met, it must come by trading off scope in the project. Simply throwing more staff at it does not solve the problem. In some cases you may be able to reduce elapsed time by throwing more resources. But beware, what takes one person 100 hours, will not be delivered by 100 people in one hour. There is a cost of communication and coordination.

Q4: How am I going to transition the outputs to the business?

So you have a set of outputs from the project … process, software, document, building … whatever these may be. Now what? The only way the customer can achieve any benefit out of these is once you have transitioned these into the business. I see many projects leaving transition planning to the end. That is always too late. The end of the project is usually a swarm of activity, many planned, many unplanned but necessary. You need to have planned your transition up front. Organisations have various levels of change appetite. You need to consider if you can take a big bang approach or need gradual transition into service.

Q5: What does my gut say?

If you are an experienced project manager, then trust your instincts. Our brains are programmed to catch patterns. You may get a feeling that something isn’t quite right. I have seen project managers ignore that if they have not been able to verify if there is indeed a need for concern. By the time they have realised what it is it is too late. If your gut tells you something is wrong, stay at it. Until you find out what it is. Have a method that you apply to it. Go through your risk register, deliverables, product descriptions, milestones. At first if you don’t see it, stay vigilant. Ignoring it is just about the worst thing you can do.

There are bound to be plenty of other questions that you should ask yourself. What is your list?

Image Credit: All-Free-Download.Com

%d bloggers like this: