Capturing Project Knowledge

By: Greg Bailey

As the saying goes, “failure teaches us more than success”. But when we consider the number of projects that fail, and project managers’ struggles to capture learning as they implement projects, it seems project management may be an exception.

A 2013 survey found that 50 percent of businesses had an IT project fail during the previous year. What’s more worrying, however, is that not much changed in the following three years. A 2016 survey by the same company found that the statistics have in fact gotten worse: with 55 percent of businesses reporting they had worked on a project that had failed. While project managers are clearly working hard, there appear to be systemic problems in how common issues are being resolved across the industry.

The key differentiator is that learning from failure implies learning from our mistakes. To do that, we must identify and acknowledge challenges, obstacles and human mistakes during the project lifecycle. And to do that, we must consistently capture project knowledge. Without capturing the mistakes (as well as everything else) we encounter along the way, how can we as project management professionals learn from them?

Failure is a result of mistakes 

It is highly valuable to understand how mistakes arise, so you can then do something about them. Common issues that arise include:

  • Adding more people to a late project. When a project is behind, it’s tempting to add more people to the project to speed up completion. But filling new additions in on the situation will likely take more productivity away from existing team members than will be added by new ones.
  • Overestimating savings from new tools or methods. Productivity is rarely improved in giant leaps, no matter how many new tools or methods are adopted. It is a gradual process, yet the project aims do not reflect this.
  • Insufficient risk management. Failure to proactively assess and control the things that might go wrong with a project can cause projects to fall behind and go over budget.
  • ‘Silver-bullet syndrome’. After finding initial success, project teams latch onto a single practice or new technology and expect it to solve all their problems from there on out.
  • Switching tools mid-project. Often a result of making snap decisions, the learning curve and inevitable mistakes that accompany implementation of a new tool can void any benefits when in the middle of a project.

The power of hindsight is a wonderful thing. For many project managers, they will address any problems they encountered after the project’s completion—usually by way of a project summary. The following are the most common activities and approaches Project Management organizations use to capturing project knowledge, per the Project Management Institute (PMI)® study on Capturing the Value of Project Management through Knowledge Transfer:

  • Lessons learned/post-mortem debriefings (81%)
  • Subject matter experts (77%)
  • Copying documents to a centralized repository (72%)
  • Company Intranet (68%)

Post-project debriefings are the most common form of capturing knowledge. But the reality is, by waiting until after the dust has settled to address these problems, you risk forgetting the problems themselves or how you solved them. If project knowledge is not captured or shared, you risk ‘reinventing the wheel’ and failing to learn from (and therefore repeating) your mistakes.

Capturing project knowledge through developing a culture of continuous improvement should be the ideal goal for a project manager—where your team members will proactively decide to immediately record the lessons they’ve learned or directly mention them to you. But it will take a lot of time and dedication before this becomes a reality. So how do you get started?

Capture project knowledge at all times

  • Constant improvement

In other words don’t wait until your next project to do things differently, but act immediately and plan ahead. It requires learning lessons as you encounter them. This is difficult, especially when your focus is on the project at hand. But it can be done.

  • Documenting both the positives and negatives you and your team members experience

It is the individual responsibility of every project team member to take the opportunity to learn—documenting this as soon as possible. Project Managers and team members should participate together in sessions—both during and after projects—where these experiences are reviewed to make decisions on how to improve on future and current projects.

  • Reporting and analyzing the lessons you have learned

From your failures and your successes, are the next steps you should take to implement a culture of continuous improvement. By analyzing lessons in full, you can develop practices to improve on future projects and ensure you don’t become another failed project statistic.


Greg Bailey is Vice President WorldWide Sales at ProSymmetry, the company behind the state-of-the-art resource management tool, Tempus Resource


What’s the Difference Between a Risk Audit and a Risk Review?

By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM   |   Executive Vice President – Enterprise Solutions, IIL

Don’t answer that. I already know. Not a darn thing, or at least there shouldn’t be.

In my experience, both have been used, are currently being used, and will probably always be used to mean the same thing by the many companies I’ve worked with in my forty plus years in project management. Some companies use “review” rather than “audit” because the latter scares folks.

Who really wants to be audited? No one of sound mind that I know, and I should know.

I worked for the Federal Government for almost seventeen years on some very controversial programs in Indian Country which were constantly being subjected to audits. These programs were audited by the Government Accountability Office or GAO (formerly named the Government Accounting Office), the Inspector General of the Department of the Interior, Congressional audit staff (then-current investigators from the FBI on-loan to Congress), and a host of other “interested parties.”

