Initiating a Project

Introduction to the Initiation Phase

I'm all for Read-Fire-Aim tactics, but kick-starting a project isn't about jumping in headfirst; you've got to set the stage first, or chaos will reign, even in the simplest of projects.

In the initiation phase, you line up the dominoes to ensure they fall just right; we're setting up its entire trajectory. It's more than choosing the right folder structure, picking a killer project code name, and doing a bit of crystal ball gazing.

As humans, we just can't help it when we start something new - naivety and optimism run away hand-in-hand, telling us it's all going to go well and it'll be completed within a week or two. We can't help it. We are hard-wired for something referred to as 'reckless optimism'.

Spoiler alert: it never goes easily. If any project manager tells you it always does because they have the 'formula' to guarantee success, they are peddling snake oil.

Something always causes the project to derail to a greater or lesser extent. It's about preparing well and managing the issues effectively when they do happen. But we run ahead of ourselves, so more on that later.

In the initiation phase, we're pulling together the big pieces and the tiny details that'll define the entire project. This is the critical first play in our game plan, where we establish what needs to be done, who will be on our team, and whether the whole thing is feasible. Getting this right means everything that follows can have the best chance of success —or at least as close to it as possible.

It's all about foundations.

Think of it as laying down the keel of a ship. The initiation phase holds everything else up, so we must ensure it's rock solid. If done right, we're on our way to a smooth sail; if not, it's anyone's guess.

Let's get into how we do this right, doing the best we can to ensure our project is something everyone will remember for the right reasons.

[Diagram showing relationship to other phases]

The Main Activities of Project Initiation

Key Steps	Activities	Outputs
Creating the Project Charter	Drafting the initial document Consulting stakeholders for feedback Finalising and getting formal approval	Approved Project Charter
Assembling the Project Team	Selecting team members based on criteria Defining roles and responsibilities Conducting initial team meeting	Assembled project team Defined roles and responsibilities
Undertaking Initial Assessments	Conducting technical, economic, and legal feasibility studies Developing a high-level risk register Outlining preliminary delivery methods	Feasibility study reports Initial high-level risk Preliminary project delivery plan
Developing a High-Level Plan	Drafting the plan Iterating based on feedback Seeking preliminary approval	High-level project plan
Planning Gate Approval	Reviewing the high-level plan Integrating stakeholder feedback Making go/no-go decision	Decision on proceeding with the project Adjusted project scope if necessary

Create the Project Charter

Importance of the Project Charter

The charter sets out the "what" and the "who," defining not just the boundaries of the project but also who has the authority to do what.

The Project Charter isn't just creating documentation for the sake of it; it's the green light for the project and, I'd argue, probably the most crucial document of the entire project.

I see the charter as the bedrock upon which everything else will be built.

It's about getting everyone on the same page—literally.

Sometimes, fireworks fly when you put the charter before stakeholders because of differing opinions, and that's a good thing to flush out early on.

Getting the charter right means securing an upfront commitment from upper management and a clear mandate for the project manager to know what they need to achieve and the parameters within which the project needs to operate.

Key Components of the Project  Charter

• Project Scope: This is where you draw the line in the sand. It's about defining what's in and, very importantly, what's out. Keeping the scope tight and well-defined helps avoid the dreaded scope creep and keeps everyone focused.

• Objectives and Goals: Here's where the aspirations for the project are penned down. Concrete, achievable, measurable goals to see if they are achieved. This section ties the project back to tangible business outcomes, making it relevant and justified.

• Project Justification: We must ask ourselves, "Why are we doing this?" This part needs to make the case loud and clear. Whether it's market demand, a business need, or a strategic opportunity, this is your chance to determine why this project matters. One of my biggest mistakes was to allow a CEO to state, "I am the business case!". We sold 2 copies of the product, which cost upwards of £500k.

• Main Stakeholders: Who's in this? Identifying key players and their roles early prevents confusion and sets the stage for effective engagement. Knowing who has a stake in the project outlines the network of influence and support needed to push the project forward.

Steps to Draft and Approve the Project Charter

Drafting the Charter

Start with a draft that captures all the essentials: scope, goals, justification, and stakeholders. This isn't about perfection; it's about direction and clarity. Get something written down.

Consultation and Feedback: Share the draft with key stakeholders. This isn't just about getting approval but engaging them to refine and enhance the document. Feedback at this stage can save a lot of headaches later.

