Posts Tagged ‘Lessons Learned’

PostHeaderIcon Three Agenda Items for a Lessons Learned Review

Every project should be closed with a proper review of lessons learned. I’m always amazed at the tremendous amount of feedback, ideas and value that comes out of a well run project closeout review session. Regrouping the team for this one final meeting is one of the most important events in the life of the project.

The agenda for this meeting – best run as a facilitated workshop – should comprise these three items:

1 – What Worked?
2 – What did Not Work?
3 – What must we Do Differently Next Time?

Structure for Best Results

Some structure around each of these will maximize the quality of the output. For example, solicit feedback with respect to specific areas, such as:

  • Categories – Planning, Resourcing, Risk Management, Requirements, Technology
  • Enablers – Commitment, Competence, Communications (see The Fifth Law)
  • Phases – Solution Design, Development, Testing, Deployment.

This provides proper focus and balance for identifying lessons learned. Also, use of the Nominal Group Technique in the workshop ensures the optimal mix of individual contributions and team discussion.

Lastly, just capturing lessons learned is only half the job. In the spirit of ‘kaizen‘ or continuous improvement, they each need to be transformed into action items for implementation, in order to guarantee future projects will use them.

PostHeaderIcon Uncertainty is Certain (the 4th Law)

Plans are not crystal balls. They are at best a logical and reasonable perspective of the future but no more. Every project involves uncertainty and uncertainty implies risk. And there is no such thing as a risk-free project. I call this the Fourth Law of project management.

All of which has a serious implication for project managers – the need to properly account for risk. The fact that plans are incomplete views of the future means they are always at least slightly wrong. Even if we correctly identify all the tasks and activities to be performed, errors will always exist in assumptions, duration and work estimates, task dependencies and so on.

Most project managers appear to ignore most risks (witness the lack of risk readiness as evidence) . Yet threats can and do suddenly materialize. But sudden does not necessarily mean unpredictable. Experience and a little structured thinking can expose potential threats that we can get ourselves prepared for:

5 Essential Steps to Managing Risk

1 – Get Prepared

  • Determine how complex your project is and how much unmanaged uncertainty you (and the project sponsor) can tolerate, i.e. how important is risk management for your project? Then decide on the process you will use and brief your core team accordingly (risk management is not a solo effort).

2 – Identify Risks

  • Review project documentation – business case, SOW, charter, plans (WBS especially) and assumptions to seek out sources of uncertainty, potential error and change. Wear the hat of Murphy – “If it can go wrong, it will go wrong.” Remember, this involves core team members, not just the PM.

3 – Assess Risks

  • Evaluate each risk for (a) the likelihood of the risk occurring and (b) the potential impact to the project if the risk does occur. Rate the severity of each risk on these two dimensions. High likelihood and high impact means for those risks at least, response plans will be a necessity.

4 – Develop Risk Response Plans

  • Evaluate alternative response strategies. Ask these questions: How could you avoid the risk? How could you reduce likelihood? How could you reduce impact? How could you transfer the risk to another party? Could you accept the risk with a just-in-case contingency or backup plan? If so, how would it work?

5 – Monitor Risks

  • As the project progresses, risk monitoring should be a regular item on the agenda, week after week. Have any risks occurred? Are the response plans working? What has changed that might cause new risks?

These are the essentials. Large complex programs will take these steps to a very deep and sophisticated level. But even the simplest of projects will benefit from the same basic steps. Scalability, as ever in project management, is the key.

Here’s a good way to think about all this-

Ignoring project risks is the first and biggest risk to the project.

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

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 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 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)

PostHeaderIcon The 5 Laws of Effective Project Management

Over the years I’ve had the good fortune to observe, lead and coach dozens of project teams in all sorts of organizations in a variety of countries and cultures. It struck me that while we have a multitude of overwhelming specifics and references for sound project management, (think PMBOK, PRINCE2 etc.), many project managers would benefit from simply absorbing a few basic realities—or, put another way:

Universally Useful Mantras

So some time ago I started wondering if we could condense recognized best practices in project management into a simple set of guiding principles. My answer – YES, I think we can.

A few simple rules

A few simple rules

So here are my own personal mantras:

1 –  Ambiguity kills Projects


2 –  Credibility requires Detail


3 –  No Truth, no Trust


4 –  Uncertainty is Certain


5 –  Satisfaction is not Guaranteed


I believe these realities hold true irrespective of the nature or complexity of project. They reflect the strongest forces for shaping success or failure on most projects, most of the time.

I’ll be expanding and evangelizing my perspectives on each of these in future blogs… so stay tuned!