You can plan it, if you really, really want. Or: How to Build a Project Plan When You Know Almost Nothing Yet

When I gave this talk a few years ago, I wanted to share something that took me a long time to understand. I had spent many years staring at Gantt charts and project plans, sometimes thinking they were created by geniuses who understood every detail of a project before it even started. Later I learned that most plans are not great. In some projects there are none. Many are built under pressure. And very often the person who creates them does not know the full project either.

Note: This article is based on a talk I gave at Code.Talks 2023. Check out the full video here: https://www.youtube.com/watch?v=A9c0CtSIb_U (19 min.)

Still, a good plan has value. Not because it predicts the future but because it gives structure. It helps teams talk about what will happen next. It helps leaders understand the risk behind a date. And it helps everyone build a shared picture of how work will unfold.

This article is the method I wished someone had explained to me in my early days. It is the same approach I learned from a project manager I once worked with. He stepped into a troubled project and somehow managed to bring it back on track. It looked like magic. Later I learned it was not magic at all but a clear and repeatable process.

Here are the five steps I now use whenever I need a project plan quickly, even when the content is still fuzzy.

1) Start with the constraints

Every project has things that cannot move. This is where you begin. Typical constraints are simple:

• A fixed go-live date
• A seasonal event like Black Friday
• A company-wide code freeze
• A key person who joins or leaves on a certain date

You do not need full clarity to identify these. Talk to stakeholders and ask what is fixed. These constraints become the frame for everything that follows. If a stakeholder insists on a tight go-live date and you already know it will be hard to reach, you get an early signal that you need a serious conversation later.

2) Set the frame with high-level phases

Once the constraints are clear, define the big phases of the project. Do not go into details yet. At this stage you want simple blocks like:

• Requirements
• Design
• Development
• Integration
• Testing
• Migration
• Go live

(Note: The building blocks are very "waterfally". It also works using iterations or sprints as building blocks)

Think of it like sketching the outline of a picture before adding color. The frame gives shape. It also gives your stakeholders something they can react to. They will try to pull you into details. Do not follow that path too early. Stay at the top level. This is about structure, not tasks.

A helpful approach is to plan backward from the end. Start at the known or desired go-live date and walk back step by step. It helps create a sense of clarity at a stage where most things are still unclear. from the end. Start at the known or desired go-live date and walk back step by step. It sounds obvious but very few people do it. When you plan backward you quickly notice if something looks unrealistic. If the backward chain leaves only one week for testing in a four-month project you know you need a discussion.

3) Define the milestones

Milestones are the moments that show if you are on track. They are not tasks but events. For example:

• First version of requirements approved
• Design signed off
• First demo ready
• Integration with payment provider completed
• Test data loaded
• Final UAT started

A milestone needs a clear definition. Write one or two sentences that describe exactly what must be done. Share it with stakeholders so everyone has the same understanding.

How many milestones do you need? There is no perfect answer. I follow a simple rule. A milestone should give enough feedback to know if the project is still healthy. If there are none for six weeks you are flying blind. If there are ten in one week you will spend your time reporting instead of delivering.

Milestones are a rhythm. They force transparency and they keep everyone aligned on progress.

4) Add details to the phases

Now you add content. This is the moment where the real work appears in the plan. Break the phases into sub-workstreams. For example in a shop project you can split the work into two clear sections for better readability:. For example in a shop project:

• Front-end work
• Home page, Listing Page, Detail Page
• System integrations like ERP, Payment, CRM, Shipping

You do not need every detail at the start. Focus on the main blocks. Start with the long phases. Add the big elements. More detail can be added later when the team knows more.

Many people start with this step. Here is why you shouldn't: Because without the frame you will drown in tasks. The frame gives boundaries. It works like a canvas that holds everything in place.

5) Map the dependencies

The final step is to draw the lines. Walk through the plan from left to right and ask what depends on what. A few will be obvious. Requirements must come before development. Data migration must come before going live. But others might surprise you.

Look for the critical path. The critical path is the chain of items that decides the end date. If one of these slips, the whole project slips. Not every delay is dangerous. Only delays on the critical path matter for the final date.

Understanding the critical path is powerful. It helps you focus your attention. It helps you challenge delays that look scary but are not. It also helps you identify delays that look small but matter a lot.

This is also the moment to check if your plan looks right.

When a plan feels wrong it usually is. When it feels right, there is the chance it gives you a model to manage the project

Discuss unclear dependencies with experts. Iterate. Adjust. The first draft is never perfect. The second draft is often better. The third often works.

A plan is not the truth. It is a model. It is a helpful simplification of a complex future.

Once the plan exists it is more than a schedule. It becomes the model for how you talk about the project. You use it to:

• Report status
• Spot risks early
• Run simple what-if checks
• Align teams on timing
• Guide staffing
• Communicate with leadership

A project plan will never be reality. Reality is messy. People get sick. Requirements change. Stakeholders forget what they asked for. A plan is not there to predict all that. It is there to help you stay in control when the real world gets complicated.

My experience is simple. Even in agile teams, people will ask how long something takes and what it might cost. A basic plan helps answer these questions without losing the spirit of agility. It is a communication tool.

Closing thoughts

If you ever feel lost at the beginning of a project you are not alone. Most people feel that way. The trick is not to know every detail. The trick is to create structure fast. Constraints. Frame. Milestones. Phases. Dependencies.

Once these five pieces are in place you have your first plan. It may not be perfect but it gives direction. And sometimes that is all a team needs to turn a chaotic start into a strong delivery.