Starting and Structuring a Project The Right Way

A project plan should not begin with a list of tasks and dates. Before building the schedule, the Project Manager needs to understand why the project exists, what outcome the organization is trying to achieve, what is in scope, and which assumptions or constraints could affect the work. If those things are still unclear, a detailed schedule can create a false sense of certainty. Early guesses about the work can get turned into dates, and those dates can start being treated as commitments before the team has enough information to support them.

The useful part of planning is creating enough structure for people to make sound decisions about deliverables, dependencies, resources, risks, responsibilities, and commitments. The plan should become more detailed as the project becomes better understood, and it should change when new information makes earlier assumptions unreliable. Good planning avoids two bad extremes: moving forward without enough structure to coordinate the work, and locking the project into details that the team does not yet have enough information to support.

Turn the Objective Into a Delivery Structure

I saw this firsthand at a digital agency where I managed several early website implementations within a broader initiative to create a reusable headless WordPress foundation for multiple affiliated companies. The overall strategy had already been established before my involvement, but the delivery process still had to be worked out. The shared platform gave us a common starting point, but it did not mean every website could be planned and delivered the same way.

Each implementation brought its own set of challenges. Although the companies were using the same underlying platform, each one had different branding requirements, feature needs, content, budgets, timelines, and expectations for what its website needed to accomplish. That meant we could not simply apply the same list of tasks and dates to every site. More importantly, even within a single implementation, the plan depended on understanding that company’s specific objectives, requirements, constraints, and priorities before the work could be scheduled in detail. We then had to align those needs with the broader objectives of the parent-company initiative and determine where the shared model could be followed as-is and where exceptions or adjustments were needed. That required collaboration among the individual company stakeholders, the parent-company stakeholders, and the project team before the plan could become more specific.

That experience reflects how I approach any project when the objective is clearer than the path to delivering it. Before building a detailed schedule, I want to understand the business objective, expected outcome, boundaries of the work, people who can make important decisions, and assumptions or constraints that could change the plan. I also separate what we know from what we are assuming, what still needs a decision, and what we still do not know. Some of those unknowns require discovery, workshops, technical investigation, or stakeholder decisions before the team can make credible commitments, while others can remain unresolved until the work gets closer to them.

Once that foundation is clear enough, I establish the high-level delivery structure and add detail based on what we actually know. Near-term work can usually be planned more precisely, while later work may need to stay at the level of major deliverables, dependencies, and decision points until more information is available. The goal is to create enough structure to manage the work now without pretending the entire project is already fully understood.

Plan Around Deliverables, Dependencies, and Decisions

Once the project is understood well enough to move forward, I build project plans around what needs to be delivered rather than starting with a long list of activities. That means identifying the deliverables, breaking larger pieces into manageable work, and working with the people responsible for delivery to understand effort, dependencies, resource needs, technical constraints, and sequencing. Dates come after that because a schedule is only credible when it reflects how the work can actually be performed.

It is also important to define what completion means, and two tools for doing that are Acceptance Criteria and the Definition of Done. Acceptance Criteria ensure that the specific requirements of an individual feature or work item have been met. The Definition of Done is a broader checklist that applies consistently across all features and work items, such as completing QA, UAT, required approvals, and deployment. A good project plan should account for both.

“A plan only remains useful if it continues to reflect the reality of the project.”

While at the same digital agency mentioned in the previous example, I also managed a healthcare project that had to be delivered within a short timeframe. It included two parallel tracks, a mobile experience and a landing page. I managed the sequence so each track moved through design, client feedback and approval, development, QA and remediation, and client review, while staggering the work so one stream could move forward while the other was still completing an earlier stage.

One of the most important dependencies was outside our direct control. Because the client operated in a heavily regulated environment, everything from the broader experience down to the text used in the landing page and mobile app had to go through extensive legal and regulatory review. Reviewers would request revisions or decline approval, we would make the requested changes and resubmit the material, and further revisions could follow during the next review cycle. That repeated until final approval was granted, and those review cycles delayed the launch even though our own execution was not the source of the delay.

That project reinforced why dependencies have to be built into project plans even when the Project Manager cannot control them. A plan should show where an approval, stakeholder decision, vendor, regulator, or other outside party can affect the schedule, who owns the next action, and what happens if that dependency moves. In this case, regulatory approval was a real condition for release. We could plan the work around that dependency, but we could not decide when the client’s legal and regulatory reviewers would give final approval.

