Monthly Archives: January 2015

Closing the Project: 10 Ways to Embed Lessons Learned in the Organizational DNA

The value of the project lessons learned process is to transform information into actionable knowledge to improve the outcome of future efforts.   If we do not apply the lessons to future work, then little has been achieved.  Furthermore, embedding the lessons into the organizational DNA is necessary for our project organization to mature.   

In October, I published “Closing a Project: Ask the Right Questions.”  In that blog, I presented two techniques for effectively eliciting lessons learned during the project review.  In this blog, I will share 10-ways to embed lessons into the organizational DNA:

1.       Have a meeting where all recently completed projects are reviewed.  This ongoing meeting should be held on a regular schedule. A regular cadence sets the tone that this process is a part of the organization’s culture.   

2.       Include all project delivery teams in the meeting.  The expectation should be that all teams contribute to and are invested in the process.  The project management organization can facilitate the meeting as a shared service to the development organization.

Ideally, the meeting would include managers and leads from the business, requirements, project management, portfolio management, development, and testing organizations.  Initially, it may be best to start with the PM and development teams, or a similar pairing. It is easier to establish the pattern and rhythm with a smaller group, and expand as the process matures.  

3.         Create a simple one-page template for the project team to complete and use when presenting their lessons learned.  Keep the template focused. The goal of the template is to help the team distill and crystalize their thoughts. I have used the following template.

Project Lessons Learned Template

4.         When the team presents their slide, set the expectation that they are delivering their “elevator pitch.”  Remind them to be BLUF (bottom line up-front).  I challenge people to articulate their pitch in 25 words or less.

Clearly articulating the lesson and delivering them is the most important step.

Once, one of my project managers got so mired in the details of the project that his contribution was lost.  I helped him restate the lesson so the value was clear:  “We eliminated the overlap in testing between system and user testing.  We got the project quality office and stakeholders to agree.  Consequently, we reduced the duration of a monthly maintenance release by one week (25%) and the cost by $ 12K (10%).”

5.       Time box each presentation. This keeps the meeting moving and forces the presenters to focus on honing their message. 

I generally set the time limit for each presentation to 2 minutes.  Time boxing helps the presenters develop better oral presentation skills. Also, we are frequently deploying 10-15 projects per month so we need to have a quick tempo both to review all of the projects and keep everyone engaged.  

6.        Have the leaders in the organization attend the meetings.  The presence of the leadership has three benefits:

  • Reinforces the importance of the program.
  • Provides team members with exposure to their leadership.
  • Gives the leaders direct and clear visibility into their teams’ experience. 

7.         At the end of the meeting have the facilitator summarize and articulate 3-5 key points or themes.  The attendees will be exposed to a lot of information and this recap helps distill information and lock the learning in memory.  

8.       Over time, develop and maintain a list of the themes and lessons that need to be embedded into the organizational DNA.  These themes should be listed in the first page of the deck.  Reviewing the key themes reinforces the message. 

9.        Build a repository of the lessons and encourage the teams to review the lessons as they begin new projects.   Also have managers periodically review the themes in their staff meetings.   

Building a well used, vibrant repository is the hallmark of best practices.  Achieving this level of maturity is a significant challenge.  Many organizations focus on the tools and technology.  The key is building a culture where teams actively use the repository; and where members routinely maintain the content. 

10.       Develop a culture of storytelling where the team members share their experiences.   Humans learn through storytelling. Ancient civilizations used stories to pass learning from one generation to the next.   In learning organizations, the stories are shared in break rooms or over a cup of coffee.  These interactions are critical to embedding the lessons into the organizational DNA.

Having experience with literally hundreds of projects I often provide guidance to my project managers through storytelling.  For example, when involved in requirements gathering I share many examples of over-engineered processes that are disabled as soon as the application meets its first users. 

Finally, set the expectation that building a learning culture is a long-term commitment.  While the processes and tools can be implemented quickly, building a vibrant and sustaining environment will take several years.  Gains will be realized in the short-run; but embedding learning into the organizational DNA takes time, focus, and effort.  If managed as an organic movement, the cost is low and the payoff is high.

Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service – if this is your content and you’re reading it on someone else’s site, please read the FAQ at

PM Blog: Project Practitioners

Infographic: See How Much Work Got Done in 2014 With LiquidPlanner


Check out your productivity!

If you used LiquidPlanner last year to manage projects and resources, you’re part of a community of very industrious people. With 2014 in our rear view mirror, we looked under the hood of our project management software to get all the juicy data points. From projects created and completed to the number of work hours and comments generated—check out these impressive figures. (Click to see a larger version.)


