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?

What does a Project Manager need to know about Project Management?

Don't worry, this isn't a job interview; it's okay to say "It depends."

It seems like, once you get past a core set of skills, there is a lot of variation, between companies, when it comes to what is expected of a Project Manager.  I've also noticed a lot of variation in what is expected of a Project Manager from different employees within the same company.  A starting point might include the following:

• Communicating effectively across all levels of an organization
• Facilitating meetings
• Documenting and managing project tasks/schedule (often using software that displays a WBS and Gantt chart)
• Identifying/managing risks and issues
• Managing project scope changes
• Creating status reports/dashboards
• Various "soft" skills

The longer you work as a Project Manager, the more important it becomes that you understand the nature of work and how it can be accomplished.  You also need to understand the culture and structure of the organization you work in to choose the best approach to successfully accomplish the work to be performed.  Here are some areas to study:

• Agile/Kanban/Lean
• Scaling Agile
• DevOps
• Waterfall (in its various forms)
• Six Sigma
• Organizational Change Management
• Project Portfolio Management
• Benefits Realization Management

As a PMP, I feel a little obligated to say that you need to know the PMBOK, but I also feel the need to point out that it is the PMBOK Guide, emphasis on 'Guide.'  There are also other approaches, such as Prince2, that may be more relevant to your career.  Knowing what is relevant to your career is more important than using the topics I've mentioned as a checklist for things you need to know.

The point of having a tool belt is to be able to know how to use the tools you need based on the situation you are in, not to use every tool you have.  So, here's a question for the rest of you - reply in the comments section - what else, in your experience, do Project Managers need to know?

Have you ever had a really good idea that you were excited about, that you couldn't wait to start, only to have it go nowhere?  I've had more than one hobby that went into limbo and became an "interest" because it was a good idea, but the timing wasn't right.  I'm sure I'll get back to one or more of them, but now is not the time.

Have you noticed that we have similar behaviors at work, often with one difference?  A good idea becomes a project and resources are assigned to it, but when it loses priority it never actually stops.  Nobody says, "This isn't a good idea right now."  Instead, people work on it when they have time, assuming it doesn't impact anything.  Don't get me started on multi-tasking… but multi-tasking isn't the only concern.  Activities involved in both testing and implementation tie up people and resources, and not just those performing the work.  A desktop software implementation can distract people working on other projects, as well as resulting in issues that can stop work until they are resolved.

This post is only partly about organizational multi-tasking and project prioritization.  It's also about efficiency, or at least the illusion of efficiency.

My work is primarily in IT, so there will be an IT focus in what I write, but I will try to tie it back to the business, as well.

IT is expected to be efficient.  It often feels like people think efficient IT means working on all requested projects and getting them all done on time and within budget.  That doesn't feel very efficient to me.  Can you see the connection to "good ideas?"

A company can have employees working on a lot of projects.  Some strategic, some compliance enabling, others required to keep the lights on, and then a bunch of good ideas.  The company can hire more people and buy more equipment to keep everyone working efficiently on all of the projects.  Eventually, however, there will be conflicts.  A natural bottleneck occurs with testing and implementation.  When you have interdependent systems, your dependencies limit the amount of separate changes that you can effectively test or go live with at any given time.  If you really want IT to be efficient, you need to insert a bottleneck in the decision-making process in order to limit the amount of work in the project pipeline to match the amount of output your organization is able to effectively deliver.  (Think of Portfolio Management as one step toward making this happen.) Over time, you may be able to enlarge the testing and implementation bottleneck, at which point, you will be able to increase the amount of work in the pipeline.

So far, we've just been talking about IT projects.  Now, consider a company, like the one I work for, that has global markets.  This means global marketing projects and global sales events that also impact the web, mobile, CRM, and ERP systems, among others.  The windows for testing and production implementations just got a lot smaller.  Should these activities be considered as part of portfolio management? 

Is that good idea you're working on a good idea right now, or would it be a better idea to work on it when it is a better fit with other priorities your organization is pursuing?  Or, not at all?  Does being a good idea automatically mean that it deserves to be executed?

I'm currently listening to The Goal, by Eliyahu Goldratt and Jeff Cox, while I commute to and from work.  I'm about halfway through it and, so far,  it reminds me of some problems we experienced load testing our ERP and sales systems.

We encountered login failures during load testing, where we hadn't before.  A little digging revealed that recent performance improvements had sped up our submit times but we hadn't accounted for the impact on other processes.  As a result, we experienced failures.  Our attempt to become more efficient made us less efficient because the improvements we made ran into downstream processes which choked due to greater volume than anticipated.

One possible interpretation of the message of The Goal is that overemphasis on efficiency when doing something can lead to ignoring the reason why you're doing what you're doing, in the first place.  You basically end up failing efficiently, but that is a little oversimplified.  A bigger concern is whether or not you are focusing on the right efficiencies.  It doesn't matter how efficient your production is if you're not selling anything.  From a software development perspective, it doesn't matter how efficiently your team is developing code if they're not delivering code that the customer wants.

From a project management perspective, are your projects helping your company achieve its goals?  A project can be on time and within budget, yet still do nothing to help a company achieve its goals. 

Don't worry, I'm not about to segue into Portfolio Management.  I could, but if you're not doing Portfolio Management now, you're not going to automagically be able to start once you finish reading this.  You can, however, examine your products with the critical eye of The Goal (with the caveat that I have not finished the book, yet).  Does your project help your company meet its goal through some combination of reducing inventory, reducing operational expenses, and increasing cash flow? 

What about you?  Have you read The Goal?  If so, what insights did you gain from it, as it relates to project management?

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.