Taking the Plunge

If you're reading this, you may be wondering "What kind of title is 'Taking the Plunge'?"  When I started this blog(?) almost 20 years ago, it was as I was preparing for the PMP exam, the idea being that when you find something worth doing, you jump into it and then share your experiences with others so that they can learn from your experiences.  I haven't always held true to that idea, and there have been big gaps between my posts, partly because I've been busy doing other things.  I may write about those, soon.  But first, I want to continue my experiment with GenAI.

I'm going to go a little backwards and share something I've learned from this experiment before explaining what I've done.  Working with AI has reminded me that I enjoy the act of creating much more than having a robot pump out something in a fraction of the time.  I've also learned that AI has its place - not in my creative writing, but that's okay.  Let's get to the reason we're here.

This is part 1 of 3 of an exercise in using AI to tell separate stories and then bring them together to teach a lesson, beginning with the prompt, "Speaking as a sarcastic comedian, how would you explain project management to a group of executives who have had negative experiences with project managers?"  Part 2 will ask our sarcastic GenAI to explain executives and stakeholders to a project manager, and Part 3 will bring everyone together for some bonding and mutual affirmations.  Be warned, some of the best and worst comedy has foundations in painful truths.  I'll let you decide which this is.

*****

Ladies and gentlemen, esteemed executives, gather 'round! Today, we're going to unravel the mystery of project management—a profession as misunderstood as the Bermuda Triangle and as appreciated as a traffic jam on a Monday morning.

Picture this: you're on a sinking ship, but don't worry, the project manager is here! They won't save you, but they'll document the exact time each deck goes underwater, schedule daily stand-up meetings to discuss how wet your shoes are, and ensure you have a comprehensive PowerPoint presentation on the best way to drown efficiently.

First, let's talk about planning. Project managers are like your overly enthusiastic GPS. They create a route so detailed that it includes a pit stop for every restroom and coffee shop. But when the road is closed, instead of rerouting, they insist on discussing the detour over several mandatory, but thoroughly unproductive, meetings.

Then there's communication. Ah, the art of talking without really saying anything. Our project manager sends emails—lots of emails. You’ll get updates about updates, notifications about those updates, and reminders about the notifications. By the end, your inbox will be a black hole of status reports, none of which actually tell you if the project's succeeding or failing.

And let's not forget risk management. Here, the project manager is like a weather forecaster. They'll predict 17 different disasters that might happen, create a spreadsheet for each one, and then be completely blindsided by a real issue that no one saw coming, because they were too busy mitigating the risk of a coffee spill in the break room.

Finally, there's the wrap-up phase. Imagine a grand finale where nothing works as planned, but don’t worry—there's a detailed post-mortem. The project manager will conduct a series of retrospective meetings to analyze why everything went wrong, carefully avoiding any conclusions that might suggest they, or the process, were part of the problem. And then, they’ll enthusiastically propose the same approach for the next project!

So there you have it, project management in a nutshell. It's like herding cats, except the cats are on fire, the project manager is trying to teach them synchronized swimming, and you're footing the bill for the water damage. But hey, at least you’ll have a Gantt chart to remember it by!

Thank you, and may your next project be slightly less of a circus.

Be warned, this is experimental humor.  Somebody asked "What do PMs do from a Developer's perspective?"  I asked GPT4o to help me come up with the following:

"""python
class ProjectManager:
def __init__(self, name):
self.name = name
self.team = []
self.projects = []

# Method to recruit team members and send welcome emails
def recruit_team(self, team_members):
self.team.extend(team_members)
self.send_welcome_emails()

# Method to send welcome emails to team members
def send_welcome_emails(self):
for member in self.team:
self.send_email(member, "Welcome to the team! Let's do great things!")

# Method to assign a project, schedule meetings, and create tickets
def assign_project(self, project):
self.projects.append(project)
self.schedule_meetings()
self.create_tickets()

# Method to schedule meetings for the project
def schedule_meetings(self):
print("Scheduling endless meetings...")
for day in range(1, 6):
self.schedule_meeting(f"Day {day}: Stand-up Meeting")

# Method to schedule a specific meeting
def schedule_meeting(self, meeting_details):
print(f"Scheduled: {meeting_details}")

# Method to create tickets for tasks
def create_tickets(self):
print("Creating tickets for every possible task, even the smallest...")
for task in self.generate_tasks():
self.create_ticket(task)

# Method to generate a list of tasks
def generate_tasks(self):
return ["Design UI", "Implement feature", "Fix bug", "Write tests", "Deploy to production"]

# Method to create a ticket for a specific task
def create_ticket(self, task):
print(f"Ticket created for: {task}")

# Method to monitor progress and update project status
def monitor_progress(self):
print("Monitoring team's progress and updating project status...")
for task in self.generate_tasks():
self.check_task_status(task)

# Method to check the status of a specific task
def check_task_status(self, task):
print(f"Checking status of: {task}")
if self.randomly_decide_status() == "done":
self.close_ticket(task)
else:
self.remind_team(task)

# Method to randomly decide the status of a task
def randomly_decide_status(self):
import random # Importing random module for random status decision
return random.choice(["done", "in progress"])

# Method to close a ticket for a completed task
def close_ticket(self, task):
print(f"Closed ticket for: {task}")

# Method to remind the team about an incomplete task
def remind_team(self, task):
print(f"Reminder: Don't forget to complete: {task}")

# Method to report the project status to stakeholders
def report_status(self):
print("Reporting status to stakeholders...")
self.send_email("[email protected]", "Here is the latest project status update!")

# Method to send an email
def send_email(self, recipient, message):
print(f"Email sent to {recipient}: {message}")

# Example usage:
pm = ProjectManager("Alex") # Creating a ProjectManager instance
pm.recruit_team(["Dev1", "Dev2", "Dev3"]) # Recruiting team members
pm.assign_project("New Feature Implementation") # Assigning a project
pm.monitor_progress() # Monitoring progress
pm.report_status() # Reporting status
"""

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.