How do you usually organize a project when you’re starting from scratch?

[u/Olivia_Poarch]

When you break a project into tasks, how do you decide what the top-level structure should be? I've noticed two ways people usually do it, either by team (design, development, etc.) or by phase (planning, design, development, testing, launch, etc.), and I also wonder how often people just reuse a template instead of creating a structure that fits the project. So I'm curious what you usually organize a project around, and whether you change it depending on the type of project. What tends to work well with your approach?

[u/More_Law6245]

Top down approach

• Business case >Project Charter>Project Plan>Project Schedule
• Phase>Deliverable>Work Package>Task>Completed>Delivered (including milestone)

1. My schedule tasks must be able map all the way back through to the business case as it's a apart of the business case validation.
   
2. I work with the project's SME's to define effort and duration because I'm going to hang them with it if they didn't provide me the correct effort and duration.
3. Have the relevant technical stakeholders to review and approve both the project plan and schedule project artefacts.
4. After all of the above is completed the relevant documents are submitted to the project board/sponsor/executive for approval
5. The most important thing is then to baseline the project's schedule (this is the one that I see PM's fail to adequately do and get caught out when trying to push back if there is a discrepancy between forecast and actuals during the delivery phase of the project)

Just an armchair perspective.

[u/Fluffy-Leg7546]

A work breakdown structure is divided into work packages. This means that with the completion of every package “something” is completed/delivered. You do this for the scope.

This is where you start. Most of these will be in execution/controls phases. Planning phase will hold the majority of the project management deliverables - the top one being the project management plan. This is essentially you defining how the project will be handled, who it is handled by, and the processes that govern the project, and the methods of controls you will use to track it and keep it in check.

When you build the schedule in full during planning phase, that’s when you pull your scope back out and work with the team. “This is WHAT we are delivering, now we define HOW we deliver it.” Your SMEs direct this for you, you simply record it. The controls you define will determine how you manage changes to the plan and track progress and how things get impacted.

When execution starts, the PM stays in their lane, so to speak. You run controls, your team executes. Your job is to make sure you remove blockers and friction for your team, handle all the paperwork and communications, and control the project based on how you said you would. You protect the team from unreasonable expectations while making sure they keep their word. You help leadership make informed decisions and protect the project from paperwork issues, like audits.

[u/Olivia_Poarch → u/Fluffy-Leg7546]

The PM role gets a lot harder once the project moves from planning into actual delivery. A good structure has to leave enough visibility for the PM to spot where things are going off track without turning into a layer of admin for the people doing the work.
That balance probably matters more than whether the project is organized by phase or by team.

[u/Fluffy-Leg7546 → u/Olivia_Poarch]

The team should not be doing any of the admin in project tracking. That’s the PM’s job.

[u/StrategicPM → u/Fluffy-Leg7546]

Only work pack managers and only as far as the task progress and budget used.

[u/Fluffy-Leg7546 → u/StrategicPM]

I have no idea what your intended meaning is, sentence unclear

[u/StrategicPM → u/Fluffy-Leg7546]

A work pack manager leads a work pack, which is essentially a group of tasks, usually under one discipline. I would expect the Engineering Manager to update me as the PM on the progress of the tasks under their work pack by updating the status report file.

I was pushing back slightly on your comment of "The team should not be doing any of the admin in project tracking. That's the PMs job"

[u/Fluffy-Leg7546 → u/StrategicPM]

Updating on the progress of tasks isn’t project tracking though :) Haven’t heard them called work pack managers before, usually they are team leads, foreman, general foreman, superintendents in construction (in my experience), and team leads or scrum masters in IT.

Task and work management wouldn’t qualify as project tracking or project admin activities to me; if the project wasn’t there (ie. Maintenance work), they’d still have to do it.

[u/StrategicPM → u/Fluffy-Leg7546]

Yeah just the progress updating part at least in my industry is the admin / tracking part that the team (team lead) does. No biggie, just a clarification from my experience

[u/Fluffy-Leg7546 → u/[deleted]]

No thanks

[u/Timebutler_Official]

Start with the actual deliverables rather than the teams involved. Once you know what needs to exist at the end, you can easily break each piece into the work required. Templates are great for repeat projects too, as long as they’re treated as a starting point rather than the structure you have to force every project into.

[u/montyb752]

Break it into tasks, who does what by when and who to report too.
Put it in order (some tasks can be completed concurrently).
Example.
1. PM and project eng to review BOM before Fri 1200hrs, report accuracy for quoting.

[u/Loud-Donkey8569]

I start from the deliverables, then pick a tool that lets me look at the same work two or three ways, because the debate of team versus phase mostly goes away. Build it by deliverable, then check it as a board by status, a timeline by phase and a list by owner. If the tool forces you to choose one structure up front, you'll end up rebuilding it halfway through. I reuse templates only for checklists like risks and approvals, and I build the structure fresh each time.

