Step 1: Start the Project

Every project starts with a decision: is it worth investing time, money and energy in this? Step 1 exists to answer that question clearly — and, if the answer is yes, to leave the project authorized to move forward. This is where you do an initial survey, looking at the whole project from above, without diving into the details yet.

For your career: learning to start a project well — justifying it, setting clear objectives and aligning the stakeholders — is one of the most valued skills on the market. It works for your company’s project and it works for your life or career-change project too.

The tool for this step: 5W2H

To organize the initial survey we use 5W2H — a simple, powerful set of questions that turns a loose idea into a clear plan. It is not our invention: the PMBOK® Guide, 8th Edition says that a project charter, even the leanest one, “focuses on answering a subset or all of the following key questions: why, who, what, where, when, how”.

Each question answers an essential part of the project — and each one has a card on your board:

In the next sections we go through each question; as you answer 5W2H you are already building your project.

The board is built in two stages — and the second one depends on you

When the board opens you will notice that everything from the HOW block onwards is born locked 🔒 — cards 4.1 to 4.6 (the where is part of the how), 5 (WHEN) and 6 (HOW MUCH). That is on purpose.

The “How?” of 5W2H is the development approach — and it is what defines the shape of the rest of your board (a WBS or a Product Backlog? “In progress” or “Sprint Backlog”?). The order of the course is the right order to think in, and it has two halves:

• the approach is chosen from the characteristics of the deliverable, the project and the organization — that is, after you have answered why, what and who. Choosing before that would be a guess;
• and the when, the how much and the where are calculated from it. “When will it be ready?” is a different question if the answer is a delivery milestone or the end of a Sprint; “how much does it cost?” is different if the cost is the whole project or the team per Sprint. Asking before is asking for a number without knowing what it means.

So it works like this:

1. Stage 1 (now): you answer cards 1.1 to 3 (why · what · who) as you read this article.
2. The decision: when you reach the “How?” section, you choose the approach.
3. Stage 2: you run Step 1 again — it unlocks the rest of the charter (the HOW, the WHERE, the WHEN and the HOW MUCH) and builds the rest of the board in your approach.

Why? The justification and the objectives

This is the first question, and the most important one: why is this project necessary? It splits in two.

What is your justification?

Which current situation motivated the project? The justification almost always comes from a pain — something that bothers you today and that the project turns into something better. Do not look for the perfect justification: this is an iterative process that you refine as you go.

Which objectives must the project meet? Use OKR

Subjective objectives create double interpretation, conflict and rework. To give clarity, use OKR (Objectives and Key Results): the Objective says, in a directional way, where you want to get to; the Key Results say how you will know you got there — 2 to 5 per objective, each one with an indicator and a target.

How many objectives? As many as the project asks for — most have more than one. Number the Key Results per objective (KR 1.1, KR 1.2, KR 2.1…): it is by that number that, in the next topic, each deliverable will say which Key Result it serves. That way no Key Result is left without a deliverable that reaches it — and no deliverable is left without a reason to exist.

Test the quality of every Key Result. At this step, a good Key Result is:

• Specific
• Measurable (it has an indicator and a target)
• Realistic

A Key Result has no owner and no deadline — it is only the result and the target. Who does it and when belong to the deliverables and the tasks (the schedule and the execution), not to the Key Result.

Whenever you can, write the target as “from X to Y” — from the starting point (the X: today’s situation, that same dissatisfaction you described in the justification) to the target (the Y: where you want to get to). It carries more information than a percentage change: “reduce churn from 3.2% to 2.7%” says more than “reduce churn by 15%”. That starting point is recommended, not mandatory: when it is the first time you do something there is no starting point — then write only the target (“reach Y”).

An example of getting out of the subjective: instead of “the project must satisfy the customers”, write “overall customer satisfaction above 80%, measured by a survey answered at the end of the project”.

What? Deliverables and requirements

To reach each objective, define the deliverables (products, services or results) needed and, for each deliverable, its requirements. A requirement is a condition to be met in order to satisfy a need — it can be mandatory or desired.

A good deliverable is a result (a noun), not an activity: “Purchasing policy published”, not “write the policy”.

It is worth separating a few close relatives of the requirement, because these concepts come back throughout the project:

Who? The stakeholders

Knowing the expectations of the people around the project is decisive. When interests conflict, your role is to balance them to minimize resistance and delay. Organize the stakeholders into three groups:

• Customers — those who will benefit from the products and results. The project exists to serve them.
• Team — those who produce a deliverable (employees or not).
• Other stakeholders — people, organizations and external factors that can impact the project.

Pay special attention to the most critical stakeholders: those with power over resources, scope (veto), budget (approving an increase or a cut) and people — in particular the sponsor, the person who authorizes and funds the project. If you do not know who the sponsor is, you do not have an authorized project yet.

A word of care when you build the team

When you list the team, push your memory and try to remember everyone who will perform some activity in the project — not just the core group, but also whoever takes part briefly, whoever comes from another area or from a supplier. Name each one by the person or the real role that delivers (“Ana — video editing”), not by a vague group (“the marketing team”): these are the people the project’s tasks will be assigned to later on.

Do not blame yourself for not remembering everyone now. The team grows with the project: whenever you remember someone else, or a new need appears, come back to this card and add the new member — that is natural and expected.

And, whenever possible, each team member should have a user on ProjectAdm (or on whatever tool you use to manage the tasks). It is that user which lets the person receive notifications about their tasks and mark them as done as they complete them. With no user attached, nobody is told what they have to do — and the project loses the most basic control of all: knowing who does what.

How? The development approach

Here comes the decision that changes everything else — and that is exactly why it comes after you already know why, what and who, and before you say when, how much and where.

The “How?” of 5W2H starts with the development approach: “the means used to create and evolve a product, service or result during the project life cycle” (PMBOK® Guide, 8th Edition). It is not the manager’s taste or the market’s fashion: it is a decision made from the project factors you have in hand. And it lives on a spectrum:

• Predictive — the scope is known and stable enough to plan before executing. You define the scope, break it down into a WBS, estimate schedule and cost, approve a baseline and control change against it. Changing later is expensive: that is why you plan first.
• Agile — the requirements are not clear yet and frequent feedback is worth more than predictability. You establish a Product Vision, the known requirements become a prioritized Product Backlog, and you deliver in short increments: build, show, learn, reprioritize. (The PMBOK® Guide calls this family adaptive — Scrum is its most used method.)

There is also the hybrid approach, which combines the two — but it is not a third path you pick at the start: it emerges in practice, when you run one approach and borrow what works from the other.

How to choose — the 5 axes that decide

The Guide does not tell you to choose on gut feeling: section 4.3 lists the variables to consider, in three categories (the deliverable, the project and the organization). There are many — and several say the same thing with different names. Distilled, five axes remain, and it is on those that the decision really turns:

The Guide’s own rule of thumb sums it all up: requirements clear and stable from the start → predictive; requirements uncertain and frequent feedback valuable → agile.

The rest of the “How”: constraints, assumptions and risks

With the approach chosen, the HOW block completes itself — and notice that these three concepts change shape according to your choice:

• 4.2 Constraints — the limits imposed from outside (deadline, budget, standard, contract). A constraint is not negotiated inside the project: you work around it or you accept it. In agile, the typical constraint is the date: it is fixed, and it is the scope that flexes to fit.
• 4.3 Assumptions — what you take to be true without being sure (“the supplier delivers in 30 days”). Every assumption that falls becomes a risk. In agile, the assumption becomes a hypothesis — and Sprint 1 exists to test it.
• 4.4 Initial risks — the high-level risks you can already see at the start, written as cause → event → impact. “Delay” is not a risk: it is the impact. In agile, risk does not live in a parallel document: it goes into the backlog — knowledge uncertainty becomes a spike. You go deeper in Step 3.
• 4.5 Initial scope — the first breakdown of your deliverables: the WBS (decomposition into work packages, numbered by levels — a package has cost, duration and an acceptance criterion) or the initial Product Backlog (value items in priority order, written as user stories: as a [user], I want [need], so that [benefit]). This is the initial view — you open it up in Step 2.

And the “where”? It is part of the “how”

Where the work happens and how far it goes: which area, unit, system, region, audience — on site or remote. And, above all: what stays out.

The where comes here, at the end of the “How?”, for a reason: it depends on the way the project is run. A team that delivers in short increments and sits with the real user works in a different “where” from one that delivers everything at the end. That is why it is part of the how — and not a loose question further back.

It is also the least decisive of the seven questions. If you do not know where yet, leave the card blank and decide at the right moment — that is a legitimate answer, and better than inventing a boundary you will have to take back later. What really counts here is what stays out: it costs one line now and saves weeks of argument later.