Their job was to ferret out “waste, fraud, and abuse” and they did their best to find all three. In all programs on which I was working, they just found “waste,” meaning we didn’t do things as perfectly as they thought they should have been done. While you could argue (in writing), it didn’t do much good. They always had the final opportunity to write their rebuttals. After all, they published the reports.

Audits in the corporate world may not be as scary, but no one likes them there either. Why put people on the defensive when all they’re trying to do is a good job under difficult circumstances? That’s why I noticed early on in corporate life, that the word review was much more popular than audit, and not just here in the United States where I live and work.

Review wasn’t just a euphemism employed by companies to hide a more unpleasant activity. PMOs and others used it to create a culture of collaboration and to show they were just trying to be helpful to the project managers they oversaw or had some accountability for.

This is why I have mixed feelings about the Monitor Risks: Tools and Techniques (formerly Control Risk) section in the Project Risk Management knowledge area in the Exposure Draft of the PMBOK® Guide—6th Edition (I know I’m getting a bit geeky on you here). I was very glad to see that the authors included a new T&T called Risk Review, but less glad to see that they retained the term Risk Audit from the 5th and current edition of the PMBOK® Guide. 

Let me explain. Essentially, they took the definition of Risk Audits from the 5th edition, took out the part about reviewing individual risk responses and placed it under Risk Reviews, and left the part about whether the project team was following the risk process under Risk Audits.

Personally, I would have left the current definition and just changed the title from Risk Audits to Risk Reviews.

What’s your view?

[trx_infobox style=”regular” closeable=”no” icon=”icon-info”]Related Courses from IIL:

Browse the full course catalogue here. 

[/trx_infobox]

LeRoy Ward
J. LeRoy Ward
is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. 


Do You Feel Lucky?

By Alan Ferguson – Approved Trainer for PRINCE2®, MSP®, M_o_R®, MoP®, P3O®, Change Management™, Managing Benefits™, AgilePM™, APM IC & APMP

Mature risk management is about culture as well as process.

In the 1971 movie, Dirty Harry, Clint Eastwood says the following lines:

“Uh uh. I know what you’re thinking. ‘Did he fire six shots or only five?’ Well to tell you the truth in all this excitement I kinda lost track myself. But being this is a .44 Magnum, the most powerful handgun in the world and would blow your head clean off, you’ve gotta ask yourself one question: ‘Do I feel lucky?’ Well, do ya, punk?”

Although this is a rather violent film, this is a perfect illustration of risk appetite. When the police officer, Harry Callahan, asked the bad guy if he felt lucky, he was only assessing that individual’s risk appetite.

So what’s your risk appetite? Are you risk averse – avoiding risks if at all possible? Or you could be risk seeking – looking for risks, thrills, when they are available. Then of course the balance in the middle would be risk neutral.

Now it’s interesting to think about one’s personal risk appetite but the concept also applies to an organization. Risk appetite can be defined as ‘the amount and type of risk that an organization is willing to take in order to meet their strategic objectives.’

Like everything else there are stereotypes – the risk averse local authority that goes from striving to provide us with services reliably, every day to failing to innovate or the financial institution that goes from sensible speculation to taking unwarranted investment risks.

When implementing, assessing, or improving risk management across an organization we can all too easily focus on the process. We put in place more precise guidance or more sophisticated risk management tools.

We often overlook the culture of risk management.

We fail to properly understand the organization’s risk appetite. Very often the organization’s risk appetite is either not written down, or if it is written down the words on paper do not truly reflect the behaviors of the people in the organization. We need to understand the organization’s risk appetite and reflect it in the way the organization manages risk.

But I think you can take this discussion a little further. If we’re talking about changing an organization’s behaviors, its culture, then we are moving into the world of change management. We can’t simply alter behaviors across your organization by publishing a new set of procedures, guidelines, or standards. If the organization is resistant to change, it is likely to have a low risk appetite. This type of organization has a very deep-seated reluctance to change.

I can play this linkage in both directions. If as a change manager, I see there is a risk averse culture, then I’m going to have to work more slowly, carefully, and sensitively on my change management initiatives.

On the other hand if as a risk manager I see that there is a low risk appetite, then I may have to use change management techniques in order to improve risk management in the organization.