Chapter 15: Lessons Learned

 < Day Day Up > 



Before your project team disperses and those fond memories fade, it is standard practice for the project manager to facilitate the "lessons learned" exercise. I do not know how often this happens in reality, other than my own experience in which the frequency is low. This is partly because the employees move on to new assignments and consultants head out to new environments. Still, a wealth of opportunity for personal and professional growth can be realized by spending time reviewing the project from the simple perspective of "how could we have done things better?" This process should not to be confused with rehashing the more glorious or silly moments over beers with your buddies. Instead, this should be treated with the same honesty and sense of urgency as the other key tasks you sweated out during the life of the now expiring initiative.

Why? Well, unless you just won the lottery or joined "project manager's anonymous," you will live to guide more extravaganzas. That said, now you would do well to reflect back on the chaos while it is still fresh in your mind and before it transforms itself into a useless war story.

15.1 How do People Learn?

A few years ago, my boss and I were looking to temporarily augment our project office with a senior project manager. It had gotten to the point that we could not keep our arms around everything. I certainly felt like I was trying to capture greased pigs. We sent a clear list of desired attributes to several agencies and reserved a whole day to interview the candidates who seemed worthy of consideration.

Amazingly, one of our questions stumped the candidates, namely: "Is there anything about your most recent project you could share with us in terms of things you did extremely well, things you now wish you had done differently, or anything else you learned?" Neither my boss nor I thought this question was particularly tricky or cruel, even if it was intended to get a peek at the individual's character. We wanted to make sure that whomever we hired was a conscientious self-starter, someone who could be trusted to ferret out issues and react appropriately. In other words, we wanted to engage someone who did not require much oversight. Anyway, to our amazement, four of the six interviewees tap-danced around this question without answering it, whereas the other two stared at their shoes so long we had to suppress our own embarrassed laughter.

Obviously, it was not fair to conclude, based on their nonresponsiveness, that none of these people had ever learned anything during their careers. To answer the question fairly, each of them would have had to admit to mistakes and other imperfections, which admittedly is not common practice in the job interview situation. Still, one has to wonder how much people really do learn in the workplace or if most people recycle experience without really questioning how things could be done better next time. It is my contention that project management is somewhat ritualistic, meaning that a great deal of the job never changes from project to project. If this is true, it stands to reason, then, that one should assess one's performance to see what kinds of tweaks to approach and demeanor could hopefully lead to better results in the future.

I certainly am no expert on how people learn, but I have some ideas worth considering. As my grandfather used to say, "Anyone can make a mistake, but it takes a knucklehead to repeat it." Surely, cognitive psychologists have a far more elegant way of putting this, but in essence we learn because we want to avoid repeating previous hardships and believe we can find ways to do just that. One of the most painful but simple ways to accomplish this is to review past incidents, especially the more unpleasant or messy ones, and ask the following "did I ..." questions:

  • Make things worse by something I did or said or failed to do or say?

  • Miss a harbinger of trouble and therefore suffer the consequences?

  • Articulate my expectations effectively?

  • Not ask for clarification to avoid looking dumb?

  • Listen and react professionally to negative feedback?

  • Misread a situation as "not my problem?"

  • Spend enough time and energy preparing for an upcoming event?

  • Correct a hastily made decision upon further reflection?

The answer to these kinds of questions can provoke some very interesting dialog - even if it takes place in front of the mirror in the absence of witnesses. Be fair and remember that no one, not even you, is perfect and that past actions or reactions taken out of context can look worse in retrospect than they deserve to. Still, we must be willing to accept those indelicate moments as real stinkers and ask of ourselves, "what's up with that?"

Before getting too carried away on the personal front, however, let us take a look at how you should orchestrate a meaningful lessons learned exercise for your team. To do that, you first need to establish some goals, before engaging the team. Obviously the nature of the project will shape the dialog and the document that should emerge from this process. Lessons learned for a project focused on the development, integration, or roll-out of a singular system will be far more detailed from a technology perspective than a project that had multiple deliverables, diverse beneficiaries, and few universal dependencies. In my own experience, this latter project type includes building a corporate campus, integrating a monorail system with a commuter railroad line, and Y2K.

The difference between single- and multideliverable projects from a lessons learned perspective is that the project manager and team leads assigned to the multideliverable project interact differently than when everyone is focused on a single thread. From a project manager perspective, the delta is somewhat akin to the contrasting duties of coaching a team versus individual sports:

  • A team sport coach (e.g., field hockey or football) is similar to a single-thread project manager focused on coordinating everyone all the time.

  • Multiple deliverable projects require an approach more like that of a tennis or wrestling team coach who has to worry about each team member's "issues" to ensure that in the end the team succeeds, because success in this case is an aggregation of mostly unconnected, individual performances.



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net