Lessons Learned and Wash Up's

Project delivered what happens next

When a project has completed there is still things to do, both for the ongoing development for the business that you are delivering for and for your own personal development.

All good project management books will tell you about the formal project framework requirements of closing a project although you will find it difficult to get engagement once a project has been completed, as the natural order is to look back rather than forward. However I firmly believe that to keep innovating you need to learn from things that don't go smoothly and to plan.

This week I have completed two different wash up activities, whilst both looking back at project delivery they serve different purposes one to help with strategic direction for a next phase of integration and the other to identify how a process improvement can be implemented better.

Executive Summary

A 2 page summary highlighting the following:

What the issues were

Solutions for the next stage

Working at this level, no need to go into detail, remember the sponsor should be aware of these issues and this is a recap. If you have kept a good RAID log through the project this activity is relatively easy to put together.

Detailed wash up

This activity brings together all the stakeholders who have been involved in the project and runs through the following themes:

Communication of project strategy and deliverable

Testing Procedure and feedback

Process Improvements

Actions to complete before fully BAU

From the wash up this week, there was an obvious problem identified as it was clear that the senior management who had signed off the change had not clearly communicated to the users what was happening and why, a vital lesson learned for my next project.

Assumptions- Be Careful

Introduction

It is important to document and get agreement of any assumptions that you make on your project, and it is absolutely essential when dealing with external stakeholders, particularly when providing professional services.

I generally find there are two types of assumptions that you need to document and be aware of resourcing and technical decisions.

Resourcing

At a start of a project there is a lot of excitement and promise of great resources that will be at your disposal which allows you to build a great project plan, however experience shows says this does not always follow through, particularly when the sponsor's next exciting project comes along.

Resource is always a big issue on any project and you need to fight hard to keep good resource.

Technical Decisions

A couple of examples here are when you are putting your business case together and for example you are offshoring some activity, you will need to document and agree that you are moving roles on a like for like basis, getting this understood and agreed early saves surprises for everyone later on.

In your technical planning you could make an assumption that your changes will be able to go into the standard release programme, change release managers are very protective of their schedule so again book your assumption in early.

Process

You can't totally guard against an assumption not being correct or agreements renegaded on, but to mitigate i carefully track the assumption agreed in a project meeting and then play them back in an email to the manager responsible, then add to them my RAID log and then perhaps more importantly check in on a minimum monthly basis to ensure the assumption still holds good.

Comments/Future Articles

It is nice to be getting a steady number of page views, I would love some comments good or bad and any ideas for furure articles