Note: This post was originally published (by me) on May 22 2014 on Linkedin.  You can navigate to the original post by clicking here.

Where I now work (and in several places past), a Post-Implementation Review (or PIR) is routinely performed by the Program or Project Manager, assisted by PMO, after every reasonably-sized project has been implemented – and then the “Lessons Learned” from that effort are meticulously applied to benefit subsequent projects. At least, that’s the theory…

The PIR process – which is rarely a trivial exercise – typically seeks to identify, document and highlight several things:

1. Determine “Lessons Learned” – how can future projects benefit from mistakes made or new “best practices” that have been identified as part of the current effort?
2. Determine whether or not the project was “effectively managed” and was run according to pre-agreed standards (these tend to vary, but invariably follow the same set of precepts).
3. Determine whether or not project objectives were met and anticipated benefits were ultimately delivered.

“All good stuff” you might think. And it is. But this is where the fun begins.

When the next project is kicked-off, we expect everyone will automatically be familiar with the updated list of “Lessons Learned“, that people will actually fine-tune their future behavior to incorporate the findings and we also assume that the larger problems identified in the PIR will have been addressed as a matter of course.

We are often disappointed.

Ground-hog Day

The problem is, some of the bigger problems identified such as:

• Data Ownership / Data Issues
• Language/Taxonomy Issues
• Environment Availability/Setup Issues
• Configuration Management
• Production Support

are more than likely large enough to warrant their own remediation projects if deemed insufficient. These remedial projects rarely happen given the already full “book of work” and so the same problems tend to persist. They wreak the same havoc on project after project – time and money are invariably wasted.

Additionally, recommended behavioral modifications with regard to (for example):

• Inadequate Planning
• Discipline regarding Requirements Traceability

which would normally dictate additional training, are often overlooked. A major false-economy in my opinion.

Benefits are also sometimes difficult to gauge when only a 90% solution has been delivered. Hidden work – and hidden costs – plus antiquated systems persisting past their life expectancy – along with tactical workarounds (some manual, some automated) make an accurate benefits assessment subjective at best. Constant flux provides the real challenge.

Are Lessons Really Learned?

From my point of view, collating the “Lessons Learned” is often one of the only objectives that is ever effectively realized and this is where it gets really tragic (and interesting).

Companies spend vast amounts acquiring tremendously powerful knowledge and – despite the recommendations of every Project Management framework – then ignore it when it’s time to actually leverage that knowledge.

Would you, using some extreme examples, attempt to walk/run across the Sahara or swim the Channel without intense preparation, research and training? Not likely. So why do so many Project Managers ignore this crucial first step of discovery?

So – how do we become more effective? How do we really incorporate “Lessons Learned” and break the vicious cycle?

At a minimum, scouring the Firm’s knowledge-base or PIR Repository (assuming you have one) should be the first order of business when embarking upon any new project. If you know what you’re up against, you then at least have a fighting chance. Bake this discipline into your Project Initiation schedule and promise yourself never to short-change the effort.

What do you think? What happens where you work? Please feel free to comment.

Photos: Courtesy of Google Images

So what exactly is Project Planning? From my point of view:

“If You Fail to Plan, You Plan to Fail”

A lot of people learn about creating plans when they are mentored, self-study and/or take Project Management classes or courses. It is an essential element in any Project Management effort and without planning, most projects fail.

I have tried to get to grips with the art of planning for a very long time and it still kicks me in the pants when I least expect it – and for me, planning is an art – and not a science. You can give somebody a laptop and a copy of Microsoft Project – it doesn’t make them a Project Manager or a great planner. Skillful planning requires understanding, practice, persistence and time.

Everyone who has worked with me work knows that I am passionate about having a plan, but few understand what I think is the most important thing about the plan. It isn’t the Microsoft Project ‘Tracking Gantt’ or “Missed Milestones” report that is important. Far from it.

It also isn’t the scope, cost, resource or risk/quality profile although each of those aspects are critically important.

Realistically speaking, the plan is never fixed, it constantly moves, morphs and develops. It changes every day as understanding deepens and it requires almost constant attention if you want to get it even close to “right”.

The real value in any plan is when the people involved in the project sit around a table and understand where exactly they fit into that plan.

When people in the team appreciate the sequencing, what is expected of them and where the dependencies are, the real power of the plan is exposed.

Without this realization, it’s just another piece of paper.

Photos: Courtesy of Google Images

Note: This post was originally published (by me) on March 19 2014 on Linkedin.  You can navigate to the original post by clicking here.