Related stories:
See How Much Work Got Done in 2013 With LiquidPlanner
5 LiquidPlanner Features That Make Your Team More Productive
5 Key Ways LiquidPlanner Helps You Manage Your Resources

Article Name
Infographic: See How Much Work Got Done in 2014 With LiquidPlanner
See how much work you completed in 2014 using LiquidPlanner.
Infographic: See How Much Work Got Done in 2014 With LiquidPlanner was last modified: January 29th, 2015 by Alison Meier

Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service – if this is your content and you’re reading it on someone else’s site, please read the FAQ at


Scrum User Group of South Africa: Join the SUGSA Committee

Enjoy SUGSA events, want to get a bit more involved?

Why not join the committee? Nominations for the 2015 Cape Town SUGSA Committee, are now open to all SUGSA members.

We promise you dinner and drinks with international agile celebrities (when they come for our annual event), highly entertaining committee meetings, an opportunity to be part of a great team all passionate about building a great community, a chance to organise a world class events, your name and photo on our fantastic website :)

All we ask in return is commitment for 1 year to working as part of a team of 7 people to organise monthly events, an annual conference, a great website, and any other new ideas people have to enrich our community.

You can expect to spend about 1-2 hours a week on committee business during normal months, with a peak of about 4 hours a week for the 3 months around the annual event.

If you would like to nominate yourself to be on the committee, please forward a picture, short bio, and statement about why members should vote for you to before 7 February 2015.

After 7 February, the list of nominees will be posted on our website, and voting will take place electronically leading up to the March monthly event. Each SUGSA member is entitled to vote. The committee will be chosen based on the 7 nominees who have received the most votes. The new committee will be announced at the March SUGSA event.

Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service – if this is your content and you’re reading it on someone else’s site, please read the FAQ at

Scrum Planet – Agile Software Development Project Management Feeds aggregator

Microsoft Office 2013 Excel Chapter 2 Project B


Uberize the project team

To add to the lexicon of project management we now have:

  • To be uber’ed
  • To uberize
  • Uberization

Say what?

In an interesting essay, we can now see ahead to the uberization of many technical tasks, to wit: any time work can be put in finish-to-start segments, we can hire the expert-of-the-moment to do them. It’s much more flexible than contracting for an independent for an extended term, like life-of-the-project.

Oops! Did someone say ‘finish-to-start’? Isn’t that what project schedules are all about?

Is this the uber’ed PMO:

“Just as Uber is doing for taxis, new technologies have the potential to chop up a broad array of traditional jobs into discrete tasks that can be assigned to people just when they’re needed, with wages set by a dynamic measurement of supply and demand, and every worker’s performance constantly tracked, reviewed and subject to the sometimes harsh light of customer satisfaction”

Farhad Manjoo

OMG! We’re just getting around to figuring out where robots fit into the project, and now comes uberization. One can only wonder how the PMBOK of 10 years hence (10 years? perhaps five!) will be written.

Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service – if this is your content and you’re reading it on someone else’s site, please read the FAQ at

Musings on project management

Documenting diversions or delays from a schedule?

Documentation is a Communication Aid

Where is information such as deviations to be documented?

There isn’t a single answer for this, as it depends on what you’re trying to document and the purpose of the communication. Deviations from a plan might even be documented in multiple places, and sometimes in different ways, depending on what you’re trying to communicate and to whom. For example:

  • Deviations that result in schedule risk probably belong on the Project Risk Log.
  • Deviations that impact budget probably belong in an information radiator such as a bi-weekly budget report.
  • Deviations that affect scope or quality should be communicated with stakeholders in whatever report or communications format project status is usually used to share with that group.
  • Deviations that impact the project team, or (perhaps more importantly) downstream project teams or matrixed resources, should be shared through updates to start/stop or lead-time estimates, as these deviations may have a direct impact on their schedules, budgets, and estimates.
  • Deviations that can be mitigated should be communicated through updates to the project plan.
  • Deviations that can’t be mitigated should be communicated to upper management for strategic decision-making.

The general theme of most of these items is effective communication. If there’s a problem, be transparent about the nature and (if possible) the root cause of the problem so that the organization can take the appropriate steps to fix things, or at the very least not be surprised by sub-optimal outcomes if they are unavoidable. Burying the critical input needed for strategic decision-making is a sure path to project failure, so don’t do that!

Note that some deviations are also simply an expected outcome of normal variance. If that’s the case, these routine but acceptable deviations should be reported as such through the project’s normal communication channels. A good project manager never covers up deviations from plan, but also doesn’t cry wolf when such deviations are within acceptable tolerances and when the project plan has been properly built with sufficient slack to absorb expected variation.

Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service – if this is your content and you’re reading it on someone else’s site, please read the FAQ at

