Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Enter the characters shown in the image.

Lessons learned, who cares?

Lessons learned, who cares?
2010-02-152013-02-11IT managementen
In order to progress, past errors shall not repeat while past successes must become an integral part of our way of working. This sounds quite reasonable I hope. However, we often do not allot sufficient quality time to learn from past experience. How can we improve in this Experience Sharing...
Published February 15, 2010 by Michel Operto in IT management

a suggested framework to gather and share experience in the Project Management area

In order to progress, past errors shall not repeat while past successes must become an integral part of our way of working. This sounds quite reasonable I hope. However, we often do not allot sufficient quality time to learn from past experience. We need short sessions in duration and dense in contents to capture the interest of other PMs and executives. We need simple documents, easy to browse through.

Only such intense communications may ensure dedicated attention to learning what went well or not on the project and enable continuous progress. Here is a simple framework I'd like to propose that is focused on project management. Preliminary work is of course to gather the lessons learned but I will not cover this in this post. And, essential is the way you communicate on these. My first suggestion is to use the wording "Return on Experience" (REX) instead of "lessons learned". You're not trying to give lessons to peer PMs or executives. You only think that they may be interested in listening to your experience. Second is in the form. I propose to build a concise presentation (15 slides max). And, as you'll see, the agenda of the presentation with a brief introduction on the project itself, followed by one page per key PM domain of competence facilitates sharing. First of all, in a project's REX session, you'll cover all aspects as the presentation is simple to follow. Secondly, you will over time be in position to build your own library of best practices by domain of competence (risk management, scope management, procurement...) across several of your projects and also best practices of other PMs. Thirdly, if you evolve in an organization that has a PMO, all REX can be classified in a collaborative tool by type of project and domain for future use and for the training of new PMs. Let's now see what the contents will look like.

Project's Business Purpose

Not all attendees or readers will be fully aware of the project you're debriefing upon. You may have invited peer project managers, PMO staff, functional staffs who were not necessarily involved in the details of the project, i.e. anyone you think will truly benefit from these lessons. So, you need to briefly (3 to 5 slides) expose what the situation was before the project started. Highlight the motivation for change, i.e. the key drivers of the project, its business objectives. Limit yourself to the major reasons in order not to loose or confuse the audience. Also, describe the expected benefits from the project (again, limit yourself to the major ones).

High Level Description of the project

Expose the scope of the project over a few bullet points:

  • Business areas
  • Key functions
  • Processes addressed
  • Stakeholders

Provide a very high-level plan (one page) to expose the main phases/steps and deliverables of the project. Give a few sizing elements so people can establish a mental reference with other projects they know or have: Budget, Effort, Timeline.

Highlights of the results achieved

What results have you and your team achieved on the project management triangle: Time, cost, contents? It needs to be to the point: on time or not, budget situation, deliverables. Move on to expose briefly what the feedback on the project and its deliverables is from different populations: Senior Management, Team, Customer. Highlight a few key issues encountered during the project.

The Project Management Domains of competence

We're now ready to enter into the real meat of the topic, i.e. the lessons learned and more specifically the Project Management ones. I suggest following the decomposition proposed by PMI® by Project Management Knowledge domain as it provides a simple and logical framework for presentation. I suggest that you start with a list of the 9 domains in the agenda of the session and highlight in a different colour or in bold the domains where improvements are most required. And, in each of the subsequent sections, please identify as much as possible the benefits linked with these lessons you learned on your project.

Integration / Planning: Plans, Meetings, Issues, Project Office processes

What did you do well and what you would want to improve in the area of planning? A few ideas and areas to consider that may or not apply to your situation:
  • Plan: Completeness, Accuracy, Timeliness of updates, Tracking, Level of detail, Communicability, Milestones and Deliverables visibility, Critical path tracking and management, dependencies
  • Team/Project meetings: effectiveness, regularity, attendance, agendas, minutes, decisions, outcomes
  • Issues Tracking: timeliness of capture and categorisation, responsiveness, completeness. Did issues hit you that had not been elevated before and therefore you never had a chance to address? or did you miss to act upon some elevated questions or issues?
  • Project Office effectiveness: Documents repository (ease of access, control, contents), Naming conventions, Physical storage, Administrative tracking (Purchase Orders, Vacations, Timesheets)

Scope

What did you do well and what you would want to improve in the area of scope management? Again only a few ideas to build upon:

  • Clarity of the documented scope
  • Completeness of documented scope statement
  • Level of details of the scope, i.e. or the project you just completed, was there anything remarkable about the scope definition piece? Something that helped to make the project a success.
  • Clarity and effectiveness of your change management process. You may want to look into number changes, magnitude of changes, impact of changes (positive ones), responsiveness, customer satisfaction with the process.
  • Efficiency: Capacity to limit scope creep, to avoid gold plating...

