Taking the Plunge

What went well?  What can be improved upon?  What issues did you encounter?  What should we start doing?  What should we stop doing?  Who should be recognized for outstanding performance?

Who cares?

As project managers, we ALL should care.  A more important question is “What can we learn from the traditional approach to lessons learned?”  Let’s start with establishing a common understanding of the lessons learned process.

The approach I learned, twenty or so years ago, goes something like this:

• After a project has closed, not too soon after because of maintenance mode and not too long after or people start to forget details, you get everyone who had a role in the project together in a conference room and ask a few basic questions (see above).
• You take notes on all the responses and spend a couple of hours turning your notes into something cohesive and figuring out how to remove some of the negative emotion and fingerpointing (if there was any).
• You send out your notes, never knowing if anybody read them.  Any action that was needed was decided during the meeting and the action was initiated before your notes got sent out.
• You publish your notes to the lessons learned repository, never knowing if anybody will read them.
• In time, your notes get forgotten.  Nobody wants to go through multiple years of lessons learned documents.  If you’re “lucky” enough to have a lessons learned repository with search capabilities, much like Google, most people aren’t going to review more than the first few results.

Sound familiar?  I’m pretty sure it hasn’t changed much in over twenty years, for many people.  Some of you might do things a little differently.  My experience, limited as it is to anecdotal information from a couple handfuls of people in two PMI chapters and answers to questions on gantthead.com (yes, I’ve been here that long) and ProjectManagement.com, is that the biggest consistent difference is the questions that get asked. 

I’m willing to be wrong, but I’m also comfortable in my opinion because lessons learned aren’t a sexy enough topic for people to spend a lot of time or money on improving the process.  Who can name a popular and widely used standalone software package for managing lessons learned documents?

A few years ago, I was hired at a new job.  Part of what I was hired to do was to help stand up a new PMO.  As part of the overall overhaul of our processes, I looked at the lessons learned process through the lens of a lessons learned meeting:

• What is/can be effective?  Getting feedback from the team.  Identifying issues and areas to improve.
• What can be improved upon?  Identifying and using relevant lessons learned.
• What issues do you encounter?  Lack of participation.  Blame game.  Forgotten details.
• What should we start doing?  Hold lessons learned multiple times throughout a project.  Capture actionable data.  Move away from blame toward learning.
• What should we stop doing?  Dumping documents in a repository and never looking at them again.
• What should we continue doing?  Refining/improving the lessons learned process, finding the right balance between adapting the process to company culture and changing company culture to be a learning culture.

I realize this list is a little on the simple side, but one of the lessons I learned is that there is a lot of data from lessons learned meetings that is specific to the project and relevant to little else. If your project is going to be audited in the future, keep the data for as long as you need it, then get rid of it.  For a set amount of time, you might need to know who made what decisions, when, why, and how people felt about it, but the relevance and usefulness of that information has an expiration date.  It can be good to know why something broke, but once fixes are in place and processes are updated to prevent the problem in the future, is anybody going to look for that information in your lessons learned documentation?

What do I recommend?  I recommend running lessons learned more than once during a project.  If you have a phase gate approach, make it part of the phase gate.  Or you could hold them once a month.  Find the cadence that makes sense for the project.  You might not need a lessons learned meeting every other week on a two month project.  Maybe it’s not always a formal meeting, but it’s part of the discussions that take place.  It’s what you do with the data you capture that really matters.

There is often someone with some sort of requirement for capturing historical data.  Meet their needs, and then focus on actionable data.  I break actionable data down into the following categories:

1. immediate action is needed
2. action that should be considered in later phases/cycles of the current project
3. action that may need taken in other active projects or in normal business operations
4. action that may be needed in a future project

Putting this into action:

• Item 1 triggers varying responses - meetings, emails, phone calls, changes... depending on the action needed.
• Item 2 can result in changes to the project plan, with the appropriate approvals and subsequent notifications.
• Item 3 triggers notifications to the appropriate project managers/sponsors (or notifications to the appropriate person in the business) so that they can determine the appropriate course of action.
• Item 4 goes on a checklist, split into process groups or phases, that is actively monitored and updated.

