How to Start a New Project the Right Way

Most projects do not fail in the middle. They fail in the first two weeks — before the work even began — when nobody wrote down what the project was for, who could approve it, what “done” meant, or who was responsible for what. The team dives straight into tasks with enthusiasm, and the project quietly inherits every ambiguity that will later explode into scope creep, missed deadlines, and “I didn’t know I was supposed to do that.”

Starting a new project the right way is a short, deliberate sequence of decisions that happens before execution: run the pre-start checks, write the project charter, define success criteria, identify stakeholders, set up the team and roles, run the kickoff, and build the first planning cycle. Do this well and the project begins with a foundation; do it casually and the project begins with a wish.

This guide walks you through exactly how to start a new project — the steps in order, the questions to answer at each one, what the documents should contain, real examples with numbers, and the mistakes that most often sabotage the start.

Quick Answer: How Do You Start a New Project?

You start a new project by working through the initiation phase before execution: run the pre-start checks (is it needed, is it authorized, is it feasible), write a project charter that captures purpose, scope, budget, timeline, sponsor, and success criteria, identify stakeholders and get sponsorship, define the team and roles, run a kickoff meeting, and complete the first planning cycle that establishes the baseline.

The guiding rule is simple: nothing is real until it is written and approved. If you cannot point to a charter that a sponsor signed, a stakeholder list, and a definition of done, you have not started a project — you have started an argument that will reveal itself later.

What Should I Check Before a New Project Officially Begins?

The pre-start checks answer three questions that too many projects skip: Does this project need to happen? Are we authorized to run it? And can it succeed as currently understood?

Run the needs check first. Is the problem real, and is a project the right way to solve it? A surprising number of “projects” are solutions to problems that could be handled by a process change, a tool purchase, or simply by not doing something. The cheapest project is the one that never started. Write down the problem in one paragraph and the expected benefit of solving it — if the benefit is vague, the project will be vague.

Then run the authority check. Who has the power to approve this project’s scope, budget, and timeline? If you cannot name a sponsor — a person who is accountable for the project’s success and can commit resources — stop here and get one. A project with a committee “everyone agreed to” but no single accountable person starts without a rudder.

Finally run the feasibility check. Given what you know about the requirements, the timeline, and the available people and budget, can this project realistically deliver? This is the moment to surface the uncomfortable truth — an impossible deadline, an unstaffed phase, an unaffordable scope — while the project is still just an idea. Fixing it here costs a conversation; fixing it in execution costs a crisis.

What Goes Into a Project Charter?

The project charter is the formal document that authorizes the project to exist. It converts the pre-start discussion into an agreement: what the project is for, what it covers, what it costs, when it ends, and who is accountable. A good charter is one to three pages — long enough to be unambiguous, short enough to actually be read.

A charter that works contains these sections:

• Purpose and background: the problem and why the project is worth doing.
• Project objective: the outcome in one or two sentences.
• Scope (in and out): the deliverables included, plus an explicit out-of-scope list.
• Success criteria: the measurable conditions that define “done.”
• Budget and timeline: the cost range and the key dates.
• Sponsor and stakeholders: the accountable person and the people affected.
• Constraints and assumptions: what is fixed (budget, deadline, compliance) and what is being assumed.
• Risks at the start: the known risks you already see, so they enter the register immediately.
• Approval: signature lines for the sponsor and the project manager.

The charter is not the detailed plan; it is the authorization slip that says the project exists and the project manager has the authority to run it. If you produce only one document for the whole project, produce this one — every later dispute about scope or purpose is settled by what the charter says.

How Do You Define Success and Boundaries at the Start?

Success criteria are the measurable conditions that let you say “done” without asking the sponsor. Write them so a stranger could verify them: not “a successful launch” but “the site launches with 200 products migrated and zero broken checkout flows by June 30.”

Boundaries matter just as much. The out-of-scope list is the project’s shield: every item you write down as “not in this project” today is a scope change you will not have to fight tomorrow. A customer portal project might explicitly exclude mobile apps and custom reporting; a marketing campaign might exclude PR and video production. Writing “not ours” is not negativity — it is precision.

Start the scope-change discipline at the same moment. Define how change requests will be handled from day one — who can raise them, who approves them, and how their impact is assessed. Teams that establish this rule at the start never fight about scope; teams that leave it implicit spend the whole project fighting.

How Do You Identify Stakeholders and Get Sponsorship?

Stakeholders are anyone who affects or is affected by the project. List them now — sponsor, users, delivery team, suppliers, and the departments your work touches — and note two things about each: how much they care and how much power they hold. High power plus high interest gets close involvement; low power plus low interest gets periodic information.

