In my handbook, Chapter 17 goes into the closing phase. This is after the customer signoff. Of course, there are punch list items that remain after the signoff. The PM has to chase those down and make sure the customer gets the finished product. But even when all those are complete—and they can take a while—the project still needs to be closed out.
Close out needs a lessons-learned meeting. Some people call it a post-mortem. It’s the meeting everyone forgets. Schedule that lessons learned meeting. It is only a half hour or an hour at most. The team needs to have a chance to review how things went. They can talk with each other about how to keep doing the things they like, and avoid the part that went wrong. They work so hard, this may be the only time they get to trouble shoot the process, and it’s invaluable to teambuilding and efficiency.
The PM needs to gather all the deliverable and provide them to the customer. The final BOM, the as-builts, final software files and other documents. She needs to check off the requirements outlined in the SOW and hand them off to the customer
ALSO! Those same docs need to be archived for the service provider’s records and handed off to support. IF the customer requests a service call, that tech will need those documents to get the issue resolved.
The invoice must be delivered to the customer. The service provider is running a business after all. There are other contracts and invoices that must be processed as well. Any subcontractors or skilled labor that was part of the project must be reviewed, accepted and paid. There will be tracked in the project budget, which is now its final stage.
The project team can be released and know this work is put to bed, the customer is satisfied and likely to come back to you when they have more work. Celebrate!
I have gotten this question from a Project Manager; “How do you handle multiple projects and how many is too many?”
I’ve heard an old old story about a farmer who was trying to save money on food for his horse. He fed the horse a little less every day. It was a working horse, pulling heavy loads.
It was going along so well, that farmer got the horse down to a handful of feed a day, cutting his costs on feed. Then the horse died. The farmer was angry because he couldn’t finish his experiment.
Business loves to save money. Me too. But that poor horse!
How many projects can one PM manage at once?
It depends. And I hate that answer. As a PM, I gather the team at the internal kickoff to make sure we have the right resources to get the job done. I will raise a red flag, even calling a halt if I see we don’t have what we need. I won’t sent the team onsite without enough people. If I see some guy trying to be a superhero and lift a display alone, I stop him and insist we get another person.
I don’t want to lose a critical resource to injury. I’ve been known to ask the client to provide an extra set of hands if they can’t afford to pay for another person.
When the bosses do the WIP report, who is checking on the load the PMs are carrying?
I’ll be honest, I’ve been that one carrying too much in the past.
There was that time that I didn’t double check the delivery address on a shipment of touchscreen displays and they all went to one address instead of the 7 different places it was meant to go to. I felt bad about that, but on the other hand the manager who handed me the project did not make it clear when he assigned me the project.
Those managers of project managers are caught in the middle. PMs are expected to do their job and not bring attention to themselves by talking about problems.
A good PM knows that risks need to be exposed as soon as possible. We stay aware of weather that would delay deliveries to site. We must make sure that everyone on the job has what they need. It’s big waste if they don’t.
There is an old saying in project management. You can’t take three pregnant women and set them to work to produce one baby in three months.
Some things take time. We know how long it takes to gestate a baby.
When it comes to managing a project, it’s a road less travelled. I don’t know the map. The project management institute defines a project as an effort that produces a UNIQUE result.
Definitively, we don’t know exactly how much work it’s going to take and how long it’s going to be.
So those middle managers—the bosses over the project managers—hand out the projects with a hope and a prayer. If the PM fumbles the project, it’s the manager’s fumble just as much as the PM, because he’s the one who chose you to do this work.
Did he misjudge how much work that project was going to be? That’s when the PM has the responsibility to raise the alarm.
Yep.
That means I have to say “This is too hard for me. I need more time.”
And I have to say this humiliating thing to my boss.
That boss who made assigned it to me. If he had somebody better standing by, he probably would have given it to that person. Maybe his favorite PM already told this boss that HE is overworked. And I—the rookie who screwed up the delivery of 7 displays—want to come to him with the same complaint.
Whose job is on the line?
Everybody has something to worry about.
I better be very very very sure before I say it.
Which means:
Double checking everything, looking for ways to expedite or shuffle the tasks
Late nights
Early mornings
Lunch at the desk
Telling my family I’m busy and I can’t
The clock is ticking, pushing me and the project to the brink, to the point of failure.
I can do this. Just barely. Don’t miss that phone call or that shipment or the next meeting.
Then the boss gives me another project because I’m doing so well on the ones I have.
I never said otherwise.
And I’m proud that I didn’t have to fold. I’m getting better at this. I wonder how many more projects it will take to be that favorite PM. The one who was able to say he were too busy for another project.
It’s not just me. The whole project team is working on the brink. Some of the best programmers and commissioners working so many hours that they quit to get a break.
The PMs have tools in their kit. They control—well, steer—the schedule. Some projects can be sped up a little, others can be delayed because of resources. If I’m good, I can push out a task for day so I can go to my kid’s musical performance. And often I go but still wrestle a flood of texts while in the audience.
To mix up the metaphors from earlier, I am the underfed pregnant horse trying to pull the load I’m given.
What’s the right answer? Can I be confident that I know enough to recognize when the load is too heavy? Would my boss even believe me?
Deep breath. My job is to manage the project.
I know how to do this.
When I identify a risk, I need to track it. If a hurricane were coming to an installation site, I would tack it and come up with a plan. We would bring it up in the team meetings.
If a heavy PM workload is a risk, I need to track it the same way. As early as I see it, I can bring it up and say that things might get delayed and I will keep them updated. The team can huddle to re-prioritize the tasks. Some things could be delayed. More resources can be added if the timeline can’t slip. Scope could be cut.
All these risks and mitigation can be tracked, and the team is working together. That’s what the team is for.
That documentation I create from the team is what gives me the confidence. Bringing up the risk early is about the success of the project. Not about me.
It was never about me.
I don’t want to make another rookie mistake by trying to do it all alone. When the project work mounts, I can track that risk just like any other. This protects the project and builds a protection for me.
I don’t know if I’m ever going to be my boss’s favorite. I do know I can give status updates on my projects, including the workload to whole way along. Confidence comes from competence. That’s the part I can control. That’s what I know.
The projects I work on only have one project manager. I get excited when someone brings up what we PMs do.
Substack served me a ppiece about intergenerational communications. Thank you, Jonathan Small. In the workplace. emails, texts, Slack, A.I. and phones are used by different groups in different ways and can leave a team lost.
Here is where PMs where mentioned
“I guess you don’t work with any project managers. The answer is to set communication norms and expectations. Determine as a team, or org what tech you use to communicate, how quickly you expect a response and how detailed.”
Those expectations can be part of the communication plan. As a PM, I try to work with what’s already working. I prefer emails, but texts and DMs allow for quick answers. I adapt to what the teams need.
Those expectations can be part of the communication plan. As a PM, I try to work with what’s already working. I prefer emails, but texts and DMs allow for quick answers. I adapt to what the teams need.
Then again, as that excerpt above implies, they teams might very well need someone to lay out the standard. Corner office types don’t always see what is happening on the factory floor where the real work gets done. The PM lives where are the work is happening.
Chapter 13 of my AVPM handbook lays out legally defensible expectations for how communication will happen during an installation window. It’s meant for subcontractors to understand what is required of them at the beginning of the work, throughout each day, and the communications expectation every day. I further lay out what must be delivered at the end of the job for them to receive their pay.
Definitively subcontractors are not part of the company culture. The company itself may be struggling with new communication tools with round-the-world work zones, all before we get into intergenerational styles. A Mission Statement is not enough to keep the project team working together. We need to know to check in and when they are shamefully late.
As PM, I know to give clear action items to specific owner with a due date. If the team is haphazard in communicating the fulfillment of these deliverables, the next step is to be more specific. THIS will be email; THOSE will be Slack and THESE must be PDF.
Then I follow up on any responses that don’t meet the spec. Yes, it’s a lot of work. That’s what PMs do.
How are workplace communications working? Let me know in the comments
My first real job was at McDonald’s. I learned phrase I’ll never forget. “IF you have time to lean, you have time to clean.”
As a PM, It’s my job to give everyone on the job site something to do. I start with the work plan, but if I planned everything right there is no extra time.
WHICH MEANS
everyone better be doing something to get this job done. If someone is sitting down, something is wrong.
But don’t do anything I didn’t tell you to do.
That fine line only works if i pack these guys to the gills with stuff to do. And if I check in with them constantly to remove any blockers.
This sort of micr-management could be annoying, but i learned if I answered all the problems and questions as quicklyas they ask them or even before.
Once my team realized that was my goal, they didn’t mind checking in with me. They trusted that I would make things better when they came to me.
Any installation window has a lot of moving parts. Every body has to do their part. And everyone has to stay out of each other’s way.
That’s why the Project Manager has to direct traffic and keep everyone moving.
Very specifically I have to think through what every single person on the team needs and I better have it.
This is what monitoring and control looks like when the PM has extreme ownership.
Control is acheived by monitoring before it even starts.
That kickoff meeting is the launch party for the project. The decision makers already decided to initiate, the design and the bill of materials are accepted and it is go time.
In the words of Captain Picard “Make it so!”
Engage execution phase.
Now that the design is done the PM creates the preliminary project plan and schedule.
That project plan isn’t DONE done though. The project team has to meet to review everything. That’s the kickoff. Well, there are two kickoffs, the internal kickoff with the in-house team and the customer kickoff. Those two sets of people have different perspectives. The PM must collect and prioritize that information.
The PM can create the preliminary timeline. That timeline has a kick to it, and I have to hang on for dear life. I review it and all the milestones on the recurring project meetings. We can get all the right people scheduled and committed to their part. Electricians, carpenters, programming, CAD …what else is needed on this project? Get that resource scheduled as early as possible.
When all resources are committed, with the system equipment in hand and the locations reserved, we have the technical kickoff. This is the install team getting ready to install and commission the system. To quote my handbook: “All the planning, meetings and conversation have led to this execution window—I don’t want to squander a minute of it.”
All the information, all the coordination passes through the PM. Questions, updates, decisions come through the PM. Things are supposed to go fast and furious. It will get done and that project get signed. I’ll talk about the monitoring and control next week.
When I wrote I my book The AV project manager handbook, I assumed some things. I didn’t stop to answer the fundamental question: What is a project? My friend Joe Way says everything is sales. I clap back “Everything is a project!”
But there is a demarcation. This is a project:
“A project is a temporary endeavor undertaken to create a unique product, service, or result.”
That sounds like lawyer talking. Let me pull out the dividing line. A project is something with an end, and it does something that isn’t already being done.
A project contrasts with operations. For an organization—whether a business, government or a household—there are the everyday systems that keep everything running.
In my household, I really want things to stay the same. We rely on a lot of systems. A really big one is our cars. We use our vehicles every day, and my daughter got her driver’s license recently. We are all zipping around for school, work and sports.
Making sure we park in the driveway in the right order so we can drive our cars in the order we are going to leave, keeping the gas tane full are folded into the week’s chores.
They are not a project. Nothing unique to see here. In fact, as far as my household is concerned, we want it to stay this way. Can I just go about my business please? We can all get where we need.
UNTIL!
Disaster strikes: A car breaks
OR
Operational Upgrade! A new Vehicle purchase
Maybe my car breaks down and needs a new transmission. We would have to come up with a plan for the time and resources it will take to deal with this disruption in operations. The other drivers in the household might have to share their vehicles. The family would do decision analysis about the kind of repair we would do (repair or replace? What’s the budget? How old is my car? Etc.)
We would all weigh the opportunity and the cost in time and resources to make the best choice to restore the vehicle transportation system.
We could brainstorm ideas. Do we need three cars? How do the choices fit with our values and future plans?
The stakeholders –all of whom are still involved in operations—have their part to play in the project as it gets scoped, designed and executed.
In this case, all of them want to get back to operations as soon as possible.
For a professional services organization, a project is likely the source of revenue, Projects are the reason for operation, not an interruption of operations. The goal might be to define and execute as many project as possible, as quickly as possible. Projects and Operations exist side by side, and the team would do well to understand the difference and right-size the effort and attention on both
All the stakeholders would be wise to identify which projects support their operations and which operations support their projects. It’s a changing continuum. What is the core value for the team? What things are always a NO? Communication, analysis and leadership will support success and progress.
Priorities, opportunities and disasters shift. Resources and attention can be distributed in response.
For AV integrators and professional services companies, the project planning is usually called scoping.
The client who needs the service will have their reasons for reaching out, and they have a concept of what they want. In their mind it may be utterly clear.
When they reach out to the group that can provide what they want, the questions start
“How do you want this system to function?”
“Have you considered…?”
“A different client had success with this choice…”
The clients usually value the experience their integrator brings and want this kind of conversation.
I remember one very unusual project when the customer refused absolutely to hear anything our team had to say.
This was a military project, to install a movie theater on a military base.
They had a budget, and they borrowed a bill of materials from a different military base and our house was told to make this BOM work in a different space with no changes. In my experience, that is very rare. Most project planning phases involve a discussion and prioritization.
The ‘designer’ assigned to this job was angry and hostile. He had no say in how this project would work and stopped speaking to me after he realized how inadequate the system would be for the space. One of the suppliers, QSC, even offered a free upgrade on one of the amplifiers so that the system could perform better. They didn’t want their name on the system that was underpowered.
The customer refused. The materials could not be substituted, and we had to make it work.
Most projects’ planning phase involves multiple iterations. The first plan could be too expensive, the next might have unnecessary features. The planning phase allows those aspects to be explored and after consideration the final choice becomes the SOW of the contract.
That information about priorities and the desired outcome is a wealth of knowledge that the account management team can bring to the kickoff when the project manager schedules the kickoff for the Execution phase.