Final Approval: Once the charter is polished and everyone has had their say, it's time for the formal sign-off. This approval is the project's official go-ahead, so ensure it's documented.

Assemble the Core Project Team

Criteria for Selecting Team Members

Picking may or may not be something the Project Manager can influence. You need experience, energy, expertise, enthusiasm, intelligence, dexterity, and wizardry skills.

Here's how you do it:

Skill Match

Obviously, you need people who know their stuff. Whether technical prowess, project management expertise, or specific subject knowledge, the team's skills should align closely with the project's requirements.

Team Dynamics

It's not just what you can do; it's how you work together. Look for individuals who bring skills and the right attitude to the table.

Give me someone enthusiastic, hard-working, and inexperienced over someone lazy and disruptive but skilled any day.

Availability

Realistically, you need people available to dedicate the required time to your project. Overcommitted team members are a recipe for project delays.

Roles and Responsibilities of the Project Team

Once you've got your team, setting clear roles and responsibilities is crucial.

I just want to underline that it needn't be complicated. Indeed, the smaller the project and team, the less need for vast amounts of detail, but it is still essential to iron out. You can probably capture it in a table format within a document, but it is important to clearly define who's responsible for what.

If you don't, ambiguity slips in, people don't do things you expect them to do, and they'll shrug and say, "I didn't know that was me."

Here's how to ensure everyone knows what they're supposed to do.

• Clear Definitions: Each team member should have a clear description of their role and what's expected of them. This clarity helps prevent overlaps and gaps.

• Authority Levels: Just as critical as roles are the authority levels. Make sure people know what decisions they can make and what needs to be escalated. This is important to capture because they might sit on issues that should otherwise have been escalated. Equally, you'll want people to feel they can solve problems however they see fit.

• Interdependencies: Highlight how team members' roles interlink and depend on each other. Understanding these connections helps foster collaboration and prevents bottlenecks.

Conduct The Initial Briefing

Bring everyone together for a kick-off meeting. This isn't just about walking through the project charter; it's about building a team spirit and opening lines of communication.

Make it interactive, not a lecture. Seek input regarding pitfalls and potential dependencies you might not have seen.

Undertake Initial Assessments

Conduct Feasibility Studies

Before diving too deep, you've got to check the water is okay. Feasibility studies are your first reality check.

There can be several perspectives to a feasibility study, but typically, they could be based on the following:

Technical Feasibility

Can we actually do this? It's about determining whether the technical resources and capabilities are available to deliver on the project's objectives. Will you do it yourself and try to save money (no), or bring in expertise (yes)?

Economic Assessment

Does it make sense money-wise? This involves crunching the numbers at a high level to see if the project's benefits outweigh the costs. It's about ensuring that the project is economically viable.

Legal Considerations

Are we clear on the legal front? This includes checking for regulatory requirements or legal constraints that could impact the project. Don't underestimate this in a world where increasing regulatory compliance and things like GDPR and Data Protection regulations shape how we must approach so much.

For a smaller project, you may not need to go into detailed feasibility studies but don't underestimate it or dismiss it out of hand. Think to yourself;

• What are the influences that might impact my project and its outcome? For example, are there regulatory aspects we need to investigate that might influence how we go about our project?

• Are there different ways to approach this project delivery, and what's the best option? For example, should we build, buy, or outsource it to someone else?

• Do we have the skills to deliver and support this if we build it?

Feasibility studies may even go as far as a brief proof of concept or supplier evaluations. So, this step may be far more involved than it first appears.

Develop a High-Level Risk Register

No project is without risks, but not all risks are created equal. I don't try to seek out every single risk anyone can think of, but only the large ones that would keep me awake at night if they were to start materialising.

For example, my immediate thoughts would be;

• Is anyone on the project a single point of failure that would disrupt the project if unavailable for some time? So, have we hinged the entire delivery on someone who might be brilliant but erratic?

• Is my supplier in robust financial shape? Have they got a proven track record, or are they attempting to do something they haven't done before?

• If there was a delay to a particular delivery, would it cause a disruption to the entire project, and if so, can we have a mitigation plan?

Evaluating & Writing Up Risks

Here's how you size them up:

• Identifying Potential Risks: Start with a brainstorming session with your team to list possible risks. It's about thinking about what could go wrong and planning for it.