The most important stakeholder is the sponsor: the single accountable person who funds the project, approves its scope and changes, and removes blockers the team cannot. Confirm sponsorship explicitly — do not assume that “everyone agreed in the meeting” means someone is accountable. If your project touches other departments, map them now too: a sales team whose workflow your project changes will resist unless they were consulted before the design was fixed.

Stakeholders are also your best source of requirements. Collect what the users actually need in the start-up phase, and review the resulting requirements with both the sponsor and the users. The requirements approved at the start are the contract your plan will be built on.

How Do You Set Up the Team and Roles?

Set up the team by naming the roles, not just the people. For each major deliverable or decision area, define who is responsible, who is accountable, who must be consulted, and who only needs to be informed — the RACI model. This one matrix prevents most of the “I didn’t know I was supposed to do that” failures.

The distinction that matters most is responsible versus accountable. Responsible is the person doing the work; accountable is the person answerable for the outcome — often the sponsor or the project manager. When a task has no accountable owner, it is a delegation of blame, not an assignment.

Agree on how the team will work at the same time: where the plan and tasks live, how updates are given, what the review cadence is, and how communication happens between meetings. Remote or hybrid teams need this written down explicitly, because the office’s informal feedback loop is gone. Define roles and working agreements in the start-up phase, and execution runs on them instead of negotiating them.

What Happens in the Kickoff Meeting?

The kickoff meeting is where the started project becomes a running one. Its purpose is alignment: every attendee leaves able to answer three questions — what are we delivering, what is my part, and what happens next.

A well-run kickoff covers the outcome and success criteria, the scope and its out-of-scope list, the roles and owners (including the RACI highlights), the schedule and its key dates, the review cadence, where the plan lives, and how changes are raised. It should not be a read-out of the charter; it should be a discussion that surfaces disagreement while it is cheap — the moment to hear “we can’t hit that date” is at the kickoff, not at the delivery review.

For large or high-stakes projects, the kickoff can run in two stages: a small alignment session with the sponsor and leadership first, then a broader team kickoff. For small projects, a single well-structured meeting is enough. The test is the same: after the kickoff, nobody is guessing.

What Should the First Planning Cycle Cover?

The first planning cycle converts the charter into the plan’s first layer. Use rolling-wave planning: build the near term — typically the next four to six weeks — in detail down to assignable tasks, and build the rest at a higher level, refining it on the review cadence as the project progresses.

The first cycle should produce, at minimum:

• A work breakdown structure down to estimable work packages.
• A near-term schedule with dependencies and the critical path identified.
• A budget breakdown with contingency.
• The first risk register entries, including the risks named in the charter.
• A baseline for scope, schedule, and cost, approved by the sponsor.

End the first cycle with the baseline signed. From that moment, monitoring has a reference point and change control has a standard. The start-up is complete when three things are true: the charter is approved, the baseline is set, and the team has run its first cycle with a defined cadence. Everything after that is execution — which is a different problem, and one your careful start has made tractable.

A Startup Checklist for a New Project

3 Real Examples of Starting a New Project

Example 1 — A small internal project (2 weeks to start). A marketing team starts a 6-week campaign. The pre-start check confirms the problem (stale lead flow) and the benefit (300 qualified sign-ups); the VP Marketing signs the charter. Success criteria: 300 sign-ups, $8,000 budget, live in 30 days; the out-of-scope list excludes PR and video. The stakeholder list names design, content, and sales as high-interest; sales is consulted on the offer wording. Roles use RACI: one person accountable for the whole campaign, one responsible for each deliverable. The kickoff runs 45 minutes and ends with the team agreeing on a weekly status rhythm. The first planning cycle produces the WBS, the schedule, and a $7,200 plan with $800 contingency. Baseline approved in week 1; the campaign launches on time.

Example 2 — A mid-size cross-team project (4 weeks to start). An IT team starts a 4-month CRM migration. The pre-start check surfaces a feasibility problem — the cutover date conflicts with the finance close — and the date is moved before any money is spent. The charter captures the moved timeline, the $28,000 budget, and the success criteria (40 users trained, data preserved, no rollback). Stakeholder mapping reveals sales must be consulted on workflow changes; a sales lead joins the requirement reviews. RACI assigns a single accountable owner for cutover. The kickoff splits into a leadership alignment session and a team session. The first planning cycle produces the WBS, a schedule with two weeks of cutover buffer, and a risk register that flags data quality as top risk. Baseline approved; the project starts with a known risk and a plan for it.

Example 3 — A large project with a hard deadline (8 weeks to start). A facilities manager starts a 9-month office fit-out with a fixed lease date. Pre-start feasibility confirms the timeline is achievable only if the planning-permission application starts immediately. The charter names the lease date, the budget, and the handover criteria. The out-of-scope list protects the budget from the executives’ “while you’re at it” additions. Stakeholder mapping covers every department moving floors, and a RACI matrix gives each a single point of accountability. The kickoff is a half-day session with the sponsor, the design team, and the contractor’s project manager. The first planning cycle produces a four-level WBS, a critical-path schedule anchored on the lease date, and a budget with 10% contingency plus a client-change allowance. The baseline is approved before any construction spend. The fit-out starts, and the lease date is met.

