Project Initiation Guide: 6 Steps To Start Right

What Is Project Initiation?

Project initiation is the first phase of the project management lifecycle, where teams define the project’s goals, scope, stakeholders, budget, timeline, and overall feasibility before work begins.

The purpose of project initiation is to align teams, gather the right resources and project management software, clarify expectations, identify risks, and create a strong foundation for successful project delivery.

Why Is The Project Initiation Phase Important?

The project initiation phase is important because it forms the core setup for your project. You identify the stakeholders, the team, project goals, objectives, and deliverables. The project initiation phase matters because it helps you:

• Successfully understand the requirements for the project
• Set realistic expectations as to what was happening next 
• Build trust with the group, including the sponsor, client, and stakeholders
• Avoid overwork, re-work, scope creep, or poor delivery

The Project Initiation Process: 6 Steps

Here are the six important steps involved in the project initiation process.

1. Understand the scope of the project

The first step to initiating a project is getting an understanding of the scope of the project, typically from the project sponsor or key client contact. Understanding the scope of the project includes getting solid answers to the following questions: 

1. What is it exactly that you [project sponsor or requestor] think we’re here to do? 
2. Why is this important? 
3. Why is it important to address this now? 
4. What are the benefits to addressing this project? How are those benefits created? 
5. What might happen if we do not do this project? 
6. Who is expected to be involved in this project? How does the project impact them? 
7. Who will sponsor the project? 
8. What happens if we need more resources or the problem is bigger than we understood at the outset? 
9. What are the known issues revolving around this project? 
10. Has anyone attempted this project before? If so, what happened? 

Once you have the answers to these project initiation questions, you can begin to get an understanding of the reason for the project and the key objectives to attempting the project, and you can also get a sense of what you will need to get started.

2. Validate the scope

The second step involves pitching your version and your understanding of the project to the various impacted stakeholders. This step is sometimes called a feasibility study, but for my purposes, I like this to be a little more open and flexible. 

You are validating the scope with impacted stakeholders and getting a ton more information about how everything is put together and how the requested project will influence changes across the organizational landscape.

For example, a systems implementation project might look simple to the person who wants the new system, but the downstream effects of changing processes across the company, such as processes that have historically relied on another tool, can include significant fear, distress, and debate as to if the implementation is a good idea at all.  

Pro Tip

As you engage in this stage, you will be met with a significant amount of fear and roadblocks from stakeholders that are to be impacted by the change. This is normal. Take the fears and considerations seriously; write them all down. You might not understand them all yet, but you will in due time, and you’ll want the notes to come back to.

Once you have a clearer, proof-of-concept understanding of the problem and the project scope, provide your feedback and findings to the project stakeholder. Give them an update on what you’ve found, and then proceed to the next step: assembling the required resources and gathering even more feedback. 

3. Assemble the required resources, gather feedback

It's time to assemble the resources that will be required to facilitate the project and gather even more feedback from these individuals. Begin by approaching the managers of the team members you think you might need on the project, position the endeavor, and ask for help from them and their team. 

At this point, you likely have enough information such that you can begin to build a high-level project plan, or there might be enough things standing in the team’s way that you have to go back to the project sponsor.

4. Set realistic expectations for the project

Once you’ve gathered feedback from everyone close to the project, it's time to set some expectations about how it will all go, or at least how it will start. This stage requires a significant amount of negotiation and documentation—it can be thought of as pre-planning for a project. 

Lead Smarter in the Age of AI

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

Sign up with LinkedIn

Or sign up with email:

Name

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Define Who Is Involved in The Project And When

Here, you’ll outline and define the stakeholder involvement. Whether this is client or internal stakeholders, it’s really important to be clear on who is doing tasks, signing off on deliverables, or reviewing and providing feedback. 

Creating a RACI chart is a great way to do this. I’ve written an article which dives into RACI charts and helps you create a RACI that is useful.

Define Project Deliverables

At this stage of the project, you have an idea of what the deliverables are. Now’s the time to start fleshing this out and putting some perimeters around them, in order to be able to agree to these in the SoW or PID.

Take the information you have and organize an internal meeting to go through the deliverables with your team. If your team isn’t yet in place and you need to push forward with setting the deliverables, meet with the discipline leads.

