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.
A common side effects of successful project and program management in organizations is the designation of activities as projects or programs which are neither really projects nor programs.
There are three outcomes that managers in business are regularly required to achieve. I want to discuss these three outcomes, or more precisely the inter-relationship between them. I am going to use the example of projects. That is not because this is an article for project managers, but because projects provide a very clear example of the problems of trying to achieve these three outcomes simultaneously. The ideas in this article are widely applicable beyond the specific domain of projects.
The three outcomes are: meeting commitments, enabling flexibility and keeping resources 100% utilised. The main message of my article is simple: you cannot achieve all three. Constantly trying to do so is a waste of effort that misses an important opportunity.
I regularly interview and otherwise engage with lots of project and program managers. Sooner or later the conversation turns to how good they are at their job, and usually pretty soon into this conversation the response comes that they have a great track record. Their great track record is justified because they have repeatedly delivered to time and budget.
Frankly, I am usually a bit sceptical at this point.