Posts Tagged 'Proactivity'

A smart Project Update meeting technique

I was once involved in a project where the project manager did something that struck me as unusual at first, but which I came to find was quite an effective technique.

At the very start of every meeting he asked “How are things going? Do you have any feedback to give on the project?”

In the early meetings the response from the stakeholders was usually a polite “Everything seems to be going well” kind of comment, which our PM recorded in the minutes. Over the course of the project though, the feedback became richer and more beneficial, often praising the efforts of particular team members.

The value of this is significant.

  • Firstly, it opens the communication channels and lets all stakeholders know that their feedback is invited and valued.
  • Secondly, it establishes a positive atmosphere in the early stages of the project, and gives excellent opportunity for people to provide positive feedback on team members.
  • Thirdly, it allows the PM to keep a close eye on the sentiment of the project – especially if he is not on site every day to observe it for himself.

This is an excellent project management device that is really easy to implement – start asking for feedback in every project meeting and see it work for you.

Related Posts

It isn’t fine when everything’s fine

How many projects are too many?

Play the Project Management Game

Business Cases: Official vs Personal

Rock climber hanging on by his fingertips

We all know the rules about business cases:

  • A project should not be initiated unless the appropriate stakeholders accept the business case;
  • The outcomes of the business case form part of the success criteria for the project, and;
  • The project manager is responsible for achieving those outcomes.

The project manager periodically checks that the project is delivering a solution that satisfies the business case and, if it’s not, puts it back on course.

From time to time, the project manager also confirms that the reasons for the business case are still valid. If they aren’t, the project is cancelled so the people involved can move onto work that serves the business.

A project can have a couple of different business cases. It will always have the official business case, created by the business to fulfill their goals. It can also have a vendor’s business case – this is created in response to their customer’s business case and incorporates both the customer’s and the vendor’s reasons for being involved in the project.

But there’s another business case that usually doesn’t get the attention it deserves – your own.

Your personal business case consists of the reasons why you’re involved in the project, such as monetary reward, reputation, job security and/or the intellectual challenge. But like any other business case, if you’re not really clear about your goals up front, and don’t review your progress towards them regularly, you run the real risk of putting in a lot of time and effort to find you haven’t met them in the end.

As for any other business case, your personal business case serves two purposes:

  1. It gives you the ‘it’s just not worth it –I’m outta here’ criteria, and, more importantly;
  2. It drives you forward – when you’re in the heat of battle, it reminds you why you’re working so hard and putting yourself under pressure.

So know your personal business case before the project starts – be very clear about the reasons you’re involved in the project, and define your exit criteria now, before the going gets tough. Then, with regular reviews, you’ll be able to keep focused on what’s important, stay motivated through those tough times and achieve your goals.

Related Posts

How are you managing your reputation?

Play the Project Management game

Project style: Yellow is the new grey

Don't expect miracles

In a thought-provoking post on Ron Rosenhead’s Project Management blog recently, Ron talks about how ‘grey areas’ are areas of risk in a project.

These are areas where details are not well defined, information is incomplete or where no-one is taking responsibility, etc. Warning lights should flash where there are areas like this in a project – ambiguity makes bad things happen.

So should these be grey areas? Grey fades into the background and this is the last thing you want to happen to these risky areas – they should be called yellow areas. Being yellow, they’ll stand out and won’t drop off your radar.

So when you find a grey area, see it as yellow and you’ll deal with it before it starts causing you trouble.

Ron’s blog article is here.

Related posts

Standish Chaos Report 2009: Are projects failing or are Project Managers failing?

It isn’t fine when everything’s fine

Effective project managers live in the future