Project Management and Agile

Every organisation runs two kinds of work. There is the work that keeps things running every day, and there is the work that changes how things run. This chapter is about the second kind. You will learn what makes something a project, how projects move from idea to handover, and why time, cost and scope pull against each other. You will also see what a project manager actually does all week, and why most of that job is about people rather than charts.

These ideas matter whether or not project manager is in your job title. If you have ever been asked to launch something, move something or fix something by a date, you have run a project. Knowing the vocabulary helps you plan it, defend it and finish it.

Operations are the repeating work that keeps an organisation going: paying salaries, answering customer calls, processing orders. A project is different. The Association for Project Management (APM), the UK professional body, defines a project as a unique, transient endeavour undertaken to achieve planned objectives. Unique means it has not been done in exactly this way before. Transient means it has a start and an end.

The Project Management Institute (PMI) works from the same idea. A project turns an idea into a product, service or result, then stops. Operations carry on, often using what the project delivered.

Emma, an operations manager at a housing association in Cardiff, runs a team that handles about 1,200 repair requests a month. That is operations. It repeats, and it has no finish date.

Her director asks her to replace the phone booking process with an online one within six months, for a budget of £80,000. That is a project. It has a fixed end, a set budget and a clear output. If the new system saves five minutes of staff time per request, that is 1,200 multiplied by 5, or 6,000 minutes. That is 100 hours returned to the team every month, once the project hands over to operations.

Projects move through phases. APM describes a linear life cycle with four phases: concept, definition, deployment and transition. Many organisations use similar labels such as initiate, plan, execute and close. The names matter less than the habit of pausing between phases to decide whether to carry on.

For Emma, concept took two weeks: she confirmed the problem with tenants and got a rough estimate. Definition took a month and produced the plan her director signed. Deployment ran for four months. Transition took the final two weeks, with staff training and a named owner for the new system. Each phase ended with a short review before the next began.

Common mistake: skipping transition. Teams deliver the system, celebrate and move on. Nobody trains the users or agrees who owns the system now. Six weeks later, the repair team has drifted back to phone bookings, and the promised 100 hours a month never arrive.

Every project balances scope (what you deliver), time (when you deliver it) and cost (what it takes). This is often called the triple constraint, or the iron triangle. APM names time, cost and quality as the building blocks of every project. Many teams use scope as the third corner and treat quality as what sits in the middle. Change one and at least one other moves. Add scope and you need more time, more money, or both. Cut the budget and something in scope or schedule has to give.

If you squeeze all three corners at once, quality is usually what breaks, and it breaks quietly.

Mark, a project manager at an engineering firm in Houston, is running an office fit-out. The plan is 12 weeks and $250,000. In week five, the client asks for an extra meeting room.

Mark's team estimates the room at $30,000 and two extra weeks. That is a 12 per cent cost increase (30,000 divided by 250,000) and a 17 per cent schedule increase (2 divided by 12). Mark does not say yes or no on the spot. He offers three options: add the room and accept 14 weeks and $280,000, drop a lower-priority item of similar cost and time, or add it in a later phase. The client chooses the swap, and the project stays at 12 weeks and $250,000.

On time and on budget is not the whole story. A project can hit both and still fail if nobody uses what it delivered. Agree success criteria at the start, in writing, with the sponsor.

Common mistake: absorbing changes silently to keep a client happy. Every change has a price in time or money. If you hide it, the cost surfaces later as a late, overspent project, and you have no record of why.

A project manager is accountable for delivering the agreed outputs within the agreed limits. In practice that means planning the work, coordinating people who often do not report to you, tracking progress, managing risks and changes, and keeping everyone informed. You rarely do the specialist work yourself. You make sure it gets done, in the right order, by the right people.

The sponsor is a different role. The sponsor is the senior person who owns the business case, provides the budget and makes the big decisions. The project manager runs the project day to day. The sponsor answers for why it exists.

A project or its result.">stakeholder is anyone who affects or is affected by the project. Sara, a project manager at a bank in Mumbai, is rolling out a new loan application form across 40 branches. Her list starts with the obvious names and grows quickly.

Sara also works out where her time will go. A weekly 15-minute call with each of the 40 branch managers would take 600 minutes, or 10 hours a week. Instead, she holds one 30-minute weekly briefing for all of them and follows it with a short written update. That cuts her time to under an hour and keeps everyone on the same message.

The rest of Sara's week follows a pattern. On Monday she reviews progress against the plan with her team. Midweek she clears blockers, chases approvals and updates the risk log. On Friday she sends the sponsor a one-page status note covering progress, spend, risks and any decisions needed. Very little of it is technical. Most of it is making sure the right people know the right thing at the right time.

Common mistake: finding a project or its result.">stakeholder late. Sara's previous project slipped by a month because compliance first saw the design two weeks before launch and asked for changes. List stakeholders in the first week, including the ones who can say no, and involve them before decisions are locked.

Good project managers do not guard scope for its own sake, and they do not say yes to keep the peace. They turn every request into a clear choice: what changes, what it costs and who decides. Jonas did three things. He logged the request so it was not lost. He estimated the effect on time and cost. He took options to the sponsor. That keeps the relationship intact and the project honest.