When and How much (preliminary view)

At Initiation you make only a preliminary estimate of dates and costs — enough to decide on feasibility. Put milestones only on the deliverables that are easiest to estimate, in relative time if you prefer (“Week 4”, “Month 2”), and do not worry about the rest: the detail comes in Step 4 — Schedule and budget.

For cost, give the order of magnitude with the basis of the calculation and the margin: “$20k to $30k — 2 people × 3 months; margin -25%/+50%”. Saying “I do not know yet, and this is the basis of my guess” is honest. Faking precision is what breaks trust further down the road.

Critical success factors

• Define the objective and the reach of the project clearly;
• Identify the stakeholders and define strategies to win support or reduce obstacles;
• Identify the start date and the main dependencies;
• Recognize the opportunities and threats in the external environment;
• Assess the assumptions and the risks involved;
• Decide, at the end, on the feasibility and the continuity of the project.

🎯 Your turn — Start the project

Objective: authorize the start of the project and record, leanly, why it exists, what it delivers, who takes part, how it will be run (and where), when and how much it costs.

Your script (it is the same as this article):

1. Open the board — course menu → Step 1 — Start the project. It asks for the project’s name and creates the INPUTS list with the 7 questions.
2. Answer cards 1.1 to 3 — reading each section of this article. You write; use prompts 1 to 3 to accelerate.
3. Choose the approach — menu → Step 1 · HOW (5 questions). The script recommends; you decide.
4. Run Step 1 again — it unlocks the rest of the charter and builds the rest of your board in your approach.
5. Complete cards 4.2 to 4.6, 5 and 6 — constraints, assumptions, initial risks, initial scope, the where and, finally, the when and the how much (prompts 5 and 6).

🎁 Your deliverable: the complete Project Charter, built on the cards of your board — and the board ready for Step 2.
⏱️ Suggested time: about 2 hours for the initial survey — be careful not to go into detail now.
🛠️ Tools: ProjectAdm + 5W2H + OKR + your AI.

💬 Remember: this is an iterative process. As you progress you will want to update earlier sections — that is healthy, and it shows you are going deeper. You can go back and rewrite any card: running Step 1 again never erases what you wrote. What matters is to start and not stop, going step by step all the way to Step 10.

With the project authorized, the next step is to detail what is — and what is not — inside it. On to Step 2: Review the scope.

🎁 Your artifact — the Project Charter in Word, generated from your board

When you finish Step 1, Project Together reads your board and generates the Project Charter for you (a Word .docx file, in the course’s 5W2H template), saved in the _saida/documentos/ folder. You copy nothing: the board is the source, the document is the result — ready to share with the sponsor and the stakeholders.

How to check it:

1. Open the _saida/documentos/ folder (inside the course folder) and open the file Termo de Abertura – (your project’s name).docx in Word.
2. Check that every section — Why (justification and OKR), What (deliverables), Who, How (approach, constraints, assumptions), When and How much — reflects what you wrote on the cards. The header carries your project’s name.
3. Want to update it? Adjust the cards on the board and generate it again with the D key in the course menu (Generate my documents) — the document is always a faithful picture of the board.

🧭 How to use the 10 steps — an order to learn, a repertoire to use

You learn the steps in sequence (1 → 10) because that is how you understand the logic of a project for the first time. But a real project does not move in a straight line.

Step 1 (Start) always comes first — you cannot monitor, change or execute something that has not been authorized yet. After it, you run the steps in the order the project asks for, in sequence or in parallel. And several of them you repeat many times:

• Step 8 (Monitor and Status Report) — run it whenever you need to communicate progress to the stakeholders or check the health of the project. It is not an event at the end: it is continuous.
• Step 9 (Control changes) — run it whenever a change request arrives, at any moment.
• Steps 6 and 7 (Engage and Execute) — they happen throughout the whole project.

That is why the 10 steps go into your project’s schedule: they are recurring tasks of the person in charge, not a list you walk through once. The PMBOK® Guide, 8th Edition says that the performance domains run concurrently throughout the project life cycle — they overlap and interconnect rather than happening in silos — so monitoring and controlling changes happen from beginning to end, not in one isolated stage.

💡 Tip: at any moment, run Check my project (the P key in the course menu). It reads your board and tells you where you are in the 10 steps, whether your plan still reaches what you promised, and what to do next.