Which Tools Help You Start a New Project?

The start-up phase produces documents and agreements — charter, stakeholder list, RACI, baseline — and the tool you choose should make those easy to create and impossible to lose. Every option is a trade-off.

Asana — clean task and project management. Pros: fast to set up, good for task-level structure and team collaboration, free tier. Cons: lighter on formal scheduling and cost data. Best for: teams that want a lightweight start and task-level execution.

monday.com — flexible board-based Work OS. Pros: boards adapt to charters, RACI, and status tracking in one place; strong dashboards. Cons: customization takes ownership — someone must design the setup. Best for: teams that want their own structure from day one.

ClickUp — feature-dense platform with tasks, docs, goals, and dashboards. Pros: one workspace for charter, tasks, and tracking; generous free tier. Cons: feature overload can slow the start. Best for: teams that want everything in one place.

Microsoft Project — specialist scheduling software. Pros: deep scheduling and resource planning for the plan that follows the charter. Cons: heavyweight for the start-up documents themselves; steep learning curve. Best for: large projects whose schedule is the center of gravity.

Notion — flexible docs-and-databases workspace. Pros: excellent for charters, stakeholder lists, and RACI as living documents; very adaptable. Cons: needs manual structure; task and scheduling features are lighter. Best for: teams that want a document-first start.

For teams that want the charter, stakeholder list, tasks, schedule, risks, and reports to live in one workspace — so the project starts inside the system where it will run, instead of in a document drive that execution will leave behind — an integrated platform removes the handoff. That is the design of Doitify: an all-in-one platform for project management, team management, and goal achievement, where you turn a goal into a project with tasks, sub-tasks, checklists, and schedules, then manage execution and progress in one unified workspace — with Kanban boards, WBS dependencies, sprints and backlogs, Gantt charts, calendars, resource and workload management, project documents, meeting notes, risks and constraints, milestones, and work and performance reports. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. The trade-off is the same as with any integrated platform — you commit to a system, so pilot it on one project before standardizing your whole team on it. The broader selection picture is covered in our project management overview.

Common Mistakes When Starting a New Project

• Skipping the pre-start checks. Diving straight into tasks means the feasibility problem — an impossible date, an unaffordable scope — is discovered mid-execution instead of in a cheap conversation.
• No charter, or a charter nobody signed. Without a signed charter there is no authorized scope, and every later dispute is a re-litigation of the beginning.
• Vague success criteria. “A successful launch” cannot be verified or defended. Write success so a stranger could check it.
• No out-of-scope list. Scope without exclusions is a boundary that every good idea will cross. Write “not ours” down.
• No single sponsor. A committee with no accountable person cannot unblock the project. Name one person.
• Unclear roles. Without RACI, the responsible-versus-accountable confusion produces blame and dropped deliverables. Assign both per deliverable.
• A kickoff that reads the charter instead of aligning the team. The kickoff’s job is to surface disagreement and build shared understanding — not to announce a plan people will quietly doubt.
• Diving into full detailed planning. Trying to detail-plan six months of uncertain work is fiction-by-committee. Plan the near term in detail and the rest in rolling waves.

Know This Before You Choose

Before you start your next project — and before you pick the way you will run its start-up — answer these honestly:

• Is this problem real, and is a project the right way to solve it, or am I about to build a solution to something that needs a process change instead?
• Can I name the single person accountable for this project’s success, and have they confirmed it in writing?
• Is the deadline actually feasible, or is it a date somebody liked the sound of?
• Have I written success criteria a stranger could verify, and an out-of-scope list that protects the budget?
• Have the users been consulted, or am I about to plan from the sponsor’s assumptions?
• Does every deliverable have a responsible and an accountable owner?
• Where will the charter, plan, and tasks live, and who keeps them current?
• What is my review cadence, and who is going to hold me to it?

Conclusion

Starting a new project the right way is not bureaucracy — it is the cheapest insurance you will ever buy for it. Run the pre-start checks, write and sign the charter, define success criteria and out-of-scope boundaries, name the sponsor and stakeholders, set roles with RACI, run a kickoff that actually aligns the team, and close the start-up with a first planning cycle and an approved baseline. A project started this way begins with an agreement instead of a wish, and every later phase runs on that foundation.

Apply it to your next project, however small: run the three pre-start checks this afternoon, write the one-page charter by the end of the week, and name the sponsor before you create a single task. If you want the charter, stakeholders, tasks, schedules, risks, and reports to live in one workspace from the very first day — so the start-up and the execution are the same system — Explore Doitify Project Management and start your next project where it will actually run.