• Assessing Impact and Likelihood: For each risk, assess how likely it is to happen and what the impact would be if it did. This helps prioritise which risks need the most attention.

• Preliminary Strategies for Risk Mitigation: Start thinking about how to handle these risks. It's about having a game plan ready, even if you hope never to use it.

Preliminary Delivery Methods

Deciding on how you'll deliver the project is as important as figuring out what you need to deliver.

Here are some steps to consider;

• Choose Delivery Methodology: Will this be an agile, waterfall, or something in between? The choice depends on the project's nature and the environment. If these terms mean nothing to you, just start planning it out.

• Outline High-Level Phases: Sketch out the significant phases of the project. This doesn't need all the details yet, just the broad strokes

• Validate with Stakeholders: Run this high-level plan past your key stakeholders. Their buy-in is crucial, so ensure they're on board with the proposed approach.

Develop a High-Level Plan

High-level planning is about drawing the map that guides the ship.

The early plan carves out the route from start to finish, setting out the major landmarks along the way.

It's about big-picture stuff—laying down the main tracks before getting bogged down in the granular details.

Too much detail at this stage is a progress killer. If you need a lot of detail, you should ask yourself why. It's okay to break things down into phases and stages and plan only the next one in serious detail. Once that is done, look to the next stage in detail, and so forth.

Elements of a High-Level Plan

• Major Milestones: Think of these as your project's headline acts—the significant dates everyone needs to keep their eyes on. These are your benchmarks for tracking progress.

• Key Deliverables: What are we actually delivering here? Each milestone needs a tangible outcome to show for your efforts.

• Resource Allocation Overview: Who's on deck, and what tools do they need? This is about matching your team and tech to the tasks without diving into the minutiae.

• Timeline Sketch: Rough out the timings. When should what happen? The timeline at this stage is more about rhythm than beat-by-beat precision.

Crafting the Plan

• Drafting the Plan: Write down the essentials—milestones, deliverables, resources, and timelines. Remember: it's your rough draft, not the final manuscript.

• Iteration and Feedback: Throw it out to the team and the major stakeholders. This is where you chop and change it based on what they throw back. It's a bit of give and take to mould it into shape.

• Preliminary Approval: This is about getting a nod or a shake from up top. It's not the green light for go; it's more of a yellow light for 'on the right track'.

Planning Gate Approval

Once the high-level plan is drafted and all the above components are ready, it doesn't just sit there; it goes under the microscope.

This is the stage where we see if our broad strokes match the canvas we're working on. It's about making sure the plan's workable in the real world.

Evaluation by Key Stakeholders

This isn't a solo performance; it's a complete ensemble act, and it's important to get multiple perspectives.

From department heads to project sponsors, key stakeholders get to weigh in. Their insights can turn a good plan into a great one, catching oversights and adding crucial wisdom. Typically, these guys are experienced but have objectivity and a bit of distance from the details, so they have a unique perspective worth listening to.

Integration of Feedback

The feedback isn't just for show. Each piece needs to be considered and woven into the plan where appropriate. This might mean stretching some deadlines, scaling back some goals, or adding new milestones.

Decision Making

• Scope Adjustments: Sometimes, the scope needs a tweak—narrowing down to focus on what's truly important or expanding to cover critical bases we might have missed.

• Go/No-Go: The ultimate decision—is this plan ready to roll, or does it need more work? This isn't just about having all the answers now but being confident in the direction.

• Project Halt: In some cases, the brakes get applied if the feasibility just isn't there. It's better to stop before resources are wasted. This is the gutsiest thing to do. And honestly, I've rarely seen it done, but it takes enormous courage for a team to say, 'No, it's not panning out as we expected.' As humans, we suffer from loss aversion and would much rather double down than call it a day on something that isn't working, which is why we have so many sequels to Pirates of the Caribbean.

Conclusion

The initiation phase is where we set the compass for the entire project. It's where big ideas get their grounding and project visions start taking shape. We don't know everything about how our project will unfold, but we make the big decisions to shape it.

In this phase, we've laid out the framework, established the ground rules, and determined if the project has legs to stand on.

We've tested aspects of the feasibility, and its outlines are sketched and ready to be fleshed out in the detailed planning phase.#

Transition to the Next Phase: Planning

Having established a robust initiation foundation and approval to proceed, we're now set to dive deeper.

In the detailed planning phase, we turn our high-level roadmap into a street-level guide, detailing every turn.