How to INITIATE and RATIONALIZE (Step 1) your Project for its Greatest Probability of Success
It’s the first step of your successful project. Create a strong foundation so your project delivers on the increase in competitiveness and profitability that you expect.
Step 1 of project success
The purpose of Initiate and Rationalize is to give yourself a whack on the side of the head and make sure this inspiration is worth pursuing by asking some questions to round out your perspective and rationalize that there is value in going ahead. Example questions include:
- What is the real purpose, and can it be achieved another way, maybe in less time, or with less cost?
- How will you know when you’ve reached the finish line and is it the same one for everyone else who is supporting you? What does “done” look like?
- How much, roughly, is it going to cost?
- What do you have to watch out for?
You’re Already Doing Project Management in Your Personal Life
Imagine you must buy a car. This is a one-time purchase, and you need it by the time winter rolls around. You contact your friends and family, asking for advice and technical assistance (from the people who know cars), visiting multiple dealerships and looking for that perfect set of wheels.
Eventually, dragging someone else along hopefully, make your choice, sign the agreement, and purchase it. Congratulations, you just bought a car and also just completed something in your personal life called a project.
For a project in the business world, you go through those same steps. But, what are they and how can you apply those to your business world?
Six Fundamental Questions You Must Rationalize
Six important research questions need to be asked for any idea or venture; the 5 W’s and How, come-on think back to high school: Who, What, Where, When, Why, and the additional non-W question – How Much.
If we apply this to our car purchase, here are some sample questions we would want to ask during Initiate and Rationalize before committing to buy a car:
- Who is going to help me decide? Who has the time to visit dealerships with me? Who should I tell that I am doing this?
- What kind of vehicle am I getting- a truck or car? An electric vehicle? What features do I want?
- How much am I going to spend? Am I financing or paying cash? Do I have a budget?
- Where am I looking for vehicles? Do I want to browse a website like Craigslist, Kijiji, or AutoTrader? Do I want to visit in-person dealerships? Are there constraints that will affect my options?
- What are my time constraints – am I aiming to find something within a month? Or by next week? Am I casually looking, with no major time pressures, and able to approach this casually?
- Why am I getting a new vehicle now? Is my old one about to die, or am I tired of my current vehicle? Are there any decision factors for choosing a new vehicle that I need to keep in mind?
Think about the 5 Ws and the H
Pieces of the Six Questions
The W and H questions include all the pieces you need when starting and for ongoing management of your project.
Build your foundation by answering W and H questions – Concept Model
Answer these “W” and “H” questions cause you to create the documents you have probably heard about many times in the project management world; and these are all grouped as Pieces to your project under three main categories related to activities you do to Lead, Oversee, and Schedule during the life of your project and they involved the Motive, People, Outcomes, Financials, Map and Timing.
Build the foundation by answering W and H questions – Detailed Model
Project Management Pieces Give Answers to the 6 Questions
Getting into more Project Management detail, we add in the project management Pieces to answer the questions from a project perspective for each one of the labels.
- Why = Motive: purpose, description, assumptions, constraints, risks
- Who = People: roles, team, organization, stakeholders, communications, adoption
- What = Outcomes: objectives, requirements, scope, deliverables, testing, quality, earned value outcomes
- How Much = Financials:CAPEX, OPEX, budget, procurement, earned value financials
- Where = Map (or Path): methodology, approach, earned value progress
- When = Timing: timelines, milestones, schedule
You owe it to yourself to start with a strong foundation. For each project detail piece above, put at least one sentence down to either rule it out or frame what you know or don’t know about it. Just one statement to start with.
Going back to our vehicle purchase example, let’s walk through some of the items in the MPM model.
A vehicle purchase is a practical example of a project.
Question 1: Why? / Motive
The first thing you’ll want to do is create a statement around your decision to buy the vehicle, and your motivation behind it: we’ll call this the Motive.
The Why for Project Management is your Motive
Your Motive will lead to the set of questions that you will answer with your project charter, so it’s important that it contains the information that helps everyone involved understand your project.
This is the first step in beginning to share what your project is going to accomplish. Your purpose statement outlines the problem your project is solving or the change you’re achieving.
Try to make your statement broad, and include what the project is delivering, for whom, maybe where, if relevant, and then several, powerful key benefits.
Initiate (Step 1) and rationalize clarifies what your project is solving
You’ll also want to detail some of the more important assumptions in your planning - these are good ideas to share with anyone who is helping you. This can also identify some risks to completing your project successfully, but we are getting ahead of ourselves.
To your vehicle advisor friend, your project purpose may be simply to buy a new vehicle to replace your old one because your current one is about to die and that would leave you without a vehicle.
Question 2: Who? / People
The Who for Project Management is your People
Your expectations for what you need from your car-expert friend might change from what you thought you needed at the beginning. During the project you’ll need them to spend time advising you on different kinds of vehicles and come with you on dealership visits.
After the purchase, your relationship changes again. You might discuss how you are enjoying the vehicle, but the stakes aren’t high for them, because you’re not asking them for advice.
We call the people involved in your project “stakeholders”, because they have a stake in how it turns out – they’re involved in it.
When you’re planning your car purchase, stakeholders like your car friend will want to know your expectations for their involvement: how soon and how much of their time you think you’ll need, what you are thinking of buying—or how much you plan on spending.
You might want to openly discuss your budget with your stakeholders – they’ll be able to offer input, and they want you to succeed.
Your advisor friend is partly responsible for the approval of your final choice. You’ll get their input as you take test drives and research at your options.
In a business project, there are usually many stakeholders – everything from coworkers who will be helped by your project outcomes to the exec who will sign off on your expense reports, but to keep things simple, this example uses just one.
Clarify expectations for your stakeholders
When your stakeholder asks what you want from them, think of it as clarifying expectations. Even in this (relatively) minor vehicle purchase example, you need to make sure to be straightforward with your expectations. For example, are they actively helping you make the decision? Or will you tell them afterwards what you’ve picked? For more detail on this here is link to a blog about how to best engage your stakeholders.
Make sure to keep your stakeholders in the loop if your needs change moving through the project: if you change your mind about the type of vehicle you’re looking for, if you need them to visit an extra dealership with you, if you find yourself unexpectedly tightening your budget. All of these help them adjust as needed.
Many projects end up failing or struggling, even though the project manager thought it would succeed, because stakeholder expectations and engagement weren’t clarified up front and modified as the project progressed.
To clarify, anyone involved in the project is a stakeholder, including sponsors and team members, both external and internal. Stakeholders might try to clarify expectations that they didn’t understand up front and insist that you meet their expectations before they consider the project done – even when you think you’ve crossed the finish line. Extra deliverables or conditions can up your costs, or even make your project go over-budget, which isn’t good.
Clarification of your vision with your stakeholders is critical
Stakeholder expectations also include what you expect them to contribute. If your advisor friend is working or studying 60 hours a week, they won’t appreciate you asking them to go out every day of the week to look at vehicles.
You need to set all expectations with any stakeholders involved in your project, right at the beginning, and make sure to continually touch base—this is absolutely critical – it can derail a project if you don’t do this.
As soon as a stakeholder is engaged make sure you both have the same understanding of yours and their expectations.
Finding all the stakeholders who have the authority to affect your project outcome can be one of the more critical but challenging activities when going through the Initiate part of your project.
Question 3: What? / Outcomes
The outcomes in your project are the nuts and bolts of what it is that you’re accomplishing, producing, and measuring. That may seem like a pretty broad category, but it’s important to make sure you keep them in mind: it’s easy to miss outcomes if you’re not thinking of your big picture.
In terms of outcomes to include in your charter, you’ll need all of these: objectives that can be quantified, requirements, scope of what is covered, tangible deliverables, how you plan to test the quality, and even how to measure the value of your progress. To illustrate, we’ll cover objectives, scope, and deliverables below.
The What for Project Management is Outcomes
Objectives: The Outcomes You Want to Achieve
Part of your project includes identifying your objectives – and how you can tell you’re reaching them. When you’re done your project, the goals are either achieved or not. We can label these outcomes as “Objectives”.
You need your goals to be measurable, so that you can tell if you’ve achieved them, and track how far you’ve gotten. In the case of the vehicle purchase, there are a couple goals in play.
First, you’re aiming to buy a vehicle – you’re successful if you end up buying a car, and unsuccessful if you don’t buy one, whatever the reason.
A second objective might be budget-related: to find a car within a certain dollar range or limit – again, because it’s easy to tell if you’ve met the criteria or not.
You can add in similar objectives around a time deadline for your purchase, the age of the vehicle, maybe even a vehicle colour.
To tell if something is measurable, try and apply a numerical value to it, or make sure it can be made into a yes or no question. For more details, there will soon be a link here to an upcoming blog on Objectives.
If your objectives are vague and not measurable, you’ll have a harder time proving what your project accomplished. Your stakeholders might disagree with your interpretation, and drag out the completion of the project, upping your costs.
It might feel like you’re holding yourself back but create measurable objectives: ones that are specific and realistic.
Objectives like timelines and costs need to be measurable.
Scope: How broad or how narrow
Your scope defines the limit for what your project looks at, where it looks, and what is included as part of the project. Essentially it is the boundaries for your project.
There are two subsections to this, In-Scope, and Out-of-Scope.
This may seem like a lot of work, but it is sometimes easier if you start with what is not in scope for your project.
Requirements: What You Need
Do you want a red sports car? How about a blue truck? How about an electric one? Are you going to carry sports equipment in your future vehicle? Want comfortable back seats, or do you not need back seats? These are all requirements that you might have considered before going car shopping.
Requirements can change. Objectives are less likely to change as they are measures directly related to your purpose. As the project progresses and you uncover more detail, you may drop or add requirements.
Going back to our example, you might give up on the idea of having a vehicle big enough for sports equipment – maybe a small SUV is out of your price range. But you’re not giving up on your car purchase altogether – just finessing your goals.
My experience is that we start with a particular set of requirements but allow them to change as long as the project purpose and objectives continue to be met.
Deliverables: The Tangible Part of Your Objectives
Objectives are made up of the achievement of tangible outcomes. We’ll call these outcomes “Deliverables”.
For example, as you inch towards making your purchase, you need to reach certain milestones. First, you establish the price range, then the types of vehicles that fit that range. After that, you start on logistics - the vehicle dealerships to visit, the vehicles to test drive, and so on. These are all deliverables. You might need to perform tasks to produce the deliverables: your team’s role is to help define the tasks and complete them.
Describing the deliverables like you’ve already achieved them brings focus to the tasks which produce the deliverables. If you phrase them as an activity, they’re vaguer, and harder to achieve as a result. It’s a key difference. Take a look at the chart below to see some examples:
Deliverables as achieved versus as tasks
When you assemble these deliverables, it’ll get you closer to the project objectives. The task details do not need to be specified in the Initiate phase, as your team will help you with those once the project commences.
Deliverables are tangible outcomes you can point to, so it helps to phrase them as if they are complete. Tasks, on the other hand, are the actions or activities you take towards completing the deliverable or outcome, so they feel action-oriented.
We will examine this more in detail later through an upcoming blog post and a workshop. Knowing the difference between deliverables and tasks can have a large impact on your team’s effectiveness, especially early on in the project.
For more detail about the differences between Deliverables and Tasks – Download a free PDF. Also there is another blog that goes into more detail on identifying Deliverables.
Question 4: How Much? / Financials
Your project budget can change over the course of your implementation, but what you start with sets expectations, especially for your stakeholders.
The How Much in Project Management is of course the Financials
For your vehicle budget, you’ll want to make sure you include costs besides just the purchase price: subscriptions to ratings services, the cost of transportation to get to the dealership, or the fee for your inspection to send to your insurance company. Including all variables not only helps to make sure that you know how much you’re spending, but it also shows anyone else involved in the project that you’re being responsible and thorough.
Any expenses that you pay after the purchase is completed – monthly insurance payments, going to the car wash, picking up a dash mount for your cell phone – those are all considered operational.
Don’t consider them project expenses, because they’re not contributing to the actual car purchase. Another way of thinking about it is that skipping those expenses won’t prevent you from buying your vehicle – they aren’t part of that purchasing process.
Question 5: Where? / Map
The next portion of your project is all about the way you’re going to get to your goals and the timeline that you’re planning out for how you’ll get there.
Your project has a lot of moving parts – buying your vehicle involves doing research, coordinating with your car friend, planning your dealership visits, and mapping out key decision points and milestones.
The Where in Project Management is the Map or Route or Approach
We can call this map the Approach. If your project gets more complicated because you have more people involved, and more deliverables, or specialized tools, the best path might be harder to plan.
If you decide that you want to get a red older model foreign vehicle, you might have to coordinate a lot of visits, because finding an older car in good working condition could be a tall order. Add in scheduling for one advisor who knows a lot about engine health, and another about older vehicles, and you’ll have a lot of pieces on the go.
Try to get a high-level idea of where you need to go and the pieces that need to be in place for success: if you can establish dependencies, you’ll have an idea of the order that different deliverables can be completed.
Once you start the project, you’ll probably find that your path shifts – that’s okay! You can adjust as needed, and it’s important to be flexible in your approach, because projects are often learning experiences for everyone involved.
Question 6: When? / Timing
This early in the process, a high-level overview is more useful than laying out all the small details: rather than planning your timeline down to the hour, giving loose dates will help your advisor get a general idea of what you need.
Building flexibility in early is good, in case things shift more than expected or require more time than you initially thought.
When you create that initial loose timeline, you can establish the relationships between outcomes – if you visit one dealership and take notes, how many days do you want to have before your next dealership visit?
Do you want to have a debrief with your advisor afterwards?
The When in Project Management is your Project’s Timing
Keep your appointments and blocked-out time relative to each other: if one shifts forwards X days, the following appointments do too. This gives everyone involved breathing room and helps you make sure things don’t get rushed or overcommitted.
Once you determine your actual start date, you can then populate dates for the other events in your project and the pace will have been predetermined by those relationships and dependencies mentioned in the Map section of this post.
Stakeholders might not have the time for an explanation of every single appointment in your approach: it will probably be more helpful to tell them about appointments that directly concern them and keep the rest of what you tell them very general.
Some might want more detail; it will depend on the person and their own commitments and role.
Your team members need to know far more detail, since they’re likely involved in the project to a greater extent than your stakeholders, and maybe even you yourself on a more granular level.
As you work on the project, your team members can help refine the schedule to keep time commitments, timeframes, and milestones accurate.
The Charter Ties the Items in INITIATE and RATIONALIZE Together
in this example of a vehicle purchase the answers to the questions during Initiate and Rationalize covered can be collected together in one document we’ll call the Charter.
The Charter and Business Case tools Created During Step 1 INITIATE and RATIONALIZE Tie Together all 6 Critical Questions
The Charter is the document that pulls the high-level answers together, defines the cost, people, and time and creates the launch for the project.
As specified earlier, Initiate Charter items include:
- Why = Motive: purpose, description, assumptions, constraints, risks
- Who = People: roles, team, organization, stakeholders, communications, adoption
- What = Outcomes: objectives, requirements, scope, deliverables, testing, quality, earned value outcomes
- How Much = Financials:CAPEX, OPEX, budget, procurement, earned value financials
- Where = Map (or Path): methodology, approach, earned value progress
- When = Timing: timelines, milestones, schedule
You might also be familiar with the term Business Case, which is a business justification (do you really have the money and time to entertain this brainchild of yours?) for proceeding with a Project. It can provide input to the Charter, but that is for another article.
The Charter is your common starting point for everyone involved in the project. As a starting point, it is based on knowledge at that time. If conditions change as the project proceeds, then the Charter is updated, and each update is reviewed and approved by the same team of stakeholders that approved of it in the beginning.
This ensures everyone involved has the same expectations and there are no misunderstandings.
You might think that a charter is more work than its worth – why go to the effort to produce ANOTHER document, in addition to the regular project plan? If this is a question that you’re asking, check out this post on why INITIATE is such an important step, and the value a project charter can offer.
Summary
Before starting a project, always answer the 6 Critical and Important Questions.
While you would probably never create a charter for buying a vehicle, the point of the simple example is to illustrate, using an experience most can relate to, the items that are critical and important to review and understand prior to the launch of a project.
It is important to set clear expectations in the beginning to increase the likelihood of a finished project being considered successful by everyone involved.
If the desire is to buy a used vehicle instead, you can see how that changes everything from the purpose statement down through the objectives, approach, change management, and risks; and it should. Buying a used vehicle is a different exercise and therefore it sets different expectations with stakeholders than would the purchase of a new vehicle.
Action Steps / Apply This Knowledge
- If your project is in progress now, dump your thoughts into a one or two pager. Create headings as covered in this blog, and a description of the bare minimum needed in each section.
- It is important, even if you’ve started your project work, to capture your assumptions about your current situation and your end point, to share with your stakeholders. It might point out some areas for which you made assumptions that need a closer look or a stakeholder conversation to clarify.
- When your draft is complete, circulate it to your stakeholders, regardless of whether there are one or fifty, and ask for a confirmation of your assumptions. If you are afraid of doing that, then that’s all the more reason to do it. Better to know now, before too much resource time or too many dollars are used up.
Even if your project is the kind that implements completed pieces into the operational environment a little at a time throughout the project rather than all at the end, each project only has so much time, money, and resources to make changes to how a business operates. Clarification of expectations with your stakeholders is critical.
- If you don’t come to common ground with your stakeholders on expectations, your project could stall, never get completed, be left hanging over your head, or even come back to haunt you later. Better to face the music now rather than at the end when it could be louder and not the tune you want.
Learn to More to do More
The site Learning Hub has specific examples and simple how-to action steps to follow.
INITIATE-main
© Simple PM Strategies 2024