When working on an integration project, how often do we hear, “Didn’t this happen last time?”
Remember, the definition of insanity is doing the same thing over and over again, and expecting a different result. You could say the same about many organizations’ lessons-learned process — or more aptly named, their “lessons-re-learned” process. This is because so many organizations incorrectly call the lessons-learned process a “post-mortem.” That word choice is inappropriate because it reflects a dissection mentality; a search for recrimination after the fact. It inherently poses the question, “Who caused this mess?” when what the AV company should be asking is, “How did this situation occur and what were its root causes?”
And have you ever noticed that most post-mortems take place for projects already labeled failures? And that they usually only involve the team that was on the project and maybe a couple executives — one of them from the finance department, wondering how the company could make such errors and still remain in business. The primary lesson learned using this approach is, “Hide bad news and when it hits the fan, find someone else to shoulder the blame. Or just cry, ‘It’s not my fault,’ and hope for the best.” Another lesson learned and shared by project managers through this type of approach is to avoid the documentation process at all cost. After all, no one can blame you if they can’t find proof (because it wasn’t written down).
Needless to say, this is not how a mature lessons-learned process should work.
A mature lessons-learned process focuses on the future:
- How can your company replicate the best of what you’ve done?
- How can you avoid the mistakes and pitfalls that you encountered and learn from the risks and surprises?
Remember, projects are filled with uncertainty, despite your best intentions and planning. Lessons learned need to be cross-functional and include people not directly involved in the project under review. Always keep in mind; one goal of the process is to help other people “learn the lessons” without having to painfully experience them firsthand on their own projects.
So what should a lessons-learned process focus on?
There are several key areas, not in any particular order:
Assumptions testing and validation
Were the initial assumptions you uncovered in the sales process valid? Did they change? What were the ramifications of those changes? Do you need to make changes to your documented assumptions in any current and/or future scopes of work? And where did those assumptions come from (not seeking blame; just understanding)?
The design process
Did you have a valid set of blueprints or site survey documents? Did the design reflect the stated (and implied) requirements? Were the drawings kept up to date? If the design didn’t match reality, how did you go about making the changes? And who on the client side knew about the progression of drawings and changes?
Estimation accuracy
Were your estimates within a tolerable variance range (-10% / +25%)? What are the trends across your other projects? Where are you routinely over- or under-estimating? Where are the people producing the project estimates getting their numbers? Were you able to track actual hours at a meaningful level? Were the actual hours submitted truly actual or was someone trying to skew the information to match the original or “approved” estimate? Remember, when you punish people for showing variance from the original estimate, what you’ll get back is data that looks good, but is in fact worthless — and lying on time cards is probably not one of your organization’s stated values.
Portfolio and resource management
How well did you manage the influx of new projects? Did you have adequate resources (which could include sub-contractors) to support the project? How did the project prioritization process work? Did you allow piracy among sales people and project managers to occur? When you finished, were you done but not “done done?”
Risks and surprises
How many of your documented risks came to pass? Did your mitigation and contingency plans work? If not, what could you put in place for the future? Did any surprises come up? How were they escalated and/or handled? If there were any client-facing risks or surprises, did you educate the client about their responsibilities and re-align expectations?
Change management
Did you follow the documented and communicated change management process (including using a field change order and a contract change order)? What is a smooth or onerous process? When assumptions proved invalid? What risks and surprises occurred? Did you educate the client about their responsibilities and re-align expectations via the change-order process?
Adherence to standards
Did the various professionals on the project adhere to documented standards (sales, design, procurement, warehouse, installation, production, programming, finance, project management, service)? If so, what was the result, and do the standards need to be revised? If not, what was the result, and was it due to a lack of competence or discipline, or were some people just too swamped with work to follow the process correctly? How will you remedy the situation? And if some people made mistakes, was it due to a lack of education or was it a behavior issue?
Conclusion
With these areas of analysis as a starting point, a mature lessons-learned process can pay huge dividends, especially for an AV integration company that works on a multitude of similar projects under tight deadlines. Of course, they have to act systematically on their lessons learned, addressing the root causes instead of searching for the easy looking answers.
A well-structured lessons-learned process should be viewed as a gift that keeps on giving; the lack of such as process a debilitating illness without remedies.
