Notes for Project Boards > Hail to the Project Manager!

Sooner or later we should discuss the Project Manager. This might look simple. 'Let's make him the owner of the project and that's it. Well... not so. There is some confusion about the role of the Project Manager. I could give many examples but I will not. You will have seen several of them in your own organization. It's all about responsibilities and communication.

What is the right sharing of responsibilities? This is not as difficult as its looks. One rule should be on top off mind in all discussions about the roles: 'The Project Board remains responsible for the final results of the project.' There can be more specifics to this rule like 'against a certain cost'; 'with a certain quality'; 'within certain time' and so on. However, to make this happen the Project Board should create conditions necessary to achieve the objective and check if the project remains within these conditions. Also the 'creation of conditions' is not the responsibility of the Project Manager.

But to manage the project team and the creation of the objectives on a daily basis one can hire a interim manager, in this specific case called a Project Manager. He will see to it, on behalf of the Project Board, that the project team keeps focus and remains within its limits. The Project Board however remains responsible. When this principle is taken in consideration not much can or will go wrong. Make sure it is clear for everybody in the project team.

Notes for Project Boards > What approach do you choose?

I already discussed 'What's a project'. In short: 'When everything else fails an initiative becomes a project', when there is no organization and processes in place to handle the request.

But what to do in case the requested result is fairly simple, there are few risks, planning is not essential and budget is not an issue? Or in case the request comprises of several standard requests that are interdependent? Will initiatives of this kind still require a project approach? It is clear that in those cases a complete project set up is far too much. In those cases one will need another approach. One could consider an ad hoc approach or coordinative activities to get the required result.

The question however is what do we mean when we say: 'fairly', 'few', 'essential', 'issue'. These are all relative compared to the characteristics of the organization, its environment, the growth phase and so on. A change can be simple for one and complex for another organization. Or what is now a big investment might at another point in time be considere as pocket money. Therefore one should consider the SWOT of an organization before one can decide on this. The right choice for a project approach is situational.

So, if no standard organization and processes are able to handle the request consider project approach, do SWOT analyses and decide on how stringent a project approach you will need. I will come back on approach in another posting.

Notes for Project Boards > What's the case?

Recently I joined a presentation on the Business Case by Michiel van der Molen. He wrote an interesting book called 'Waarom doen we dit eigenlijk?' (Dutch only for now meaning 'why are we doing this at all'?). A very strong appeal for the use of a business case when managing projects.

Of course it is about cost, scope, use and profit. But I was especially pleased by the importance of the reasoning behind the business case. What at all are we trying to achieve. What is the thing that matters most when making decisions on projects? To what end are we undertaking this activity? It's not to just make something, it is to achieve something.

For decisionmaking it is information to refer to. For projectteam members it is information that motivates them. It's the dream that helps everybody work in the same direction. That's why it is good to make a oneliner stating the dream of your project. It will sparkle the action and give focus in your project.