Beyond dependencies, there are a few other planning considerations that matter. Near-term work can usually be planned more precisely because the team knows more about it, while later work may need to remain at the level of major deliverables, dependencies, and decision points until more information is available. Another important consideration is where estimates come from. Estimates should come from the people doing the work, and uncertain work should not be forced into precise dates simply to make a schedule look complete. Once the plan is detailed enough to begin execution, the next challenge is keeping it useful as the work unfolds.

When the Plan Stops Matching Reality

Once execution begins, the plan becomes something the Project Manager has to keep checking against what is actually happening. Even a well-structured plan can become outdated. Sometimes you inherit a project whose current status, backlog, or reporting no longer reflects the work. Other times the original plan was reasonable, but conditions change during execution and the plan no longer fits the project.

I saw the first version of that problem when I took over a large enterprise program at the same digital agency mentioned in the earlier examples. The backlog contained stale or unclear work, Scrum ceremonies had become inconsistent, status reporting did not clearly show stalled items, and blockers were not being managed well. Before I could manage the program against a plan, I first had to understand its actual state. That meant reviewing and cleaning up the backlog, identifying blockers and dependencies, restoring a regular planning and delivery cadence, and making ownership and stalled work more visible. The goal was to create a baseline that reflected what the team was actually working on.

A separate brand and website project at that same digital agency showed a different version of the problem. I managed that project from initiation through completion, and the original plan became less reliable over time. Repeated sitemap, wireframe, design, and approval cycles took more time than originally planned while substantial development work still remained. We adjusted the remaining work by simplifying parts of the delivery approach, reducing work where appropriate, and tightening change control around additional revision requests. The remaining work also required more hours than originally planned, so those additional hours had to be formally approved.

These two situations were different, but both required the plan to be updated based on what was actually happening. In one case, the inherited baseline could not be trusted. In the other, the original plan had been reasonable, but the project changed as the work progressed. Replanning does not automatically mean the original planning was poor. The Project Manager should be able to explain what changed, which assumptions are no longer valid, and what needs to be adjusted. That may mean rebaselining the project, cleaning up the backlog, changing the execution approach, improving visibility, or tightening scope and change control. A plan only remains useful if it continues to reflect the reality of the project.

Keep the Plan Current as the Work Changes

After the project is underway, the practical challenge is keeping the plan current as conditions change. I try to maintain one current view of what the team is actually managing, including objectives, scope, deliverables, assumptions, dependencies, risks, resources, decisions, and the commitments that depend on them. The purpose is to make changes visible early enough that the team can respond before outdated information starts driving decisions.

“The goal is to create enough structure to manage the work now without pretending the entire project is already fully understood.”

I revisit the plan when assumptions prove false, dependencies move, risks materialize, capacity changes, or new information changes the work. When a decision sits outside my authority, or an unresolved dependency threatens the agreed outcome, I make the issue and its consequences visible to the appropriate owner. Governance should support those decisions and make responsibilities clear without adding process that does nothing to improve execution.

Delivery Performance Is Not Project Success

Keeping the plan current answers whether the work is being managed credibly, but it still does not answer whether the project ultimately succeeded. A project can be on time, within budget, and technically complete without producing the result it was meant to create. Schedule, budget, quality, risk, dependencies, capacity, and the reliability of commitments tell us something important about how the work was delivered, but they do not by themselves prove that the project achieved its intended outcome.

The next level of evidence is whether the agreed outputs were completed and accepted against the established criteria. In many cases, those criteria will come from the objectives and requirements defined at the beginning of the project, but they may also reflect approved changes made as the project evolved. After that, the question is whether those outputs actually achieved the result the project was meant to produce. That could mean improving an internal process, changing a user experience, enabling a new capability, or producing some other intended operational or organizational result.

Some of those results may not be measurable until after the project is complete, and by then the measurement may belong to a product, business, or operational owner rather than the Project Manager. That still matters to the Project Manager because the project should be structured around the result it is intended to support, not just around completing deliverables. During execution, leading indicators can show whether the work is on track, while acceptance, outcomes, and longer-term benefits may require later evidence. Launch is an important milestone, but it is only one step in determining whether the project was successful.

Structure Should Create Confidence, Not Pretend Certainty

Taken together, these distinctions change what I look for in a project plan. The more experience I gain managing projects, the less interested I am in plans that look complete and the more interested I am in plans that help people make better decisions. A strong plan keeps business purpose, delivery reality, key decisions, and expected results connected while making clear what is known, what remains provisional, and what should trigger a change. Good planning does not remove uncertainty, and adaptability is not an excuse for weak preparation.

The balance is between predictability and adaptability. The first version of a plan matters, but its value is not proven by how faithfully reality can be forced to match it. Its value is proven by whether it gives managers and teams a reliable basis for deciding what to do next as conditions change.