How to Manage a Project With No Experience: A Step-by-Step Guide

What does managing a project actually involve?

A project is temporary, unique and usually cross-functional. The Association for Project Management describes project management as applying processes, methods, skills, knowledge and experience to achieve specific objectives within agreed parameters, and PMI frames it as applying knowledge, skills, tools and techniques to project activities to meet requirements. In plain words: you are responsible for getting something new built, by a date, with people who mostly do not report to you.

That last part is why first projects feel hard. In your normal job, the process carries you. In a project, you have to build the process and then run it. New project owners often feel busy and unproductive at the same time, because that process-building work is invisible.

The good news is that you do not need a certification to run a twelve-week project well. You need a handful of habits, done consistently, at a size that fits the work. The six steps below are the ones we teach in our workshops at Bodhih Training to team leads and specialists who suddenly own a project.

Step 1: How do you start a project you have just been handed?

Start with why. Before you plan anything, write a one-page project charter: the purpose in one sentence, the background, two or three measurable objectives, the main deliverables, key dates, budget and resources, the sponsor and core team, and the assumptions you are making.

The most common mistake is writing activities instead of objectives. 'Run the sales conference' is an activity. 'Leave 180 sales staff able to pitch the new partner programme, with 30 partner sign-ups next quarter' is an objective. A quick test is to ask 'so that what?' after each objective; if the answer is more interesting, write that instead.

Then ask your sponsor for fifteen minutes to check it. A charter does not create agreement; it reveals disagreement early, while it is still cheap to fix. Once confirmed, use it to run a 60-minute kick-off meeting.

• Name the sponsor: the senior person who owns the outcome and can unblock you.
• Mark guesses with a question mark rather than leaving boxes empty.
• Write assumptions so someone could disagree with them.

Step 2: How do you stop scope creep before it starts?

Scope creep rarely arrives as a big demand. It arrives as a series of friendly, reasonable requests that begin with 'while you're at it'. The defence is to draw a fence early, with three zones: In (what you commit to), Out (what you have agreed not to do) and Later (good ideas parked for a future phase).

Describe scope as deliverables, not tasks, and give each important deliverable acceptance criteria: the conditions that make it done. When there is more wanted than you can deliver, sort requirements with MoSCoW: Must, Should, Could and Won't have this time. The Agile Business Consortium, which maintains the DSDM framework where MoSCoW originated, recommends keeping Must Have effort to no more than about 60 per cent so the rest acts as contingency.

Finally, read the Out list aloud to your sponsor and key stakeholders and get explicit agreement. That moment gives you something to point to in week seven.

Step 3: How do you make sure everyone knows their role?

List everyone who affects the project or is affected by it, then place each person on a simple grid of influence against interest. High influence, high interest: manage closely. High influence, low interest: keep satisfied with short, well-timed updates. Low influence, high interest: keep informed. Low and low: monitor.

Ask each key stakeholder two questions in a ten-minute conversation: what would make this a success for you, and what would worry you about it? The answers tell you more than a requirements document.

Then build a RACI chart for your eight to fifteen most important activities. Each person gets one letter per activity: Responsible (does the work), Accountable (owns the outcome), Consulted (gives input before) or Informed (told after). The rule that matters most is exactly one A per row. Two accountable people means nobody is; zero means the work drifts.

Step 4: How do you build a realistic project plan?

Build the plan from the deliverables down using a work breakdown structure. Put the project at the top, the deliverables underneath, and keep breaking each one down until every item is a task one person can finish in a few days to two weeks. Long tasks hide problems: you only find out a six-week task is in trouble around week five.

Get estimates from the people doing the work, not from your gut. Research by psychologists Daniel Kahneman and Amos Tversky on the planning fallacy shows how consistently we underestimate our own tasks. For uncertain work, ask for optimistic, most likely and pessimistic durations and use the PERT weighted average: (O + 4M + P) / 6. A task estimated at 2, 4 and 12 days comes out at 5.

Map dependencies to find the critical path, the longest chain of tasks where any delay moves the end date. Add a milestone every two to four weeks, and protect a buffer of roughly 10 to 20 per cent before the key ones. If everything bunches up at the end of your timeline, the plan is fiction.

Should you use agile or waterfall on your first project?

Plan-driven (waterfall) projects define scope up front and execute in sequence. They suit work where the outcome is clear and changing course late is expensive: an office move, a fixed-date event, a regulatory deadline. Agile projects deliver in short cycles of one to four weeks, gathering feedback each time. The Manifesto for Agile Software Development, published in 2001, values responding to change over following a plan, and the approach suits work where needs will emerge and change is cheap.

Most projects in ordinary organisations end up hybrid: fixed milestones and budget on the outside, short review cycles on the inside. The UK Government Digital Service's agile delivery guidance is a useful free reference if you want to go deeper.

Step 5: How do you track progress and manage risk week to week?

Keep a risk log. Write each risk as 'If [event], then [effect]', score likelihood and impact from 1 to 5, and multiply. Scores of 15 or more are high and get attention every week. For each one, choose a response (avoid, reduce, transfer or accept) and give it an owner and a review date. A pre-mortem, a technique popularised by psychologist Gary Klein in Harvard Business Review, is the fastest way to surface risks: ask the team to imagine the project has failed and write down why.

Then run a weekly rhythm of about 90 minutes in total: update the tracker on Monday (20 minutes), hold a 30-minute check-in focused on blockers and the critical path, chase what is stuck midweek, and send a short status report on Friday (20 minutes). Use Red, Amber and Green with clear definitions, and report amber early. A sponsor would much rather hear 'amber, and here is the plan' in week four than a sudden red in week ten.

Handle change with four steps: capture every request, assess its impact on time, cost and scope with the people who would do the work, let the sponsor decide, and update the plan. Agree a threshold below which you can approve small changes yourself, and log those too.

• Status report: RAG and one sentence, done this week, next week, milestones, top three risks, decisions needed by a date.
• Escalation: the issue in one sentence, two or three options, your recommendation, and when you need an answer.

Step 6: How do you close a project properly?

Projects rarely end; they fade. Closing well takes perhaps a day spread over two weeks: confirm acceptance against the criteria in your scope, hand over to the new owner in a short meeting, close contracts and licences, check the success measures you can, and name who will check the rest later.

Run a lessons learned review of 60 to 90 minutes. The US Army's after-action review, widely used in business, sets the right ground rule: the aim is learning, not blame. Push for specific lessons ('brief team leaders a week before agents') rather than vague ones ('communicate better'), and turn no more than five of them into actions with owners. Finish with a short closure report and specific, written thank-yous.

What tools do you need to manage your first project?

You do not need specialist software for a project of a few months and a handful of people. A spreadsheet tracker with tasks, a timeline, a RACI, risk and change logs, plus a charter, a status report template and a lessons learned form will cover almost everything. If you would rather not build these from scratch, The Project Playbook for Everyone from Bodhih includes a ready-built tracker with formulas and sample data, fillable forms and Word templates.

It also helps to know where you are starting from. The Project & Delivery Leadership assessment on AssessAll gives you an honest baseline, and Jobulary can turn the results and your project lessons into an individual development plan you can track over time.