Archive for September, 2009

PostHeaderIcon The Project Objective Statement

All projects have an objective but not all projects have a well-crafted objective statement. Its a simple and elementary thing but deceptively powerful. Creating a high level, overarching mission statement should be among the first 5 things that a project manager does with his or her core team.

Short and Sharp

An objective statement should ideally be written as a single meaningful sentence, comprised of no more than 25 words, that reflect the primary project constraints – schedule, scope, resources.  The word limit deliberately forces focus and ensures we get to the core of the project’s main objective, even if a zillion things will be worked on during the project’s life.

To re-quote President J.F. Kennedy as an example:

Put a man on the moon and return him safely back to Earth, completed on December 31, 1969, for US$531m

Call it what you will – a Project Objective Statement (POS), a Project Mission Statement (PMS – less popular), or PROject MISsion Statement (PROMISS) – this declaration is crucially important for a host of reasons:


  • It is THE stake in the ground that lays out exactly WHAT will be done, by WHEN and for HOW MUCH.


  • Securing sponsor input and involving the core team in crafting this statement ensures buy-in, commitment and a sense of real purpose. It should NOT be done by the PM alone.


  • It should be formally approved by the sponsor prior to detailed planning and re-validated again before execution begins, i.e the plan MUST demonstrate tactical viability by meeting this target.


  • It communicates an ongoing point of reference for management and the team throughout execution. The project mission changes only if explicitly required and agreed to by management.

The process of creating this statement is as important as the statement itself. Done right, it begins the development of a performing team and the resultant discussions help identify project boundaries, assumptions and issues early on. Put this as one of the first agenda items in your planning sessions.

PostHeaderIcon How to Describe a Risk

Its always amazing how small things can make a big difference in the world of project management. Consider the describing of a risk:

The Wrong Way

Oftentimes we see a ‘shorthand’ approach used – for example, a risk captured simply as “Insufficient resources”. The danger (the risk?) of such a brief description is that it creates three problems:

  • We misinterpret what exactly was meant (Which resources? On which tasks? With what consequences?)
  • We may not correctly assess the risk’s importance because of the description’s ambiguity
  • We can’t remember what we meant when we revisit the risk log at a later date

For these reasons, it makes good sense to describe a risk in a way that clearly states the possible situation and its effect.

The Right Way

A recommended approach is to write a risk like this:

EVENT may occur WHEN, thereby causing IMPACT

So rather than a bland, ambiguous risk statement such as “Lack of training, we drill down and explain clearly what is meant – maybe:

“Competing work commitments may prevent staff attending the training, thereby slowing adoption of the enhanced project planning process.”

Now its clear. We understand both the effect and its root cause. Clear statements of what we really have in mind when we identify risks promotes consensus in (1) understanding the risk, (2) assessing its importance, and (3) generates more creative thinking in the development of risk responses. A little extra effort for a big benefit.

PostHeaderIcon Making Risk Management Real

Of all the processes within project management, it would seem that risk management is the one that most often turns into a paper exercise. Lots of projects have lists of identified risks, some have plans to manage those risks but only a few properly integrate risk responses into the overall project plan.

A Small but Crucial Step

Creating risk logs and defining response strategies is a ‘non-productive use of valuable time’ if performed merely to satisfy management, increase comfort levels or just conform to company policy. Those documents will gather plenty of dust. What’s needed is for that information to become an essential component of the detailed schedule. This is a small but crucial step – and often missed.

Here’s how to do it-

  1. Once the project risks are identified, define clear mitigation strategies – i.e. specific actions to proactively (a) reduce probability or (b) minimize or alter the impact of the risk occurrence.
  2. These actions can then easily be defined as “tasks” in a verb/noun format – which means they can, and should, be added to the project Work Breakdown Structure (WBS).

In the example above, a section for Risk Management has been added to the end of the WBS task list in the Microsoft Project plan. Each of the tasks within that section is an explicit risk response activity. Each task will therefore be assigned an owner, linked into the schedule with appropriate duration and resource estimates, and then executed and tracked in just the same way as any other task in the schedule.

Now, we have made risk management real. Its an integral component of the execution plan – not a paper exercise. Remember – if its not in the WBS, its not in the project.

PostHeaderIcon The Flexibility Matrix

An important aspect of the project manager’s role is the appropriate balancing of trade-offs among the primary project constraints. In most cases this means determining priorities among schedule, scope and resources. The relative importance of these should be defined unambiguously by the project sponsor and then reflected by the PM in a matrix:

Forcing clarity on project constraints and priorities

