15.6 Gathering the Team Together

 < Day Day Up > 



15.6 Gathering the Team Together

Now that we have cycled through the kinds of analysis that can be useful, you are ready to pull the team together and talk this through. I promised a few do's and don'ts for this meeting, so here they are:

  • Your role. You should assume the role of teacher and mentor regarding lessons learned. You may or may not work with this unique combination of people on future projects, but you want the group to disband with a positive feeling about the benefits of teamwork. Why? Because you want those kinds of players on all your future projects. If you are not promoting the attitude, who do you expect will do so within your organization?

  • Criticizing individuals. You want to discourage personal issues from surfacing in this process. Even if it is true that Joe was always late with his deliverables, and that Maria bogged down team meetings with endless discourse, everyone already knows that, so why go there? I would never advise you to take Joe or Maria aside and "coach" them on such traits, because in today's world that can be turned against you. Therefore, you should not allow such observations to surface in your lessons learned activities either.

  • Body counts. If you have been in the big time project world long enough, you have seen attrition, planned or otherwise, from the ranks of stakeholders. Perhaps you have initiated or even been a victim of this sacrificial rite. In the end, however, the project's degree of difficulty, and any collateral damage suffered from a personal standpoint, is not fodder for lessons learned. Most project participants are drawn from the ranks of BAU employees and consultants and are thus probably unsophisticated, if not uneducated, in the mysteries of project management. So, interpersonal struggles and the sadly inevitable loss of face or employment is part of the detritus one might expect. A review thereof adds little value to the lessons learned process.

  • Criticizing the corporation. Anything beyond passing comments about the dysfunctional nature of your organization is not very productive either. Numerous project problems can rightfully be attributed to convoluted process, political infighting, or the lack of cooperation among stakeholders and BAU line functions (e.g., procurement). I can assure you that this is typical of all large organizations and, therefore, can always be assumed to cause trouble. So, instead of belaboring these issues, make note of them, if appropriate. Solicit positive recommendations regarding future reparations to such processes that can be passed along to those who might be in a position to do something about them.

  • Dreams of a better world. In a similar vein, it is important that the reality of the project world be taken into account. There is no such thing as a perfect project or the penultimate environment into which rollouts are deployed. There will always be issues with people, places, and things. That should be your expectation and that of your team as well. Part of your job is to promote a positive attitude about overcoming any such obstacles. A big part of the lessons learned exercise is addressing the peculiar aspects of this in regard to your project, and taking the "knowing what you now do, would you still have handled situation X the way you did fourteen months ago when the project was still on the drawing board?" If the conclusion is "we will never try this again!" the value of your lessons learned process is highly suspect. This is so, even if the assessment that the project was pointless is basically true. If that is true, then you face an even more interesting question (i.e., How in the world did this ill-fated idea become a funded project?).

  • Awards. Some projects are doomed to succeed. How? Everything can, and sometimes does, come together. This is particularly likely if the scope is good, funding is adequate, executives pitch in, and the team is sound. "Impossible!" you say? Actually I have experienced those conditions several times. Even in the best of times, however, the absence of good project management in these no-brainers will practically ensure self-destruction.

Throughout this book, I have been quite clear about my view that humility and self-effacement are imperative components of the project manager's makeup from a leadership perspective. It would be fantastic if your team leads followed suit. Until such time as self-promotion disappears from the workplace, however, you will probably have to combat hubris that surfaces during the lessons learned process. If something clever or heroic did occur, by all means commend the event for someone else's future use. As a means, however, of advancing the careers of you and your merry band of pranksters, lessons learned is not the right vehicle.



 < 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