Architecture Lessons Learned

“Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.” – Douglas Adams

The Project Management Institute (PMI) is the organization responsible for managing the PMP certification.  Its Project Management Book of Knowledge (PMBOK) is hailed as the go-to for how to run projects, regardless of size, industry, budget, or duration.

It defines “Lessons Learned” as “…the learning gained from the process of performing the project.”  There’s greater detail afterwards, of course, but it starts there.  By an extension of the definition, it is some collection and organization of the epiphanies experienced by the team over the course of the project…presumably put someplace for the greater good, for the benefit of Projects to Come.  On paper, it’s a valuable process that drives the ever-maturing organization forward.

In reality, it’s frequently a session where we carefully phrase complaints or excuses, take notes on which individual, team, or third party failed and how.  The team is relieved the project is finally over, and the notes are shelved and they never again see the light of day.  It’s a phenomenon I’ve observed time and time again.  Much of the potential value is shredded by the need to protect, or destroy, another team or individual.  What remains is often categorized in a way that makes it difficult to apply to any future project, and then all stored in a place that is unfindable.

Here’s how to help your organization avoid this quagmire and move forward in project execution:

Remove Blame.  This will take some diligence, but don’t let the Lessons Learned meeting turn into the proverbial blame game.  Phrase everything in terms of impact to the project.  Individuals should feel free to identify their own failures or challenges, but that’s as far as it should go; the individual contributors should refrain from speaking up if, for the issue at hand, they were not impacted and did not create impact for others.  The project’s PM (or PM team) will be best positioned to have project-wide perspective to understand all of the effects, and if others speak up where they were not involved, it can create a non-productive “ganging up” feel to the meeting.

Identify and quantify impact. Any task that deviated from expected – good or bad, shorter or longer – should be reviewed.  Tie the unanticipated event back to project timeline/budget/quality impact.  The PM should be able to articulate “Because X happened, Y was the resulting delay/acceleration,” for everything.

Meta-tag the notes, put them in a common framework, and store them in a public area.  Make them findable.  Capture each instance of deviation separately, use metadata to tag them (this is where Twitter’s hashtag approach can really be quite powerful) and agree with your fellow PMs as to where they’ll all be stored.  A SharePoint list is a common approach.

So…why?  Why go through all of this?  What’s the real value to the team? To the organization?  It’s simple:

The cathartic experience matters.  The team members will work together again.  It’s inevitable.  This is an opportunity for their pains from the project to be aired, shared, and shelved.  Without this experience, there will be a level of hesitation on everyone’s part in working with those individuals that created challenges for the project.

Faster execution can be just as bad as slower execution.  “On Time and Under Budget” is often seen as a good thing.  To be sure, if a project is late, it reflects poorly on the team.  But if it’s delivered early?  Praises are sung, backs are patted.  However, we’re professionals and we’re strategic, so let’s take a more strategic view.  Everyone’s familiar with the myth of “Tell them 2, get credit for doing it in 1” as a way of inflating one’s reputation.  Consistently coming in under budget will actually erode your forecast credibility…we’ll talk more about that in a future article.

The organization deserves to know.  Every one of these findings should be reviewed by executive sponsors and leadership.  It’s an opportunity for them to get a formal and objective summary of challenges, concerns, as well as the heroic efforts on the part of the team to keep the project on the rails.


“On time and under budget” is just the beginning! Learn more about the benefits of IT Project Management.