When you review with your team, make sure you have these areas in mind to review per deliverable:

• What is it?
• What format will it be in?
• Will rounds of amends be necessary?
• Who will be involved?
• When should this be delivered?
• Does it have dependencies on any other deliverables?

Here’s an example, from a recent project of mine (I’ve made it a bit more generic):

	Deliverable	Description
1.	Initial approach to fundamental design Format: Design files (Sketch), sent for feedback using InVision Amends: Iterative until 16/02/18	[My agency] will define an initial approach to the fundamental design that is necessary as part of Stage 1 of this project. The fundamentals needed will be mapped from the 3 agreed platforms that are the focus of Stage 1. Fundamentals will include Typography, Grid, Colors, and Icons.  The aim is to set these fundamentals to inform the initial design treatment and also future design in other stages.
2.	Component inventory and prioritization Format: Documentation Amends: Iterative until 16/02/18	[Client] will supply a component inventory to [my Agency], and [my Agency] will review this and the 3 identified platforms to create a component list.[My Agency] will then prioritize these components on a ‘remove, improve, reuse’ basis, and cluster into categories. The components will be checked across the 3 platforms to identify where common components are used. This component inventory and prioritization will identify which are the core components needed for the content to be delivered in the prototype.

Define Project Budgets and Timings

Following on from your list of deliverables, you now have a rough project scope, and you need to put timings and roles against this. Work with your discipline leads to estimate timings and the team shape against this.

Depending on the process, you might be estimating in sprints or in phases with sign-offs. Make sure you work with the team on these, to set the right perimeters.

Define Measures of Success

Don’t forget that your project also needs some sort of measurement, so that you can review and understand where things worked or didn’t work, and how successfully you delivered. Create some measurement criteria that you’ll review at the end (or at certain stages along the project).

Consider areas such as:

• Core KPIs, ex. increasing visitors to a site
• Client satisfaction, ie. How happy were the clients with how the project went?
• Team satisfaction, ie. How happy were the team with how the project went?
• Timings variance
• Budget variance

Consider Risks

Thinking ahead is one of the best things that you can do in the project initiation phase. Establishing risks that might keep the project from delivering is extremely important to do upfront. 

Create a RAID log to highlight risks, assumptions, issues, and dependencies, and also work through how you will mitigate these.

Make sure you involve your team, and consider holding a pre-mortem session with your team where you brainstorm areas of risk, as they are often likely to come up with things you haven’t even thought of.

5. Organize your team and tools

The goal of step 5 is to get your team, methodology, and tools ready to go so that you can hit the ground running with your team.

Publish the documents you have been working on in the previous steps, and be sure that the people on the team who shared concerns see those concerns reflected as risks that you and the team will actively monitor and manage. 

As part of the SoW or PID, it’s useful to define when and how communications will take place with the stakeholders. Here’s an example:

Meeting/Comms	Who	When
Stand up	All internal people actively engaged on this project phase	Daily
Weekly status report	Sent to project lead, project lead to circulate to wider team	Weekly, Monday end of day
Weekly review	Project lead and core stakeholders	Weekly, Friday 10AM
Fortnightly status update	Wider team	Every two weeks, Tuesday 10AM

6. Launch!

The final step in the initiation phase is to get the team together and hold a formal kickoff meeting! This is an exciting step in the project management life cycle and is a stake in the ground for you as a leader of the project and the team for what they are committing to. 

Things to run through in the meeting:

• Introductions
• Roles and responsibilities
• Key stakeholders and decision-makers
• Project objectives, deliverables, and milestones
• Assumptions
• Project risks, both positive and negative
• Dependencies and project constraints
• Timings and other change considerations
• Costs and expected return on investment
• Metrics
• Team shape

With this kickoff complete, you are well on your way towards delivering successful project outcomes. You can now close the initiation phase of project management and move on to the next step in the Project Management Institute’s (PMI) described workflow, the planning phase.

Project Initiation Checklist

Here’s a handy checklist covering the key elements you need to cover when going through project initiation.

