What is a Post Implementation Review? There are several interpretations of the term. We will address two sorts of review that are sometimes called Post Implementation Reviews:
Like many good ideas this one is very simple. Get the project team together for a couple of hours to focus on what has been learnt and how the next project could be done better.
Lessons Learnt Reviews are sometimes done just once at the very end of the project. Fine if the project was three months duration, but if the project was 3 years long you've long since forgotten what happened at the beginning.
So best practice is to hold a Lessons Learnt Review at the end of each stage of the project - say every 3 or 4 months.
Keep the Lessons Learnt Reviews meeting to 2 hours, 3 maximum. Ideally the whole team should attend. However, more than a dozen or so people may inhibit free expression, so in a large project each sub-team should hold a Lessons Learnt Review meeting.
Brief attendees beforehand. Ask them to think about what was done really well and what they
think could be done better next time. With some teams a "let's analyse how we really
screwed it up" approach may work, but for most teams a more positive "how can we improve things
next time" works better.
Some would advocate that the project manager should not attend Lessons Learnt Review
meetings. Why? Because team members will not confess their sins in front of the boss. Without the
boss there the things the team didn't do so well are more likely to get aired and thus
remedies considered. Take your pick.
It's all very well having an AA type session - "my name's John, I'm a programmer..." - and confessing your weaknesses, but unless remedies are crystallised the benefit is limited. Even then people sometimes identify what could be done better next time but don't actually do it any different next time.
So it's a good idea to stipulate that the output of the meeting should be an Action Plan.
That is, specific things that will be done, with names assigned and even dates. This action
plan could be presented to the Project Manager after the meeting. The Project Manager might even
ask the team to suggest what he, the Project Manager, could do better next time.
If there is a central Project Support or Project Assurance (see Project Assurance) group in place send a copy of the lessons learnt and action plan to them. They can make key learnings available to other projects.
Lessons Learnt Reviews is one of the topics covered in this free Project Management Book. The main thrust of the book, however, is to show how to run projects properly so that there's isn't too much 'learning from mistakes' at the end.
|
|
A Post Implementation Review is conducted after the project has finished and usually after the project team has been disbanded. Whereas a Lessons Learnt Review examines how well the project was done, the Post Implementation Review will typically consider
The project may have been sold to the Board on the basis of extravagant benefit claims. But were these claims realistic, are they being achieved in reality? The Post Implementation Review (PIR) would answer these questions.
Assessing business benefits, measuring running/maintenance costs and comparing original claimed benefits and costs to actual benefits and costs can require financial, business and IT expertise. So it can be difficult and sometimes time consuming to do a Post Implementation Review properly.
Is a Post Implementation Reviews worth doing? If it means better investment decisions
in the future, yes. Suppose the PIR reveals that the company's business case production and
vetting procedure is flawed and as a result the company invests in projects that appear
profitable but are actually loss making. This should trigger improvement of the project
justification procedures. For example, some organisations do not include user time as a cost
in IT projects and get a nasty shock when the PIR reveals the true cost of user time - business
disruption, backfills, work-arounds, etc. Had such costs been included in the business case at
the outset maybe it would have been obvious the project should not have gone ahead.
(And when was the last time you saw a business case that had post-cutover IT support included
as a cost?)
When a new IT systems is installed it is worth doing a User Satisfaction Survey a couple of months after cutover. Bug-ridden systems can be loved by users. Defect free systems can be hated by users.
So whatever the objective quality of the system (e.g. number of bugs) it can be interesting to assess the system's "subjective" quality. This kind of User Satisfaction Survey can help inform the business case review, as described above, and can also reveal the extent to which the system meets the real needs of the business. Conclusions reached as a result of these User Satisfaction Surveys, such as the need for closer user involvement in the business requirements gathering process, can lead to more successful projects in the future.
Post Implementation Reviews are also covered in this Project Management Book.
Why Do Public Sector IT Projects Fail?
Quality Management in Software Development Projects
The Tale of Three Project Managers
Towards a Project-Centric World
Project Management Proverbs, Saying, Laws and Jokes
So You Want To Be A Project Manager?
Project Management in the Public Sector
Can Construction Industry Project Managers Manage Software Development Projects?
Copyright M Harding Roberts
www.hraconsulting-ltd.co.uk
project completion review
post implementation review
business case audit
lessons learnt meeting
lessons learned meeting
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course