August 27, 2009

Brief tip 9: Ensure buy-in and reconfirm along the way

Wow, a new post not that long after the previous. Another brief tip coming up, which is is simply going to be worded like this:

Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on

The first part might be too self-evident, but make a mental note of the second part. It is in fact easy to forget this in the spur of the moment, and a project can often be nothing but a long sequence of hectic moments. Taking the time to involve key stakeholders, getting their opinions and buy-in (adjusting the course as required) will give you back the effort tenfold later – which may in turn contribute to more control of the hectic moments later in the project...

I think the tip is relevant on both a team level and an executive level. On the executive level, you might find yourself trying to mitigate different and conflicting interests. When this is not feasible, you hopefully have set up escalation mechanisms to get to a decision and move forward. This process also ties closely back to the second PM brief tip of managing expectations closely.

On a team level, reconfirming tasks, responsibilities and estimates are all important. This will also be a self-reinforcing loop, as team members tend to take on more responsibility when given the trust. Of course, you will have to work hard to create a context where the likelihood of succeeding give OK odds – if not the responsibility will be more like Scott Adams demonstrates for Dilbert as shown below:

I also think the principle of reconfirmation and no surprises can be used to contradict what some people seem to think about “that great final presentation of the project”: My take is that there is absolutely no point in such a “big bang" final presentation aimed at impressing and surprising the audience (often CxO-level). Share your thoughts (and software, if your project is developing any) early as much as possible, refine them along the way and deliver the final presentation knowing that the message will be understood.

August 21, 2009

Brief tip 8: Add value beyond administering

A little while since my last post. Looking back (wine, food and beaches in Tuscany and later Spain - then a surprise U2 concert as a birthday present from my wife), I can't say I got the priorities wrong. Good project management. :-) Anyway, here is another "brief tip":

As a project manager, try to add value beyond administering the project

The last year, I have completed my PRINCE2 Foundation and Practitioner certifications. In PRINCE2 there is a pretty clear advice that the role of the project manager “…is to manage, not to do”. While I see it as important that the project manager don’t loose her view of the big picture because of working on details, I actually think that it usually works better if the project manager can add some subject matter expertise or otherwise contribute beyond administering the project.

Some project managers have a technical background before being promoted to their own level of incompetence (the Dilbert Principle in all its beautiful essence). For these, taking part in architectural roles or detailed design may be a good way to be involved beyond the project administration. Others may contribute to testing, others again will have a strong hand on the business case and marketing plans.

I think you get some things for free if you as a project manager participate actively in the project (“doing”, if you will…). For instance if you take a role as a tester[2], you get project content and status under the skin “for free” that you would otherwise have actively worked to obtain.

For the team to see that the project manager is working along them (a Scrum master might very well be a developer for the most part of his time) can also be motivating and it shortens distances for communication and makes it easier for the project manager to detect problems early through informal channels.

[1] – PRINCE2 is a trademark of the Office of Government and Commerce in the UK and other countries

[2] – I do agree with PRINCE2 that the project manager should not be the same person as responsible for quality assurance though. If at all possible, it will make life easier for everyone knowing that there is two different persons filling those roles.