What?	Items To Check
People	Internal Define team shape Agree on ways of working Book provisional resources Run an internal kickoff External Define stakeholders involved Create and agree on RACI for roles & responsibilities Run a client kickoff
Process	Define project process Agree on and set up tools Create RAID log for risks Create SoW or PID
Product	Requirements Gather existing known requirements Outline project goals & objective Review & define deliverables Delivery Outline Create top-level timings plan Create estimate based on deliverables, timings, & team shape

8 Key Documents In The Project Initiation Phase

The outcome of the project initiation phase is generally eight specific documents:

1. Business case: The case for why the project should be considered
2. Project charter: The overview of the project, from the PMs view
3. Project initiation document (PID): Basic information about the project
4. Statement of work (SoW): Customer-facing documents describing the product, timelines, etc. This is sometimes a contractual document, especially in the case of external clients. 
5. Assumptions list: Documentation of the assumptions considered when creating the project documents and initial plans.
6. RACI chart: List of who is responsible, accountable, consulted, and informed throughout the life cycle of the project; this may change over time.
7. Risk register and issue log: List of key risks (positive and negative) that were uncovered during the initiation phase; this may change over time. 
8. Project communication plan: Describes who will be informed about what, when, by who, and in what method. 

While this is not an exhaustive list, these are common elements of the initiation stage. When you are initiating a project, don’t constrain yourself to these documents. 

Pretty much everything you learn about the project you are about to undertake is valuable, and I highly suggest capturing as much information as you can, even if you’re not sure what to do with it yet. As you learn more about the challenges at play, the information you collected at the outset will make much more sense. 

5 Project Initiation Challenges—And How To Overcome Them

There are many challenges you can face within the project initiation stage. Below, I’ve outlined five key challenges I’ve often come across when going through project initiation, and how to mitigate them. 

1. The Project Initiation Stage Is Going Too Slowly

Sometimes, project initiations can start to drag on too long. I’ve seen this many times, and it can really affect the project down the line when you’re struggling to deliver to the timings that you’ve promised. 

How To Move The Project At The Right Pace

Here are some tips to ensure you move at the right pace:

• Have calls or meetings to discuss and agree on things. This can often help speed things up rather than having a lot of back and forth via email.
• Ensure the client and team know what their deliverables are for the project initiation stage and any dependencies that rest on them. Highlight straight away if they are blocking anything moving forward.
• Set overall timings for this phase. Pre-kickoff, it’s often easy to meander along, so make sure there’s a clear goal to work towards
• Think about team and client momentum. How do you get people engaged and motivated, and make it clear that progress is being made? As the project initiation phase is less about the doing and more about the setting the scene, try and find tangible things you and the team can do to help make the project more real.

2. Picking Up A Project Mid-Way Through

Often, a lot of advice I read for project management assumes that you are starting at the very beginning of a project and can lead it from the start.

But what if you are brought into the project halfway through, or at the beginning of a certain phase? It can be really tricky as you haven’t been involved in the initiation stage. 

How To Pick Up A Project Mid-Way

Try these tips when you’re taking on a project mid-way:

• Make sure that you are clear on everything that has happened previously. If someone is handing over to you, ask them to provide a list of links, deliverables and associated status, and any links to important documents.
• Set up project kickoffs with your team, and then the stakeholders, just as you would in project initiation at the ‘real’ start of the project. Although you don’t want your team or client to have to repeat things, they will appreciate that you need to get up to speed, and also it’s a good way to reset the team and move forward with a new project lead. 
• It’s also a nice point to have a mid-way project review—you can go through existing risks or the current burn rate on the budget, to make sure everyone is still aligned.

3. Having One Project Initiation For A Project Spanning Multiple Phases

One core problem with a large and long-running project is only having one initiation right at the beginning of the project and then never resetting as you go into different phases. What is decided for one phase doesn’t necessarily count across all phases and spans the lifetime of your project. 

How To Handle A Project With Multiple Phases

Try the following for a multi-phase project:

• If your project has clear different phases, for example a discovery phase separate from the development, treat each phase like a mini-project rather than doing a bigger upfront piece. This provides key starting points for each phase, rather than trying to make a lot of assumptions at the beginning.
• Do mini kickoffs at each stage and make sure you’ve gone through the project initiation checklist and have covered off each item within that for the specific phase.

4. There’s A Lack Of Clarity Around The Project