Recent Questions – Project Management Stack Exchange

The LiquidPlanner Blog: Q&A With Marta Langland, LiquidPlanner’s Customer Support Specialist


Marta Langland joined our Customer Success team—bursting with talent these days—and she’s already making her mark. An active learner with a lot of energy, Marta thrives on taking her knowledge and paying it forward with purpose. Read on to learn her routines, influences and hobbies.

Marta LiquidPlanner

LiquidPlanner: Briefly describe an average work day for you at LiquidPlanner:

Marta: I help our customers maximize their usage of LiquidPlanner so they can get the most out of the product. This means I help them learn the product, answer their questions and troubleshoot issues.

How did you know LiquidPlanner was the perfect fit for you?

I was intrigued by the product,  and wanted a customer-facing role. I also knew that LiquidPlanner had a reputation for being a great place to work. Then I came into the office and everyone I met was warm and knowledgeable. The values of the workplace just seemed to fit.

How do you stay productive and focused during the day?

Jumping out of my seat for a minute to refresh my brain, grab a snack or re-up on tea.

What do you appreciate the most in your co-workers?

Everyone has been so supportive as I learn the role. I feel motivated by the work and the ideas that come from my co-workers.

Do you have a ritual or routine to the start of your work day?

NPR in the car with olive bread toast and tea!

Your idea of happiness at work is:

Collaborating with co-workers to solve problems; constant learning, and feeding a positive environment.

What book has most influenced your career?

I can’t think of a specific book, but most recently I’ve been influenced by listening to career-related TED talks.

Interview tips for anyone looking for a job right now?

Research the company you’re applying for, and talk not only about your past experiences but also how those experiences will relate to the role you’re seeking. Connect the dots!

A few things you do outside the office?

You can find me gardening, spending time with family, hiking, skiing, dancing or knitting. I usually have a live music show in the pipeline (to ensure there is said dancing).

Related stories:
What’s It Like to Work at LiquidPlanner?
Q&A With Allison Wilbur, LiquidPlanner’s Customer Support Specialist
Q&A With Lilly Kashfia, LiquidPlanner’s Office Manager
Q&A With Greg Bennett, LiquidPlanner’s Product Marketing Manager

Article Name
Q&A With Marta Langland, LiquidPlanner’s Customer Support Specialist
Meet LiquidPlanner’s Customer Success Specialist, Marta!
Q&A With Marta Langland, LiquidPlanner’s Customer Support Specialist was last modified: January 30th, 2015 by Tatyana Sussex

Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service – if this is your content and you’re reading it on someone else’s site, please read the FAQ at

Software Project Management Planet aggregator

Critical Ghost bug could haunt WordPress and PHP apps, too

Add PHP applications and the WordPress Web platform to the list of wares that may be susceptible to the critical Linux vulnerability known as Ghost.

As Ars reported Wednesday, the flaw resided in a variety of Linux distributions, including Centos/RHEL/Fedora 5, 6, and 7 Ubuntu 12.04, and possibly other versions. The buffer overflow made its way into those distributions through the GNU C Library, specifically in its gethostbyname() and gethostbyname2() function calls. The bug made it possible to execute malicious code by sending malformed data to various applications and services running on vulnerable systems. Proof-of-concept attack code was able to exploit the vulnerability in the Exim mail server, and researchers widely suspected clockdiff, procmail, and pppd were also susceptible.

Now, researchers from security firm Sucuri have expanded the list.

Read 2 remaining paragraphs | Comments

Ars Technica » Technology Lab

Organizing and Sharing with OneNote, Part 1

Organizing and Sharing with OneNote, Part 1 | | Phone: (888) 381-9725 Note: This video is property of Microsoft and/or was co-produced with Microsoft. * SharePo…
Video Rating: 0 / 5

SQL Kinection - Control SQL Server 2012 with gestures using Microsoft Kinect!

Sachin Patney and Aswath Krishnan from the SQL Server Engineering Team demonstrate SQL Kinection, an experimental project that allows you to control SQL Serv…
Video Rating: 4 / 5

Plan to Replan

Need a simple project management software to manage your team?
Check-out our valuable and unique Top 15 Web Applications 2015.

keep-calm-and-replan-the-planPlan to Replan: A Project is What Happens to You When You’re Busy Making Other Plans

Project planning is the process of organizing tasks and activities to achieve a certain goal or outcome. In addition to creating the plan, project planning is also involved in the maintenance of that plan.

Planning is typically done at the beginning of each project and its goal is to create the best plan possible using all the information available at the time. It is essential during this period to get inputs from subject matter experts, team members and from others who have been involved in similar projects.