Forcing clarity on project constraints and priorities

In the example above, schedule is deemed to have the least flexibility, meaning that everything possible shall be done to meet the target completion date, even if scope has to be compromised in some way, or more preferably, by adding resources to expedite the schedule. It is important to state WHY a particular constraint is either least, moderately, or most flexible, according to the sponsor’s priorities, with guidance on the relative limits of flexibility (so no blank cheques).

This little tool is invaluable to the project manager during both planning (in ensuring the right focus in optimizing the project plan before baselining) and execution (in guiding both the tracking effort and corrective action in the event the project deviates from the plan).

While the relative priorities can be changed by management as desired, a simple rule must be followed to prevent insistence that everything be least flexible – only ONE check allowed per column and ONE check allowed per row.

PostHeaderIcon No Truth, No Trust (the 3rd Law)

The interdependence of truth and trust is a powerful force in projects. When both are prominent, we have a strong basis for effective team dynamics – a key ingredient of project success. Overlooking, ignoring or concealing certain realities inhibits team cohesion and severs trust – as sure as the sun rises. I call this force the Third Law of project management.

Creating an environment of truth helps build trust. This means straight talk, smart leadership and attention to good process. It also means reinforcing positives and not holding back on bad news. (Pop quiz: What’s worse than giving your sponsor bad news? Answer: Giving bad news late).

15 Truth Checks

Here are a few checks to test whether important project realities are being detected, acknowledged and acted on:

  • Has a trustworthy process been used to plan and manage the project?
  • Is project progress being tracked and reported accurately?
  • Are team member status updates consistently submitted in a timely fashion?
  • Are issues being aggressively managed?
  • Are risks being reviewed at each progress review meeting?
  • Are new risks being proactively identified and managed?
  • Is outstanding performance being acknowledged, directly and publically?
  • Is under-performance being dealt with effectively?
  • Are people rewarded for behaviors that promote effective teamwork?
  • Have gaps in expertise or credibility been identified and resolved?
  • Is the team aligned with a common sense of purpose?
  • Are morale and commitment being nurtured proactively?
  • Have conflicts been acknowledged and addressed effectively?
  • Are team members executing, communicating and reporting as required?
  • Is a flexible leadership style in evidence, building trust across individuals and cultural differences?

Promoting open communication and instilling a sense of shared purpose are the starting points for any effective collaborative effort. But they need to be backed up by solid process and savvy leadership. Managing the project includes monitoring both the project and the project environment. It involves responsiveness to the unexpected in both project and human performance. Acknowledge the truth or face the consequences.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

PostHeaderIcon Eight Questions to ask your Project Sponsor

This might have been alternatively titled “Questions we are Occasionally Afraid to Ask”. Here’s the situation:

You’ve been appointed to project manage a new initiative. You know that effective project sponsorship is a critical success factor and so you set up a meeting with the project sponsor.  You want to be sure you’re starting out with the right kind of backing. The sponsor wants to discuss the budget (or maybe golf) but first, you have some big questions you need answers to…

1 – Do you understand your role?
Its a fact – many project managers I meet complain that their sponsor has little idea about their role and responsibilities. You may need to help them out here.

2 – Do you know what you want?
There’s not much more frustrating than a sponsor who isn’t sure about what should or should not be included in the project. A fuzzy sponsor means you could be in for a long road trip of about-turns – do, undo, redo, …

3 – Can I count on your support?
Or more specifically – will you truly champion our project? This means advocating the project at higher levels, helping maintain visibility and interest in the project with key stakeholders, providing adequate funding and obtaining resources.

4 – Will you be available?
No doubt about it, sponsors are typically busy executives. This means their time is limited and they may be hierarchically or geographically remote. You DO need those face-to-face meetings. Lock them into their calendar.

5 – Can you give me clear priorities?
What are the primary project objectives? Which is least flexible – schedule, scope or resources? (Hint to sponsor- you can choose only one). Which is most flexible? Why?

6 – Do you understand that project management is a discipline?
In pushing to ‘just get it done’, countless projects ignore the importance of proper planning and systematic tracking… and pay a high price. A sponsor who doesn’t appreciate this means we’re already in trouble.

7 – Do you know what a solid project plan looks like?
The sponsor has to approve the plan that lays out what will actually be done- so it might make sense to ensure they actually have an understanding of what a good plan looks like. If necessary, give them a Plan Review checklist and an ‘Executive Briefing on Tactical Planning’ (so they know a WBS from a critical path).