Using Item 4 as an example, I'll review the checklist when I'm beginning to plan a project, and throughout the course of the project to check for changes that may affect my project. I have a curated list of items to consider, instead of hundreds of documents that never get looked at again (true story).

The checklist is reviewed, regularly, to determine if any items should be removed because they no longer apply. If it grows into a multi-page document with a lot of content that is no longer relevant, it becomes worthless. I've tried to keep mine down to under 1 page; it's never exceeded 1 1/2 pages. Since it's broken into sections (phases for “traditional” projects), you don't have to go through the whole thing all at once to make sure everything is checked off, but it is helpful when planning future phases.

That’s the basics.  I’m actively refining the process and don’t plan on having the “perfect process that never needs to change.”  What works (or doesn’t) in your lessons learned process?

Innovation and project management go hand in hand.  If you're innovating, you probably have at least one project on the burner. So, why is innovating so much harder than project management?

The easy answer is that, usually, project management is a highly structured, well documented process, whereas there does not seem to be a magic formula for successful innovation.  A project has a point at which it is done, by definition. Innovation evolves. Scrum-based flavors of Agile seem like strong candidates to use for a project management framework for innovation, but will it still look that way when you peel the onion and see what's hiding inside?

I know, the onion analogy is old, but it is appropriate, although slightly flawed. What makes it appropriate is that there is more to innovation than what you see on the surface. Each layer may be similar to the one before it, but without the underlying layers, there's not much to it.

I'm seeing a parallel between Agile and onions, now.  Please, make it stop!

My point is that, like the outer layer of an onion, an innovation effort does not stand alone.  There is a core of culture, people, processes, tools, and data that all affect a company's ability to innovate.

I'm going to borrow a concept from Agile to describe a common challenge to innovation: technical debt.  In Agile, technical debt refers to old or poorly written code that needs to be refactored in order to deliver a desired feature.  From the perspective of innovation, I am using this concept to represent systems, software, and processes that need to be changed before an innovation can be successful.  If you ignore this technical debt, you risk failure, and we're not talking about a software release, any more.

If not addressed properly, technical debt can become part of a painful cycle.  With software used in multiple markets around the globe as an example, let's say it's been several years since the last major upgrade.  The required downtime wasn't feasible because of global sales events, which is how your company earns revenue.  Your company has reached the point where the software cannot reasonably support the changes you want to make.  You either need to perform the upgrade, or implement new software.  Either way, there will be downtime. It takes close to a year, but you make the change and start innovating, only to realize that you've started the cycle over again and 5 years later you have to make the same decision; upgrade or replace your software.

The flaw in the onion analogy is that innovation is not occurring on the outside of the onion.  The growth of an onion occurs in its core, forcing the outer layers to stretch and grow.

If you're expecting me to compare the core and outer layer of an onion to IT and the Business, prepare to be disappointed.  This mindset is a factor in why some innovation efforts struggle. IT provides the business with functionality; the Business provides IT with purpose.  It should be a symbiotic relationship, where both stretch and grow together, but it is often hampered by those that view it as a parasitic relationship, both in IT and the Business.

Once upon a time, I was an IT project manager at a claims processing center. The Business was frustrated with the service not provided by IT, even though the real problem was due to software that the business forced upon IT. IT, feeling like it was performing miracles just keeping the software running, expressed that the Business could not function without IT. One day, the software crashed. Hard.  After a couple of days with no real progress, the Business began processing claims by hand.  It was much slower than normal, but they made it clear they could function without IT.

And with this adversarial relationship, it took significant time, effort, and money (to replace the software and fix relationships) before innovation could begin again.

Back to my original question, "Why is innovating so much harder than project management?"  Because it's not just one thing.  Innovation is many things happening at once.  Good project management can help an innovation effort be successful, but unlike an onion, if you're only looking at the surface, you really have no idea what else is going on.  All parties need to realize that business and technical innovation go hand in hand.  If you try and accomplish one without the other, you're missing the big picture.