During this phase, the team must first decide and agree on the intent of the project, what needs to be achieved, the deliverables and the scope of the project. Often times, one large goal is broken up into small manageable pieces, and it’s up to the planning team to decide and estimate how much resource and money is needed and how long it will take to deliver this project. This is also the time when the team determines whether the organization has what it takes in term of time and resources to deliver on the project goals.

Unfortunately, what often happens once a project plan is baselined is that any change to the plan is viewed negatively. Change is viewed as a compromise and is seen either as a failure in planning or a failure in performance. Requirement changes are ‘customers being fickle and not knowing what they want’ while schedule changes are the result of ‘ineffective project management’ or an ‘underperforming team’.

The perception is, if the planning was done right to begin with, no changes would have been necessary as all concerns would have been addressed during the planning stage. In short, any revision to the original plan is viewed as bad initial planning and bad project management in general.

The truth is, unless one is an all knowing omniscient entity, there is only so much you can know and foresee during the initial stages of a project. So much of life is uncertain, e.g. weather, changes in regulation, changes in management priorities and etc. Only when a project progresses and as events unfold, and as more information and facts become available can we begin to adjust our plans accordingly. A project doesn’t exist in a vacuum, as the landscape changes, it too must adapt or risk failing or falling short.

Since change is inevitable, there is only one solution: We should plan to replan. We should expect that our estimates and forecast are not going to be 100% correct and put in place the processes to propagate changes to our project plans as efficiently as possible with minimal disruption. We should put in place a change control management system that is designed to react to the changing circumstances in which the project operates and at the same time does not compromise the integrity and the original intent of the project being executed.

A project plan needs to be changed or updated.


There are two major reasons a project plan needs to be changed or updated. The first is that the team is not performing and the second is the team is unable to keep up with the current plan because it was unrealistic to begin with due to the optimistic forecasting and estimation resulting from incomplete information. It seems like the tendency is always to assume the team can’t keep up, but isn’t it more likely that the plan was not perfect?

Changing the Project Schedule.

As mentioned, a schedule slip may be due performance issue or an error in forecasting or estimating during planning. If it is a performance issue, it’s because the team can no longer keep up with the schedule and meet the deadlines as planned, due to of lack of effort, ability or expertise. If it is an error in forecasting and estimating, it’s because the team has misjudged the effort it will take to deliver the project during planning and it’s now becoming apparent that it is not possible to complete the project in the time that was allocated. In both cases, the schedule should be changed and updated so that it can still be useful as a planning tool.

During planning, the team is more likely to underestimate than overestimate what it would take to deliver a project. This happens because a phenomenon that is called the Planning Fallacy. It states that people have a tendency to underestimate the time it would take to complete a task, even if they have knowledge that a similar task has taken longer than planned.

Although certain portions of the schedule are critical and major milestones need to be achieved at a certain date, the rest of the schedule should not be set in stone. Things go wrong, team members fall sick, vendors deliver late, unions go on strike – the schedule needs to change accordingly to still be relevant to the team.

Adjusting the Resources.

With the exception of actual project management shortcomings and obvious team performance issues, the request for additional budget or resources is more likely to reflect the true cost of delivering the project. The planned estimates were probably off or perhaps an unforeseen event has resulted in an increase in cost.

If the additional request for budget or resources is valid and substantial, this may be the point where the project owners may want to consider scoping down on some of the project deliverables. Or they may decide to cut their losses and terminate the project altogether. Which can be a good idea, so long as they don’t fall prey to the Sunk Cost Fallacy, where a person or an organization continue on with a project having already invested a lot of effort in it, even though it may otherwise not be the most rational thing to do.

Changing the Scope.

A project may be scoped may down if it becomes evident that the number of resources that were originally planned to support and deliver the project is now found to be insufficient. Within reason, the goals and deliverables can and should be changed according to a project team’s ability and capacity.  Scope change is acceptable as long as the overarching goal of the project is not compromised. If the intent of the project is still being served, even major goals and deliverables can be revised.

Communicating the Change.

Once the management has decided on a change and it has been approved and implemented into the existing project plans, it is important that the team be informed immediately so that everyone is clear on the latest schedule, goals and deliverables. A communication plan must be in place to cascade the information not just to the management, but to everyone on the team so that everyone is on the same page, working on the same plan to deliver the same goal.


In summary, always plan to replan. Since change is inevitable, rather than resist and dreading change, a good project manager should plan and be prepared for the inevitable. Hard and inflexible plans tend to crack and break in the real world. Without compromising the original intent of the project, strive to create a plan that is flexible yet still able to deliver on all of the project’s deliverables – as per plan.

The post Plan to Replan appeared first on