Simplifying the Planning of a Complex Project

How do you make it simpler?

Note: a prior version of this article was published in Medium in May 2024.

Note 2: In an effort so simplify the writing, I am using the word "project" to refer both to projects and programs. They share many of the same requirements.

In "Planning a Complex Project" I explained the process I use to plan complex projects. These are efforts that have many interacting teams that have mutual dependencies (i.e., a team needs a deliverable from another team to complete their work).

To recap, the process is simple:

1. Identify ALL teams and participants. They need to be involved.
2. Explain the planning process to them.
3. Assign them homework (deliverables they are responsible for and deliverables they expect) and have them complete it.
4. Get together, in person (preferably) or via Zoom (very effective) to plan the project.
5. Capture the results in a tracking spreadsheet and start executing.
6. Adjust the plan as new things come up.
7. Conduct more planning sessions to extend the horizon of the plan as necessary.
8. Complete the effort.

This approach leverages everyone's knowledge to develop a plan. But this approach may not be as simple as it could be. As I addressed in the same article, the key is to focus on deliverables, both the final deliverable(s) as well as internal deliverables. This approach simplifies the effort to plan and execute the overall plan, while relying on the teams and sub-teams to plan and execute the tasks that lead to the deliverable. The key is to plan and manage at the appropriate level. There's no reason why a project manager needs to know the details of how a team will do the work to complete the deliverable. The team's work can be treated as a black box, with a set of inputs (deliverables they need) and outputs (deliverables they generate).

Key, of course, is making sure that there's agreement on the requirements and timing of each deliverable. Its quality, meeting customer requirements, is one of the essential items to avoid surprises upon delivery. Again, though, the project manager does not need to know the details of the requirements, only that they have been agreed to. Of course, the project manager may have expertise that they can provide to the team, but their participation is not necessary. As a matter of fact, it may be counterproductive to the effort as they may introduce "friction" into the team's work.

The plan generated should be very detailed in the short term, up to the "first horizon", while being fuzzier in the longer term. People are good and comfortable at planning, and committing, for the short term. They know what other commitments they have, what their availability is, what the objective of the effort is, and from that information can generate a commit date. In the longer term, things are more variable. That's why we expect very firm commitments in the upcoming two weeks or so, relatively firm commitments from week 3 until 8 or so, and quite fuzzy and variable dates (not commitments as they are not committed) beyond week 8.

These date expectations are based on a rolling plan, which means that as the plan is executed, it is updated with details and dates.

If things are fuzzy in the longer term, how can you generate a good plan to determine when you'll be done? Experience shows that plans generated can be very accurate to what the teams develop. This is not to say that these dates will meet upper management or customer expectations. But they will be realistic. My first experience with Commitment-Based Project Management (CBPM), also known as Map Days in the planning aspects, showed that the customer desired date was not feasible. There was too much work to be done on the product. Rather than argue, we broke up the planning meetings and came back a couple of weeks later with a recommendation: to split the deliverables. While these new dates still did not meet the customer desired dates, by then the customer had more flexibility. My teams met these committed dates!

It takes practice and confidence to try this approach. It can be uncomfortable. We've been trained to need to know all the details of a project. While ideal, it is impractical and counterproductive. Make sure your teams are qualified and have the needed resources, and get out of their way. Support them when needed. Monitor to ensure things are going well. But trust them!

Want to talk about doing it for your next project? Send me a note at jose@coachsolera.com.

Subscribe here to my LinkedIn newsletter to get my articles.