This article contains a speech originally given in London in December 2015.
Thanks for the introduction, and good morning everyone. It’s nice to be here talking to a community of my fellow project managers. It can be an interesting job being a project manager. But it’s one of those jobs that unless you have done it, or worked very closely with, you don’t really have a good grasp of what it entails. Our discipline has been a domain of huge debate over the last 10 years or so, focusing on the battle between aficionados of Agile and traditionalists keeping the flame of waterfall going.
Not long ago I published a post titled "what's the point of change management?" (you can find it on this site). In this article I want to do the same sort of thing for project management. I aim to write a third article contrasting project and change management.
On most projects thinking sooner or later turns to stakeholders. Unfortunately, it is usually later rather than sooner. Stakeholder management is regularly kicked off only when there is a problem with stakeholders.
Most organizations face the challenge of repeatedly resourcing projects, and critically allocating good project managers. A common answer is to set up a central project management team.
This can seem relatively easy, but there are pitfalls on the way to setting up a successful project management team. In this article I will look at four key questions anyone setting up a project management team must consider, and then outline the main steps in setting up such a team.
Early in my career I was volunteered, (I know that’s an oxymoron, but most of us have experienced “being volunteered”), to join a quality circle. We met on a regular schedule, discussed problems and identified solutions. Our managers kept stressing how important our quality circle was. It was interesting for a while. Nothing much came from it.
Perhaps nothing came from it because “being volunteered” was the wrong starting point. I think it did not work because the expectation of what our quality circles were going to achieve was out of proportion.
I spend my life involved in projects, programs and change initiatives. A part of most of these initiatives is doing some form of stakeholder management. The aim is to engage stakeholders in the work of the program, to get their support in achieving the program goals and in accomplishing sustained change. I have come to realise that stakeholder management is like charity. It starts at home. By ‘home’ I mean with those you are working closest to - the program team itself.
In this blog I will explain why you should take the blame for things that go wrong that were your fault - even if only partially your fault. The most common argument for taking the blame is an ethical argument. The basis of that ethical argument uses principles such as we should tell the truth and not risk that others take the blame for our shortcomings. Whilst I support this ethical argument I am going to ignore it for the time being. What I want to build on is the selfish argument for taking the blame.