Sometimes, when you get started on the project initiation phase, things can feel a bit vague, and project team members are confused about what the project actually is. 

How To Provide Clarity Around The Project

Make sure you look at the following to create alignment within your team:

• Ensure you have a clear list of requirements from the client. Make sure you’re including business, user, and technical requirements within this.
• Run through these requirements with your team if you have one allocated. If not, make sure you have discipline leads involved. Make sure people are engaged from the beginning.
• Once you’ve held internal and client kickoffs, keep the momentum up within the team—make sure the team knows what they are delivering and are invested in it.
• Always involve the team in the setting of the brief, definition of deliverables, and approach to the project.

5. There’s A Delay In Getting Your Project Started

Have you ever got all excited around a project getting started, gathering all requirements, defining a plan and next steps, and then, something happens to delay the start? Momentum is lost and your proposed project team disperse. 

How To Overcome Project Kickoff Delays

Here are some tips to avoid delays:

• If there’s discussion over the project budget, make sure you run through all budget decisions with the client properly—what are they getting for their money? Be as clear as you can be.
• If they can’t afford your proposed budget, look at the scope statement—is there anything there you can remove? Have an open and honest discussion with them to try and work out a compromise.
• To get things moving quickly, try to get a small amount of budget signed off for a discovery phase.
• If the client isn’t getting involved or is missing early deadlines, make sure you raise this with them quickly—help them to understand what impact this will have on the project.
• If there are internal issues with getting the team in place, or getting going with the work, raise this internally. Again, help your internal team and management to understand the impact of the project slipping.

10 Common Project Initiation Mistakes To Avoid

Even well-planned projects can fail if the initiation phase is rushed or poorly managed. Avoiding these common mistakes can help teams improve alignment, reduce risks, and set a stronger foundation for project success.

1. Starting without clear objectives: Vague goals make it difficult to measure success, align stakeholders, or prioritize work effectively. Every project should begin with clearly defined outcomes and success criteria.
2. Ignoring stakeholder input: Failing to involve stakeholders early can lead to misalignment, resistance, and conflicting expectations later in the project lifecycle.
3. Defining scope too loosely: An unclear or overly broad scope increases the risk of scope creep, shifting priorities, and budget overruns.
4. Overlooking project risks: Teams often focus heavily on deliverables and timelines while ignoring potential risks. Identifying risks early helps prevent costly surprises later.
5. Rushing into execution too quickly: Jumping straight into tasks before proper alignment and approvals are in place can create confusion, rework, and delays.
6. Failing to document assumptions: Assumptions around timelines, resources, budgets, or dependencies should be documented early to avoid misunderstandings during execution.
7. Not defining ownership and accountability: Without clear leadership and decision-making authority, projects can stall due to confusion around responsibilities.
8. Skipping feasibility or resource checks: Starting a project without validating available resources, timelines, or technical feasibility can set unrealistic expectations from day one.
9. Poor communication during kickoff: If teams and stakeholders aren’t aligned on goals, responsibilities, and expectations from the beginning, communication gaps can quickly derail progress.
10. Treating initiation as a formality: Some teams rush through project initiation just to “get started.” In reality, this phase lays the foundation for the entire project and directly impacts long-term success.

Top Ten Tips To Remember When Initiating A Project

The best project initiation practices help teams define goals, align stakeholders, reduce risks, and build a strong foundation for project success from day one. Here are 10 tips to follow:

1. Set the tone that you want for your project early on.
2. Get your team’s buy-in and involvement early.
3. This goes for the client too—get them involved early and often.
4. Make sure clear communications are set up with any clients or stakeholders.
5. Ensure there’s an agreed upon process for your project to follow—but don’t become bogged down in documentation!
6. But don’t try to fit a specific process if it doesn’t work for your project.
7. Try to meet your client face-to-face at least once before kicking off the project (if this is impossible, do a video call!)
8. For any kickoff meeting, set a clear agenda and make people feel involved.
9. Try and future-proof your project by thinking through risks and dependencies with your team.
10. Always think ahead—don’t just focus on the start of the project!

FAQs

What would happen if I skipped project initiation?

Skipping project initiation often leads to problems later in the project lifecycle, including:

