Organizations that don’t map out the details of where they are going and are clear about it on down the ranks will not reach their desired destination, at least not on time.
No project works like clockwork, but your team can’t even pretend to march in tune without a drum beat, you can’t have a cadence without a schedule.
A project charter is like a zoomed-out road map. It lists the milestones but mostly focuses on the starting and ending points. The project schedule is a zoomed-in road map that brings the details of the path to light. It sets the pattern and rhythm for your project.
Here is my takeaway #22 from one of the most useful practical books in my field, “Project Management for the Unofficial Project Manager”:
22) “If you’re managing a project, you’ve got to know what to do when. The schedule becomes the (detailed) road map. That’s why experienced project managers break projects down into bite-sized pieces and schedule each piece.”
“The schedule contains all the key tasks and milestones needed to complete the project. It tells you if you’re on track or not, so it should be visible, constantly updated, and open to every team member. Otherwise, your project team is working in the dark.”
Note: This comes from Chapter 4 “Planning the Project: Milestone or Mirage?” (pages 88)
I like to add the word “detailed” because the project charter is like a pirate’s treasure map, but the project schedule is more exacting. Your project team needs clear direction, priorities, and actions. You will learn more of the nitty-gritty details than organizational leaders will need to know. And your subject experts will learn and know more of the nitty-gritty details than you will need to know. But every “bite-sized piece” of importance to the timing of your delivery must be delineated. If you ask your team to eat the whole elephant so-to-speak in one bite it will just be overwhelming and insurmountable.
Note: Agile projects that are measured in sprints and move just enough items from the backlog to work on for 2-3 weeks may work out just fine with a Kanban board, whereas many feel with traditional project management you will need a Gantt chart to breakdown the work activities enough if you hope to keep track of everything in play on the schedule of a project at all.
————————–
STORY TIME:
When I assisted an organization to launch a Business Process Outsourcer (BPO) and ramp up operations from 0-500 employees in 2017, our project teams were mostly “working in the dark.” It’s not that the executive team did not have a schedule outlined. We were all fully aware of the go-live date and the goals for the end of the year. We even achieved those particular milestones that were set.
What we didn’t do, is clearly breakdown the work, schedule it, and set durations. We were figuring out project management software we had just purchased and configured and determining our project management practices as we went along. This is where the project itself started to break down. I was getting bits and pieces of what I might project manage, what teams I might work with, and what their work actually entails. But it was crazy to me that people like me were not included early and often in planning sessions to work out the details.
I was brought into the organization to work with Subject Experts to harvest knowledge from 5-8 different office locations, to create Revenue Cycle Management (RCM) related software navigational videos, and compile, prioritize, and relay and facilitate training as our team had it ready to go. It was not clear who was doing what by when for the longest time because only executives were included in on the organizational portfolio/program/project level meetings.
I had a steep learning curve coming into a new company, but I was able to gain enough of their confidence, trust, and credibility to be included more. I started seeing the bigger picture and I got enough authority to be project manager so I could do the job I was brought in to do. Plus, I was able to gain a seat at the table so-to-speak taking notes for high-level meetings. And I gave them a lot of great ideas and volunteered and took on a lot of projects when it made sense for me to step up and bridge the gap between executive desires and frontline execution. (I even established the project charter template the organization started using, and we got pretty good with using our Gantt Chart software.)
But the organization continued to be so secretive about the details and what they expected from project teams – mainly because they themselves didn’t really know where they were going with everything and how to get there (still wayfinding in their project management attempts) – that eventually I couldn’t see enough through the dark to find my way anymore in that company.
————————–
That organization seems to have come to the conclusion that their subject experts were either not good enough at their jobs (keeping up their skills and training) or unable to translate their work to the masses (rather than one to one), but I maintain that we cut corners and did not train (being too ignorant of our deficiencies in project management) or hire (being too cheap, when it actually cost more to go about it all wrong) project management at the middle management level. It was not built in (foundational groundwork laid), matured, and supported for any lasting organizational change effect, nor organizational abilities to change nurtured (for it to take root). A poor schedule was just a symptom of these deeper problems.
Where this was most evident was in the fact that the executives (who didn’t truly know project management either) had to take their valuable time to lead work breakdown, wireframing, and scheduling efforts (which often led to rework anyway), when they weren’t able to form project teams that could function completely independent of them (because they were out of touch with those levels of work and how to mentor and coach it up).