8 – Will you inspect what you expect?
Not much point in a sponsor’s list of expectations if the relevant questions are never going to be asked. Generating information, reports and updates that don’t get reviewed is a fast track to morale hits and trust breakdown.

If the sponsor answered these questions correctly, you’re likely to be in good shape. (Hint for sponsors- the correct answer is “Yes” to all questions). If not, then you just identified some additional risks to the project…

PostHeaderIcon Credibility requires Detail (the 2nd Law)

Most projects are underplanned. They’re already late before they start. For a host of reasons – the usual suspects include a lack of project management discipline, inadequate tools and training, unclear objectives, top-down influence, overworked and under pressure team members – projects get planned with insufficient detail.

The reality is that detail is the basis for accuracy in all projects. Plans that lack appropriate detail can’t be believed. This is what I call the Second Law of project management.

The consequence of a lack of detail is a project suicide spiral:

Understate what’s needed… Misunderstand what ‘done’ looks like… Miss stuff out… Underestimate time and effort requirements to do the work… Overcommit resources to unrealistic schedules…
Present bad news to customer.

Breakdown Checks

Without a credible plan, a project manager lacks credibility with the team and stakeholders. Only when we get to the detail is the full extent of work revealed, which means developing a great Work Breakdown Structure. Here are a few WBS must-do’s:

  • Ensure tasks are small enough so that-
    • Estimates of effort and duration are as accurate and credible as possible
    • Task durations are typically no greater than the time between progress updates
  • Define explicitly what ‘done’ means-
    • Especially for any task that is unfamiliar, complex or difficult to break down
  • Assign a single owner to each task-
    • Have them verify that the expected workflow minimizes likelihood of any missing tasks
  • Use a checklist of often forgotten tasks-
    • e.g. meetings, defect resolutions, reviews and approval cycles.

They say the devil is in the details – and just looking for a chance to cause trouble. Good process and a little extra planning time will build protection.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

PostHeaderIcon Construction Industry needs Project Management Education

When I first started in the project management services business, I was repeatedly led to believe that the construction industry was the beacon of leadership in project management maturity. My own experience over the years tended to question that wisdom and now the truth is out that this is indeed all nonsense. According to a recent survey by the Chartered Institute of Building (CIOB), which represents 42,000 members and sets standards for the management of the total building process, the construction industry has much to learn about project management.

The Shocking Truth

Not a towering force in project management

Not a towering force in project management

The survey results are based on data from 73 companies and over 2,000 projects. Its conclusions are available on the CIOB website – you can also watch an interesting video of the CIOB president Keith Pickavance presenting the results at the Project Management Asia Conference 2008. They make for a highly uncomplimentary denunciation of the state of project management practices in the industry- for example:

– more than 50% of projects reported on managed with simple bar charts and no CPM
– less than 15% used a linked network to define the schedule
– only 10% had a QA system in place to quality control the network
  • less than 15% used a linked network to define the schedule
  • more than 50% used only simple bar charts
    • (no chance of a critical path)
  • more than 50% used paper (not computerized) records
  • less than 15% kept logs of changes
    • (not much good in court)
  • 95% did not report delays to progress because they:
    • hoped no-one would notice
    • hoped they could catch up
    • did not want to upset the client
    • thought they could blame someone else.

Its not a pretty picture. Little wonder then, that the industry is dogged by delays, compensation claims and disputes.

The Way Forward

Clearly there is a need for some serious project management skills development. In the words of Mr. Pickavance himself:

We have no standards, we have no training, we have no qualifications.

All of which should be manna from heaven for project management educators, particularly in those regions where construction investment is being pumped up to help resurrect limp economies. Assuming of course that the building firms are open to changing their ways.

PostHeaderIcon Ambiguity kills Projects (the 1st Law)

Not so clear

Ambiguity is the enemy of project success. Its one of the first things I instruct new project managers on. I call it the First Law in project management.

Its not hard to find ambiguity in projects. Look closely at the objectives, the requirements, the scope definition and the schedule. Are they each as clear and as accurate as they can be? Most importantly, do we know what “done” really looks like? This is crucial. (Glen Alleman’s prolific and consistently excellent blog at Herding Cats has a host of outstanding posts on this – check it out). Each ambiguity is a potential source of conflict, rework and failure.

Clarity Checks

The antidote to ambiguity is clarity – here are a few items that must be on the ‘Clarity Checklist’:

Leaving ambiguity unchecked simply increases project risk. The pursuit of clarity isn’t always popular because it makes people have to think ahead a little harder. But its necessary. So put on your flak jacket and go on a mission – seek out ambiguity and destroy it… before it does some damage.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)