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?

My working title for this post bounced back and forth between 'Translation Please!', 'Lost in Translation,' and 'The Telephone Game.'  Let me explain why knowing this matters.

I'm currently studying for the Agile Hybrid Project Pro micro-credential (I told you this wouldn't be about preparing for the PMI-ACP exam), and came across the concept "Go slow to go fast" in the recommended reading.  This was in line with what I was planning to write about, so I asked my friend, Google, for a little more information on this quote.  Google didn't have much to say about the supposed "warrior-leaders studying the martial arts," but I was directed to a related quote by Augustus - festina lente, meaning "make haste slowly."  Knowing this brings us closer to understanding the actual title and working titles of this post.

At two of the companies I've worked for, executive leadership has used motivational concepts and phrases, among other things, to help motivate employees during transitional periods.  It seems that somewhere between the message that is delivered and the message that is received, something is being lost. 

At Company A, a change in leadership brought a new slogan - "Fast Speed."  My first thought was, "What the heck does that mean?"  Things devolved from there.  On the plus side, it was memorable and received a lot of buzz, but opinions were definitely split on the effectiveness of the slogan.

Compare this with Company B, where there were eight buzz words.  Two of them stood out, for different reasons - 'Zoom' and 'Focus.'  I'll let you guess which one received the most emphasis.

It's easy to say that the burden of communication is on the person who is speaking, but let's not forget Active Listening.  Company A was a little top-heavy and it was difficult to get an answer on what was meant by Fast Speed.  Company B was less top-heavy, but there was still a little filtering taking place as the message trickled down through the organization.  What started as an emphasis on all eight slogans became perceived as celebrating the ability of individuals to Zoom without consideration for the other seven slogans.  Reality is probably somewhere in between, with plenty of Focus taking place, just not being recognized for its contribution (which can be interpreted as a demonstration of which slogans are valued more, but may not be intentional).

I have no doubt that executives and project managers often speak different languages, even if it sounds like both parties are speaking English.  Early in my career, I was asked for a project plan.  I could have prepared a killer project management plan - I had a template ready to go, with risk, cost, schedule, change, etc. management plans (a book nobody wanted to read).  What was wanted was a project schedule (WBS with a Gantt chart).  Another time, I was asked to put together a Gantt chart for someone else's project that I didn't know anything about.  After a lot of work, I found out that what was wanted was a status report with milestones and a roadmap.

Sometimes, the message gets changed between the time that it is given and the time that you receive it.  Other times, you might think you're communicating, but the words being used don't mean the same thing to all parties.  The onus of understanding is only partly on the communicator - the receiving party should also take a little time to focus and understand the message before zooming into action.  Festina lente.

In the spirit of the reason I started this blog - preparing for the PMP exam in 2008 - I’ll start this post with my latest certification path - PMI-ACP.  To quote myself from that first blog post:

“The important thing to keep in mind when preparing for the PMP exam is that just getting started is a step in the right direction.”

Fast forwarding to the present, I was recently approved to schedule the PMI-ACP exam (the application was soooo much easier than the PMP exam application), so now it’s time to hit the books, or more accurately:

• An exam prep book (I’m looking for a good one.  Recommendations, anyone?)
• An online prep-class from Udemy (we always need more PDUs!)
• Flash cards
• Practice exams

Can I claim PDUs for reading the exam prep book?  Hmm…

February sounds like a good time to take the exam, but that would put my renewal at about the same time as my PMP and annual membership renewal.  It might be good to stagger these, a little.  Once I get the exam prep book, I’ll put together a study plan and set a realistic date.

I’m thinking I’ll do us all a favor and NOT make my next several posts about preparing for the PMI-ACP exam.  It may come up, but I have a few other ideas that might prove more interesting.

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?

A few weeks ago, I was fortunate to be able to attend the Scrum@Scale certification course, taught by Jeff Sutherland and Kim Antelo.  There is a lot, from this class, that I could write about, but I'd like to focus on just one topic that I think is critical to effective Scrum, Scrum transformations, and scaling Scrum:  Product Owners.

If you have multiple Scrum teams that are working on different features for the same product, you need to scale your Product Owners.  I'll explain what I mean by that in a moment.

When you take the Certified Scrum Master (CSM) class, you learn the basics of leading an individual Scrum team as the Scrum Master (leading in the sense of a servant leader, not a manager).  When you take the Certified Scrum Product Owner (CSPO) class, you learn the basics of participating on an individual Scrum team as the Product Owner.  Neither class goes in depth into what to do when multiple Scrum teams are working on different features of the same project.   I wouldn't expect them to; it's not the purpose of either class.

You might hear mention of Scrum of Scrums in the CSM class.  If you're not familiar with the concept, a lot of people think of it as a combined standup meeting where a representative from each Scrum team reports on his or her piece of the product.  They don't go into as much detail, and they only bring up blockers that can't be addressed at the team level. 

In Scrum@Scale, the Scrum of Scrums is actually what you might call the Team of Teams.  The meeting, described above, is called the Scaled Daily Scrum.  Do you see what is missing?  If you're going to scale your Scrum teams, you need to scale your Product Owners.  Why wouldn't you have a scaled, refined, prioritized backlog, a roadmap that covers the features that each Product Owner is responsible for, and a team of Product Owners that is responsible for these things?  This is called the MetaScrum, and it is sometimes missing when a company is trying to adopt Scrum.  Without this, your Scrum of Scrums, whether you consider it a team or a meeting, will be less effective, which means you won't be delivering value as quickly as you could be.

For more information on the terms I've mentioned and how to scale both Scrum teams and Product Owner teams, please refer to the Scrum@Scale Guide - https://www.scrumatscale.com/scrum-at-scale-guide/.