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


Why Your Agile Implementation Failed

Join IIL’s virtual conference on Thursday, May 4th for more insights on Agile, Scrum, and Kanban.

By Roy Schilling

At one point in my career, I was a manager in a large financial organization.  Being tired of missed deadlines and disappointed customers, I wanted a better way to deliver – faster, better, cheaper.  I had been reading about Agile and how it had helped organizations with exactly what I was looking to solve.

My Agile journey started pretty much like everyone else – hours on the internet and a 2-day class.  At the end of the class, I was the proud owner of a certificate and had a high-level of confidence that I could implement this Agile thing in my organization.  I quickly looked for a project, formed my team and started executing – now we’re Agile!  The result, however, was something quite different from what I expected.  The team never really formed, we had personalities that didn’t work well together, people were getting yanked out of the team for “special assignments”, and a whole host of other anti-patterns which caused us to ultimately fail – and in a big way.

The reality was that I had no idea what I was doing.  I had no experience and no one to help set up the guardrails needed to keep the team (and me) headed in the right direction.  Sadly, this is a very common situation.  Lots of energy, desire, motivation, but no experience to make it work.  Training was a great start, but not enough to guarantee success.

 

I could have walked away with my failure, and declared Agile to be the problem.  “It just can’t work in my organization” is something I’ve heard far too often as an excuse for simple mistakes.  Instead, I was fortunate enough to have met someone with significant experience in the industry, who offered his help to mentor and coach me.  After spending a short time together, we got my team re-aligned, analyzed skill sets and personalities, setup team working agreements and started working with leadership to help them understand their part in all this.  In short, he got me back on track.

 

One of the most important things he helped me with was in becoming a better leader.  He helped me understand that I was spending too much time managing down, worrying about “resource allocation” and dealing with the minutia of daily activities.  I had hired good people; it was time to get out of their way, let them do their jobs and give them the support they needed to accomplish the goals they set out to achieve.  This was a major change from my management style, and one of the most difficult and important lessons I had ever learned as a manager.  Without his help, I may never have made that leap.

 

To summarize, hiring a coach taught me:

  1. To be an active listener
  2. To give my team the environment and support they need and trust them to get the job done
  3. To effectively communicate with everyone, and always find the time for face-to-face discussions (and daily stand-ups)

 

But most importantly,

He taught me how to successfully implement Agile and get everyone on the same page; how to destroy the barriers and bring a new mentality to the company as a whole.

Having a coach to help me through the transformation (personal and organizational) was critical to the success of my organization.  Without his involvement, I would likely have had failure after failure, or just walked away from it altogether.  The cost to my organization would have been significant due to those failures, and I still would have had disappointed customers.

I’ve since moved on and have become an Agile coach myself, but even with many years’ experience behind me, I still reach out to other coaches and my mentor for advice, and to share my experiences to help others as well.

If you are transforming your organization, or just yourself, take advice from someone who has already gone through it.

Avoid my mistakes – find a coach/mentor, learn from others who have more experience than you, ask for help and embrace your mistakes.


Roy Schilling is an Agile Trainer and Coach and is based in the Charlotte area.  Roy has 30+ years in IT and 16+ years practicing Lean/Agile in small to large organizations. Roy’s certifications include CSM, CSPO, CSP, ACP and ICP-ACC.