Time

What did you do well and what you would want to improve in the area of Time Management? Here is a quick list to start from as you think about presenting these:

  • Respect of original plans (due dates, milestones, deliverables)
  • Quality of estimates and eventually methods for estimating that worked effectively for your project
  • Management of the "buffer" or "management reserve"
  • Aggressiveness of schedule (Could we have done it faster? How?)
  • Flexibility
  • Clarity towards team members and customers

Cost

What did you do well and what you would want to improve in the area of cost management?

  • Overall assessment (on budget, below, over)
  • Reasons for positive and negative variances
  • Effectiveness of procedures put in place to track and anticipate costs variances (Purchase orders, invoices, timesheets, travel and expenses...)
  • Specific processes/actions to reduce costs
  • Corrective actions undertaken to manage variances

Quality

From a Quality management stand point, what worked and what didn't?

  • Testing processes and resources, also, quality of test plans, completeness, effectiveness if there was anything remarkable for your project in this space.
  • Integration and User tests and sign off processes
  • Interim reviews
  • Training

Resources

Along the different stages of team building, including the mix of internal and external resources, what experience can you share about Resources (People) management?

  • Build up of the team
  • Staffing of team
  • Definition of roles and responsibilities
  • Mix of external versus internal resources
  • Growing internal knowledge in case a lot of external resources joined for the project that will depart upon completion of the project while internal ones will have to provide support and maintenance services.
  • Use of consultants for the appropriate tasks.
  • Usage of contractors, Onshore/Offshore mix, Outsourcing, and this over the duration of the project inclusive of knowledge transfer at the end of the project if required
  • Performance management al along the project, at the end of each major milestone or deliverable...
  • Key contributors' retention and other project resources redeployment
  • Recognition of team members

Communications

What did you do well and what you would want to improve the area of communications?

*Communications process clarity. Was everyone clear on what to communicate when to whom? How did you succeed to do so?

  • Communications coordination, or control, or facilitation depending on the project.
  • Newsletter and Continuous communications that were key to succeeding
  • Collaboration tools used by the team
  • Customer awareness, information, readiness, as seen from the customer's eyes, with their testimonials if possible.
  • Stakeholders' management, from identification to regular communication to make them feel comfortable with the project objectives and outcome.

Risks

Is there anything specific you did on this project that helped in one or more of the 5 steps of risk management?

  1. Identification
  2. Quantification
  3. Ranking/Prioritization
  4. Risk Management plans quality and effectiveness
  5. Tracking/Reviews

It may be the way you engaged on this domain with the steering committee of the project and kept them involved all along.

Procurement

What did you do well and what you would want to improve the area of procurement?

  • Controls over expenditure approvals: This in my experience requires centralization and voluntarily rigid processes with clear rules and guidelines published upfront.
  • Timeliness of review and approval processes: in case you work at a large corporation, the time it takes to get anything reviewed and approved is usually a nightmare. So, if you found workarounds or a miracle solution, all will be pleased to hear about these.
  • Quality of negotiated contractual terms: If you came up with something smart in the contract set up or clauses that worked well for you, let other colleagues benefit from this.
  • Management of variances (Exchange rates, daily rates...). This one can be a real killer given the volatility of currencies over time, especially on a multiple years' project. I had the situation a few years back with a contract in dollars for services delivered in UK by UK resources. We would have been severely hit if we had not placed in the contract a cap on the overall local currency amount the supplier could not exceed.
  • Keeping the suppliers to approved spend levels. You'll need to keep the budget of the project within an overall envelope. So, it is critical that you do not let any supplier overspend compared to what you've approved. They need to learn that if they do (work beyond the work authorizations you delivered) they may not get paid.
  • Leveraging buyer's negotiations power: If you're in a strong position or part of a wider conglomerate that has stronger buying power, make use of it for your project. Try to understand how much overall your company (or conglomerate) is spending with the supplier and use it to your advantage.

Final words for now

Of course, there may not be lessons of returns of experience to highlight into each of these areas. So, don't make it up and limit yourself to key ones that are really worth the time of your audience and the ones you want personally to memorize for future projects.

I hope that this list will help you be successful at sharing the lessons you learned the hard way on your project so that more people care about your REX Sessions and want to hear and read about these!

1 Comment

  • February 19, 2010
    2010-02-19
    by
    Very useful and comprehensive.

Add comment

comments

  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Email HTML

  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
Image CAPTCHA
Enter the characters shown in the image.
Change the display