Taking the Plunge

In this installment of my writing experiment, let’s take advantage of GenAI's improved memory and the ability to modify the tone and perspective of GenAI.  We’re going to lose the snark and see what advice GenAI can offer to our troubled project manager, executives, and stakeholders.  Here’s the prompt:

“Taking on the role and tone of a coach and mentor, what would you say to the project manager, executives, and stakeholders to help them overcome their negative perceptions of each other?”

…and here is what our GenAI coach has to offer.

===== 

To the Project Manager, Executives, and Stakeholders:

---

To the Project Manager:

"Imagine you're leading an expedition through uncharted territory.  As the project manager, you are the guide, ensuring the team navigates safely and efficiently.  However, remember that the map is provided by the executives and stakeholders, who have a broader view of the terrain and long-term destination.

Understand that executives and stakeholders aren't just throwing obstacles your way; they have their own pressures and strategic visions that drive their decisions.  When they ask for changes or set ambitious goals, it's not to undermine your efforts but to align with broader business objectives.

Engage with them proactively.  Seek to understand their strategic vision and translate it into actionable project plans.  Communicate openly about the challenges and realities of execution, and don't be afraid to ask for the support you need.  Building this bridge of understanding will not only help you manage expectations but also foster a collaborative environment where everyone feels invested in the project's success."

---

To the Executives:

"As leaders, your strategic vision and decisions are the compass guiding the organization.  Project managers are your navigators, translating these high-level goals into detailed action plans.  They need your support and clear communication to steer the project effectively.

Recognize the challenges project managers face: tight deadlines, resource constraints, and the need to balance numerous priorities.  When setting ambitious targets, consider the practical implications and involve them early in the planning process.  This inclusion fosters a sense of partnership and ensures that the goals set are achievable and well-understood.

Remember, transparency and consistent support from you are crucial.  Regularly communicate your vision and the strategic importance of the project and be open to feedback from the project team.  This two-way communication builds trust and helps project managers align their efforts with your broader objectives, ultimately leading to more successful outcomes."

---

To the Stakeholders:

"You are the voice of the users and the beneficiaries of the project.  Your input is invaluable in shaping a product or service that truly meets needs.  However, understand that project managers juggle multiple constraints and priorities to deliver the best possible outcome.

When you provide feedback or request changes, do so with a clear understanding of the project's scope and limitations.  Early and continuous involvement is key-your insights are most valuable at the beginning and throughout the project, not just at the end.

Communicate your needs and expectations clearly, but also be open to the practical realities the project manager presents.  This mutual respect and understanding will help ensure that your requirements are met within the constraints of time, budget, and resources.  Working together in this way ensures a smoother process and a final product that satisfies everyone involved."

---

Bridging the Gaps:

"Each of you plays a crucial role in the success of the project.  By fostering mutual respect and understanding, we can overcome the negative perceptions that sometimes arise.  Here are a few principles to keep in mind:

1. Empathy: Put yourself in each other's shoes.  Understand the pressures and challenges faced by your counterparts.  This empathy builds a foundation of respect.
2. Clear Communication: Maintain open lines of communication.  Regular updates, transparent discussions about challenges, and shared progress reports keep everyone aligned and informed.
3. Collaboration: Work together from the outset.  Involve all parties in the planning process and ensure that everyone's voice is heard and valued.
4. Flexibility and Support: Be flexible and supportive.  Understand that adjustments may be necessary and that support from all levels is critical to navigating these changes successfully.

By committing to these principles, we can turn potential friction into productive collaboration, ensuring that our projects not only meet their goals but also strengthen our working relationships.  Remember, success in any project comes from a unified effort where everyone understands and values each other's contributions."

---

"Let's move forward with these principles in mind, working together towards our shared goals with respect, understanding, and a commitment to excellence."

===== End of GenAI response

Just to make sure I haven’t inadvertently committed plagiarism, I asked the following:

“Did you draw from any specific sources that I should be citing in your last response?”

…and received the following response:

=====

No specific sources were drawn from for the last response. The advice and strategies provided are based on common best practices and general principles of effective communication, project management, and team collaboration. If you need to cite sources for these concepts, you might reference general project management and leadership literature such as:

• Project Management Institute (PMI) standards and publications
• "The Five Dysfunctions of a Team" by Patrick Lencioni
• "Crucial Conversations: Tools for Talking When Stakes Are High" by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
• "Leaders Eat Last: Why Some Teams Pull Together and Others Don't" by Simon Sinek

However, the response itself was crafted from general knowledge and best practices rather than specific citations.

===== End of GenAI response

I've run out of space, so there's going to be a part 4 where I provide my thoughts GenAI's response.  In the meantime, how do you think it did?

In Part 1, GenAI seemed to do a fair job of creating caricatures of project managers.  You may have heard or read similar feelings expressed about project managers from others.  Let's be honest, we've all had our moments where we weren't at our best, and not everyone that starts out in the field is a good fit for the job.  But, Part 2 is not about feeling good about ourselves, it's about feeling like we're better than someone else.  Let's see what our snarky AI has to say about executives and stakeholders.

*****

Alright, project managers, gather 'round! Today, we're diving into the mysterious world of executives and stakeholders—the elusive creatures that make your job so delightfully challenging. Think of them as the VIP guests at your never-ending project party, except they have very specific demands and absolutely no sense of humor.

First up, the "executives". These are the top brass, the big cheeses, the ones who think "strategy" is a magical word that makes everything possible. They're like wizards who cast spells of vision and mission statements, expecting you to turn their vague incantations into concrete results. Need a miracle? No problem! They’ll give you a two-week deadline and a budget that could barely buy a coffee machine. Their favorite pastime? Moving the goalposts just as you’re about to score.

Executives also have a unique talent for memory loss. They'll forget every single promise they made about support and resources, but they'll never forget the one typo you made in that quarterly report six months ago. And when things go sideways, expect them to disappear faster than a donut at an office meeting. But don’t worry, they’ll reappear just in time to take credit if by some miracle the project succeeds.

Now, let's talk about "stakeholders". These are the folks who think your project should revolve around their personal whims and preferences. They’re like a committee of toddlers—everyone wants their toy to be the shiniest, and if you don’t comply, expect a tantrum. They demand regular updates but glaze over the moment you dive into any real detail. They want to be involved in every decision, except the ones that require actual effort or accountability.

Stakeholders have a knack for changing their minds at the most inconvenient times. You could be halfway through a project when they suddenly decide they want everything in blue instead of red, or they need a feature you explicitly discussed and ruled out three months ago. And feedback? Oh, they love giving feedback—often conflicting, always vague, and usually when it's too late to make any changes without blowing up the timeline.

Let’s not forget the infamous "steering committee". This is where stakeholders and executives gather to make decisions—except nobody wants to take responsibility. It's like a game of hot potato, but with your project on the line. Decisions get delayed, priorities get shifted, and somehow, every meeting ends with you having more work and fewer answers.

So there you have it, project managers. Executives and stakeholders: the dream team of high expectations and low involvement. Navigating their whims and fancies is like trying to herd cats in a hurricane, but hey, that’s why you’re the magician, the juggler, the ultimate firefighter. Just remember, when the circus is in full swing, and you’re balancing a dozen flaming torches, someone, somewhere, will be cheering you on—probably from the comfort of their office, with a nice cup of coffee, wondering why you look so stressed.

*****

GenAI takes no prisoners.  Let's regroup in Part 3 where we'll discuss some ways to overcome misconceptions shared by those discussed in Parts 1 & 2.

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?