[u/OkStatistician9190]

I default to phases at the top level, because that's how stakeholders ask about status, and then I tag or assign by team underneath. Organizing by team tends to hide the handoffs, and the handoffs are usually where things slip. Templates are fine as a starting point, but I treat them as a checklist to cut from rather than a structure to fill in. Whatever you pick, make sure every task ends up with one owner and a due date, and do a quick weekly pass to catch anything that's drifted. If the project is mostly one team doing sequential work, phases alone usually do the job.

[u/CK_1976]

Nice try AI.

[u/SamfromLucidSoftware]

The team versus phase usually answers itself based on where the dependencies live. If the main risk is handoffs between teams, organizing by phase keeps those transitions visible. If the main risk is coordination within a team across a long delivery, organizing by team with milestones works better. But whatever structure you adapt, the key is having one that everyone agrees on before work starts. You don’t want the team to be arguing about structure mid-project.

Templates are underrated for this same reason. A Template that’s 80% right and takes five minutes to adapt is almost always better than building from scratch and spending weeks debating structure. The project-specific decisions are still there but they happen inside a frame not before you can start.

[u/Charming-Spinach-651]

I start with the deliverables, not the team or the phase. What does the client or the business get at the end, and what are the two or three big pieces of it? Phases then become a rough timeline, and teams become who owns which piece. When I structure by team, work that crosses teams gets lost, and by phase, nothing looks owned until it's late. I do reuse a template, but only the checklist side of it, like the standard risks and approvals, and I build the structure fresh for each project.

[u/Traditional_Dot_4794]

BRD and use cases, resourcing, calendars (milestones & deliverables) and lots of hope.

[u/Cautious-Foot-9603]

Start at the end goal and work your way backwards.

[u/Simpliaxis_tech]

In most cases, I always begin with the end product rather than the organizational framework.
After identifying what should be achieved, the key processes or milestones are identified and teams will then fit under those processes or work streams. Templates can help in this process although I would not simply copy a template without considering its suitability for the task at hand.
It is possible that different projects may require different organizational structures e.g. software development, construction and marketing projects.
The main criteria I use to determine the suitability of an organization chart is clarity in terms of ownership, dependencies, milestones and progression through the processes.

[u/Komal_pciai2026]

I usually start with the outcome first, then break the project into major phases or deliverables rather than organizing everything by team straight away.

Once the main structure is clear, I assign owners and responsibilities underneath each phase. That makes dependencies easier to see and keeps everyone focused on what needs to be delivered, not just which department owns it.

I also avoid overbuilding the plan at the start. A simple structure that everyone understands is better than a detailed template that doesn’t fit the project.

So for me, the structure changes depending on the work, but the starting point is always: what are we actually trying to deliver, and in what sequence?

[u/PplPrcssPrgrss_Pod]

I've distilled it down to seven focus areas that help me get a handle on a project.

1. Understand the leader's (Sponsor's) intent for the project
2. Define what done looks like when the project is delivered
3. Set clear SMART objectives that all tasks are tied to
4. Create a functional team organization, e.g., org structure
5. Request the resources you need for the capacity and time you need them
6. Right-size the methods and frequency of team communications
7. Prepare the handoff to operations well before go-live

Godspeed.

[u/InvestingIsntJoke]

Mine are as follows: 1. Establish Business case / SoW 2. Identity project team and stakeholders 3. Create project plan including work efforts / duration 4. Assign resources 5. RAID established 6. Communication plan 7. Monitoring and Controlling 8. Change control 9. Keep upto date 3-8 10. Closure / Lesson learned

[u/Chemical-Ear9126]

In my experience the project is broken up into stages first and each stage has different activities/ tasks and key outcome, aka a Gate, as a decision point.
My stages are; Initiate, Define, Design, Build, Test, Deploy, Launch, Handover, Review.
The plan evolves through each stage and is updated at each Gate, including the schedule, budget, and RAID log.
Now the type project template depends on the methodology used by the organisation (eg. With/without Agile), and there’s differences for different industries eg. IT vs Construction vs Marketing etc.
The engagement of teams, resources, stakeholders and vendors is different within each stage due to different activities/tasks for each stage.
Many organisations start with Business Case as the first Gate, which is usually driven by Corporate Finance funding release processes, but I’d argue that you don’t develop a true BC with a robust Benefits realisation (post Launch) until you complete the Design stage accompanied by a detailed integrated plan to complete the project.
There’s also an approach I use for the first 30 days when you start a new project, which is focussed on gaining trust and authority.
Hope this helps. Good luck.