• Misaligned stakeholder expectations
• Unclear project goals
• Scope creep
• Budget overruns
• Resource conflicts
• Delays and rework
• Increased project risk

Without a clear initiation process, teams may start executing before they fully understand what success looks like or why the project matters.

What’s the difference between project initiation and project planning?

Project initiation is the phase where you define the project at a high level and determine whether it’s worth pursuing. This includes identifying goals, stakeholders, business value, scope, risks, and overall feasibility.

Project planning comes after initiation. During planning, you build the detailed roadmap for execution, including timelines, budgets, resource allocation, communication plans, and task breakdowns.

The steps answer two different questions:

• Project initiation: Should we do this project?
• Project planning: How exactly will we do it?

Without proper initiation, planning often happens around unclear goals or unrealistic expectations.

How long should the project initiation phase last?

The length of project initiation depends on the project’s size, complexity, and level of risk.

Here’s a general guideline:

Project Type	Typical Initiation Length
Small internal projects	A few days to 1 week
Medium business projects	1–3 weeks
Large enterprise initiatives	Several weeks to months

Is project initiation part of the work breakdown structure (WBS)?

Not exactly. The work breakdown structure is created during the planning phase to break the project into smaller deliverables and tasks. However, project initiation activities can appear as a high-level section within the WBS if the organization tracks all project phases together. For example:

1. Project initiation
2. Project planning
3. Project execution
4. Monitoring and control
5. Project closure

So while initiation influences the WBS, it’s generally considered a separate project management phase rather than a component of the WBS itself.

What’s the difference between a project charter and a project initiation document (PID)?

A project charter is a short, high-level document that formally authorizes the project. It defines the project’s purpose, stakeholders, and overall objectives.

A project initiation document (PID) is more detailed. It expands on the charter and explains how the project will be managed, controlled, and delivered.

In many organizations, the charter is created first to secure approval, while the PID serves as the operational foundation for the project team.

Aspect	Project Charter	Project Initiation Document (PID)
Purpose	Officially authorizes the project	Defines how the project will be managed and executed
Level of Detail	High-level overview	Comprehensive and detailed
Created During	Project initiation	End of initiation/start of planning
Primary Audience	Sponsors and executives	Project team, managers, and stakeholders
Focus	Business case and project approval	Delivery approach and project controls
Typical Contents	Objectives, scope summary, budget estimate, stakeholders, success criteria	Scope details, governance, timelines, risks, communication plans, resources
Length	Usually short (1–3 pages)	Often longer and more detailed
Approval Role	Confirms the project can begin	Confirms the project is ready for execution

How do I choose a project methodology?

Choose a project methodology based on how your client works, or how your agency or team are set up. Ideally, though, you review the project, deliverables, and team, and then find a process that will suit the needs.

Often, it’s a blended mix of different project methodologies. Think about the following things when considering the methodology:

• What is the size of your project?
• How fixed are the scope, timings, and budget?
• What team do you have to work on it?
• Do you have a full-time team or are they shared with other projects?
• How does the client currently work?
• Will you have a fully invested client project lead?

 

How do I decide on the project management tools?

Project management tools depend on your project, your team, your client, and your budget. You want to avoid throwing lots of unnecessary tools into the mix and consider how well they integrate. Some tools to consider are:

• Requirements management tools to align stakeholders and avoid confusion.
• Resource management and planning software, e.g. Float or Resource Guru
• Project planning software, e.g. Microsoft Project or Gantt Pro
• Collaboration software for use with stakeholders, e.g. Google Sheets or Confluence
• Project scheduling software (you can often get free scheduling tools as well) to help delegate tasks and keep the project on track
• Communication software for use with your team and stakeholders, ex. Slack or Workspace
• Project management software for internal tasks, e.g. Jira or Trello

Personally, I’m all for keeping things simple, and I often find myself using Google Sheets for a lot of things.

Whichever tools you use, ensure your internal team and stakeholders are in agreement and know how to use them effectively. Avoid over-complicating things, and you can always refine the tools later in the project if you find things aren’t working.

What's Next?

Want to connect with other digital project managers to share resources and best practices? Join our membership community and get access to 100+ templates, samples, and examples and connect with 100s of other digital project managers in Slack.