Project initiation: the calm before the storm or a manic rush to get things sorted and ready for the core work to start? Whichever way it happens, the start of a project is critical to its future success.
From estimating and scoping, to assigning resources, defining requirements, briefing in your team, and the all-important first meeting with the client, there’s a minefield of tasks out there which can shape how your project develops. You have to set the tone for project success.
Based on my personal experience leading projects in technology spaces over the last 10+ years, I’m going to arm you with the tools and information you need to start your project off right and pave an easier future path.
I’m going to walk you through the core aspects of the project initiation phase, how to create protections against future challenges, how to set the right expectations, and what areas to focus on to succeed throughout the project life cycle.
The examples in this article largely refer to projects that include both internal and external stakeholders. This might not always be the case in your projects. If you are working on internal projects, simply shift any reference to external stakeholders to whomever is considered the customer of your project (even if that is a person or group internal to your company).
What Is The Project Initiation Phase?
Before we talk about project initiation, let’s talk about the life cycle of a project. Whatever your chosen methodology or process, every project has to start somewhere, and anything that is a project has a defined beginning, middle, and end. If these elements are not present, then you might be looking at an operations initiative rather than a project.
Any project with a beginning, middle, and end generally has five steps to it: project initiation, project planning, project execution, project monitoring & controlling, and project closure. The initiation phase is the first phase, where the project is kicked off, both with your team and with any clients and stakeholders.
Any information you have (ex. from the pitch, project proposal, or request for proposal stage; from the client; from any background research) is gathered together in order to set and define the project’s scope, timings, and cost.
The project initiation phase is the core set up for your project where you identify the stakeholders, the team, goals and objectives, and deliverables. It is from here that your project is born, so it is essential that you spend time and energy nurturing the project before it gets legs and starts walking.
Why Is The Project Initiation Phase Important?
Taking time to actively manage the project initiation phase can seem unnecessary, especially if the project is already pressed for time or has already started in part, but let me tell you, spending time to get the project initiation phase right is the single most important thing you can do to to help your project achieve its goals longer-term.
Throughout my experience leading projects, both urgent and critical, I have been under pressure. In my early days of leading projects, I made the mistake of skipping the time to properly do the project initiation step, and I paid for it royally each time this happened.
Over time, the pain later on in the project became so consistent and terrible that I knew I had to try to stick up for the project initiation phase.
After pivoting to requiring the project initiation phase in every project, things got better. I was able to successfully understand the requirements for the project, help the sponsor, client, and stakeholders build confidence in my ability to manage the project and I was able to set realistic expectations as to what was happening next because I was able to build trust with the group.
Now, I never skip the project initiation phase because I know that if I do, there will be hell to pay later on in the form of missed expectations, overwork, re-work, scope creep, or poor delivery. All of these problems are mitigated by taking time to get the project initiation phase right.
The Project Initiation Process: 6 Steps
Step 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.
Oftentimes project requestors have a specific symptom of a problem they wish to solve, or might have a big visionary idea about what the future could be if you deliver the project successfully. While this is exciting, this is not enough to understand the scope of the project—you need a lot more information as you gather requirements.
Understanding the scope of the project includes getting solid answers to the following questions:
- What is it exactly that you [project sponsor or requestor] think we’re here to do?
- Why is this important?
- Why is it important to address this now?
- What are the benefits to addressing this project? How are those benefits created?
- What might happen if we do not do this project?
- Who is expected to be involved in this project? How does the project impact them?
- Who will sponsor the project?
- What happens if we need more resources or the problem is bigger than we understood at the outset?
- What are the known issues revolving around this project?
- Has anyone attempted this project before? If so, what happened?
Once you have the answers to these 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.
You can find more key project initiation questions to ask here.
Step 2: Validate the scope with impacted stakeholders
Once you have gathered the basic information about the requested project in step 1, you can begin step 2 which requires you to go to the various impacted stakeholders and effectively pitch your version and your understanding of the project to them, as if you were beginning to ask for their help or gather feedback from people that will be impacted by the project.
This step is sometimes called a feasibility study, but for my purposes I like this to be a little more open and flexible.
It is in this stage that your perception of the problem will likely evolve. This is often because the person requesting the project doesn’t have a full picture of how everything is connected, or how different impacted groups may react to the change.
For example, a systems implementation project might look simple to the person that 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.
In this step, 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.
It can feel like people are fighting you, or wanting to stop you dead in your tracks.
You can manage and mitigate this by framing the conversation as exploratory, and that you’re seeking feedback from the stakeholders so that you can provide feedback to the project requestor and ultimately build a solution that meets the needs of multiple stakeholders, not just the person that asked you to undertake the project.
Once you have a more illuminated view of the problem and the project scope, provide feedback and findings to the project stakeholder with an update of what you’ve found, and proceed to the next step, assembling the required resources and gathering even more feedback.
Step 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.
If the team members or their managers haven’t yet heard of your project, note this to your project sponsor or requestor, so they can help provide more visibility and awareness around the project throughout the organization.
Planning Your Team Shape
When considering which team members (and how many) you will need to accomplish the project goals, review your project and deliverables and work out what team shape you need. Check availability, and get your resources provisionally booked in.
When you’re thinking about who to book on a project, don’t just look at availability—you really need to think about what skills you need to deliver your project successfully. Think about the client or stakeholders here too: how will your team members work with them?
Run through the following checklist when forming your team:
- Skills (what will they need to do)
- Experience (what will they need to have worked on before)
- Stakeholders (how will they need to communicate)
- Availability (will they have to the time to dedicate)
- Budget (can you afford them)
Remember, don’t do this in isolation. Speak to the varying discipline leads if you have them, make sure you aren’t making assumptions on your own. It’s good to hold a quick meeting with the leads upfront, to run through the project and deliverables and get their help in outlining the resource requirements.
Working through the above should give you a team shape for your project, but remember to leave some contingency time before the proper project kickoff in case you need to look outside your organization for skills that freelancers or contractors might be able to provide.
Once you have the right people committed to taking a look, gather the group and present the project again. Tell them as much as you know about the project and ask for feedback about how the goals could be met, what might not be feasible, and what might trip up the team on their journey towards achieving the goals.
Again, you might be met with a lot of resistance. That’s normal. Write down all of the considerations that people bring up, both positive and negative. Put this information in a space that is accessible for all, and summarize your findings back to the project sponsor.
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 to gauge their interest in either committing more resources and time to the project or deciding to go a different direction all together.
It is at this time also that you can begin sharing the project charter documents with collaborators that might want input as to what you will be presenting to the project sponsor or requestor.
In my experience, sharing is better than keeping this to yourself. People generally don’t read things they are not worried about or interested in, so don’t worry too much about people reading something that may not be final.
Typically, when people engage, it is to help you, even if that “help” is in the form of information about things that might go wrong.
Don’t ignore these folks and these messages, as they usually aren’t wrong, even though you might not have enough information to understand them yet. Write their concerns down, engage with their feedback, and incorporate their fears into your risk register and risk management plan.
Step 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.
Defining Who Is Involved 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.
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. Make sure you get people to feed into these—don’t determine these in isolation!
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):
|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|
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.
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.
Again, don’t force a process onto a project—make sure the process fits the project. Agree on the team shape, and then put costs against this.
At this stage, for the PID or SoW, you don’t need a detailed breakdown of timings, but rather an overview of phases of time.
Measures Of Success
What is your project or product without success? But what does success even mean?
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
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.
Step 5: Organize your team and tools and prepare to launch
The goal of step 5 is to get your team, methodology, and tools ready to go such 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 that shared concerns see those concerns reflected as risks that you and the team will actively monitor and manage.
Getting The Team Involved: Kicking Off The Right Way
It’s good to precede any client kickoff with an internal kickoff session. This helps to get their buy-in and involvement in the project early. When setting requirements, team shape, and objectives, always remember that it’s best keeping people involved and aware.
You don’t want to add loads of overhead (and it’s often tricky to get people involved when they are busy!), but the best way to kickoff a project is to set and manage expectations early.
By getting your team involved upfront, they will feel more included and involved in the decision making and therefore have a much more positive impression of the project as a whole.
So, hold an internal kickoff session. Set up a meeting with an agenda (always make sure a meeting is useful and for the right people) and run through the background to the project, any objectives and goals, and any requirements that are already set. Something I’ve found useful is to leave space at the end of the meeting for a more workshop-like forum to gather team thoughts.
Some good areas to discuss and raise early are:
- How do the team want to work?
- How and when should the team get client or stakeholder feedback?
- How do the team want to communicate with the client or stakeholder feedback?
- What regular meetings should the team have internally? When should these be?
- Should catch-ups be ad-hoc and informal, or more planned upfront?
Like I said, getting team involvement in decision-making upfront is likely to make them feel more invested with the project as a whole. Getting this meeting in before the SoW is completed can help feed the team’s proposed ways of working into the document, making it much more relevant to how the project is actually going to run.
Setting Project Communications
As part of the SoW or PID, it’s useful to define when and how communications will take place with the stakeholders. After creating your RACI, review what you feel is necessary for updates and meetings with your core stakeholders.
If there is a clear project lead client-side, then starting out with how often you formally update them is a good way to approach this.
Then, widen this out to others on the team and when their involvement should be. List out the project updates you feel are necessary, then fill out the who and when.
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|
This is the age-old obsession in project management—which methodology to follow? This might be clear already by how your client works, or how your agency or team are set up, for example. 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 methodologies—don’t be worried by this; always think about what is best for the project rather than trying to force it to fit a certain methodology.
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?
Using answers to the above questions, you should be able to have a clearer idea of what type of project it is and therefore how it should be run.
For example, if all scope, timings, and budget are set, the project will be more waterfall, or if you have a full-time dedicated team with a fully invested project lead on the client side, this could lend itself more to an agile-style project.
Another PM obsession: what are the right project management tools to use for the project? Well, again, this really depends on your project, your team, your client, and your budget!
As I’ve said throughout, you want to avoid heavy processes and the same goes for tools—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, ex. Float or Resource Guru
- Project planning software, ex. Microsoft Project or Gantt Pro
- Collaboration software for use with stakeholders, ex. Google Sheets or Confluence
- Communication software for use with your team and stakeholders, ex. Slack or Workspace
- Project management software for internal tasks, ex. 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.
Step 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.
Stakeholder Kickoff Meeting
As a pre-flight check to the kickoff meeting, make sure you’ve had your internal kickoff meeting with the people that will contribute to delivering the project outcomes. Don’t throw team members into a meeting about a project they know nothing about.
Also, it’s good to have already introduced yourself to the client or stakeholders involved prior to the meeting, either over the phone or ideally in person. Make sure you have a clear agenda, and don’t invite the whole world to the meeting. Always remember to keep a meeting contained and relevant.
Things to run through in the meeting:
- Roles and responsibilities
- Key stakeholders and decision-makers
- Project objectives, deliverables, and milestones
- Project risks, both positive and negative
- Dependencies and project constraints
- Timings and other change considerations
- Costs and expected return on investment
- 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.
8 Key Documents In The Project Initiation Phase
In the project initiation phase, a few key documents are often used to define the project scope and begin to document the assumptions, dependencies, risks, and more. The key documents often include:
- Business case: The case for why the project should be considered
- Project charter: The overview of the project, from the PMs view
- Project initiation document: Basic information about the project
- Statement of work: Customer-facing documents describing the product, timelines, etc. This is sometimes a contractual document, especially in the case of external clients.
- Assumptions list: Documentation of the assumptions considered when creating the project documents and initial plans.
- RACI chart: List of who is responsible, accountable, consulted, and informed throughout the life cycle of the project; this may change over time.
- Risk register and issue log: List of key risks (positive and negative) that were uncovered during the initiation phase; this may change over time.
- 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 Core Challenges When Initiating Projects—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
It’s often the case at the beginning of a project that everyone takes a little more time over what they have to do, and everything is a bit more relaxed—after all, you’ve got lots of time now to do the project!
Sometimes though, project initiations can start to drag out 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.
Here are some tips to ensure you move at the right pace:
- Have calls or meetings to discuss and agree to things—this can often help speed things up rather than having a lot of back and forth on 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 half-way through, or at the beginning of a certain phase? It can be really tricky as you haven’t been involved in the initiation stage.
Try these tips:
- 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 span the lifetime of your project.
So try the following:
- 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.
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 do you overcome these kickoff 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.
Top Ten Tips To Remember When Initiating A Project
- Set the tone that you want for your project early on.
- Get your team’s buy-in and involvement early.
- This goes for the client too—get them involved early and often.
- Make sure clear communications are set up with any clients or stakeholders.
- Ensure there’s an agreed upon process for your project to follow—but don’t become bogged down in documentation!
- But don’t try to fit a specific process if it doesn’t work for your project.
- Try to meet your client face-to-face at least once before kicking off the project (if this is impossible, do a video call!)
- For any kickoff meeting, set a clear agenda and make people feel involved.
- Try and future-proof your project by thinking through risks and dependencies with your team.
- Always think ahead—don’t just focus on the start of the project!
Project Initiation Checklist
Here’s a handy checklist, covering the key elements you need to cover when going through project initiation.
Define team shape
Agree on ways of working
Book provisional resources
Run an internal kickoff
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
Gather existing known requirements
Outline project goals & objective
Review & define deliverables
Create top-level timings plan
Create estimate based on deliverables, timings, & team shape
What Do You Think?
Are there any other areas to consider when initiating a project? Let me know your thoughts in the comments below!