The launch date has not changed, which is encouraging. Neither has the list of outstanding decisions, which is less encouraging.
The designer is waiting for the wording. The person writing the wording is waiting for the price. The person approving the price is on leave. Meanwhile, three people are debating whether the button should say “Book now” or “Get started”.
There is activity everywhere. Progress is harder to locate.
Welcome to the peculiar world of the busy project: a place where calendars are full, inboxes are overflowing and the finish line appears to move whenever anyone approaches it. The following project diary may feel familiar.
Monday: everything is nearly finished
A small consultancy is preparing to launch a paid workshop. Invitations should go out on Friday. The booking page is nearly finished. The programme is nearly finished. The promotional email is, according to its owner, “basically there”. These sound like reassuring updates until someone asks what customers will actually be able to book.
One person expects a morning session. Another has arranged speakers for a full day. The booking page describes lunch, although nobody has ordered any. “Nearly finished” has been concealing a disagreement about what finished means.
Before doing more work, the team writes down the offer: a half-day workshop, two speakers, a fixed capacity and online payment. The business owner approves the price and cancellation terms. They agree that Friday’s invitations can only go out once a test booking produces the correct payment record and confirmation. This takes forty minutes. It saves them from completing several different versions of the same event.
APM identifies clear requirements and quality expectations as core parts of project management. On a small project, that might mean a short agreed brief rather than a substantial document. What matters is whether everyone can use it to answer the same question: what have we committed to deliver?
Tuesday: the small request arrives
“Could we offer a discount for group bookings?” It is a reasonable suggestion. Potentially a useful one. It also arrives carrying the word “just”, as these requests often do. Could we just add another price? Just collect everyone’s details? Just send separate joining instructions?
The team looks at the work involved. Group bookings would affect the payment setup, attendee records, confirmation messages and testing. There may be a way to handle them, but it needs more than a quick change to the promotional email.
The business owner chooses to launch individual bookings first and consider group bookings afterwards. Nobody has declared war on good ideas. They have made a decision about this one.
That is the practical purpose of change control, as described by APM: understand the implications before accepting a change to the agreed plan. Otherwise, the project grows one perfectly sensible request at a time while its deadline remains mysteriously untouched.
Wednesday: four hours take three days
Testing should take four hours. Unfortunately, the person doing it also answers customer enquiries, processes invoices and helps colleagues who begin conversations with “Sorry, quick question”. The plan allocated the effort. It never established when she could actually do it. This is a common planning trap. Four hours of work does not guarantee completion within four hours of elapsed time. Availability, interruptions and other commitments matter.
The team arranges cover for two testing sessions. They also identify what must be ready beforehand: agreed prices, final wording and a working payment setup. Now the sequence is visible. There is little point perfecting the invitation while the booking journey remains untested. The immediate priority is to get the test conditions ready.
The Scottish Government’s project management principles emphasise reviewing dependencies and refining planning assumptions throughout delivery. Here, the assumption needing attention was simple: someone appearing on a task list did not mean they had time available.
Thursday: green becomes an awkward colour
A test payment succeeds. The confirmation email gives the wrong start time. Someone suggests correcting it after launch. Someone else points out that customers may arrange travel around it. The team stops discussing whether the project feels ready and examines what remains. The email needs correcting and retesting. The second speaker has also not confirmed their attendance.
These are different problems. The incorrect email is already an issue. The speaker’s possible withdrawal is a risk requiring a response before it becomes a last-minute emergency.
A named person takes responsibility for each. The speaker receives a confirmation deadline, and the team checks whether an alternative is available.
Friday’s launch is now uncertain. Reporting that uncertainty gives the business owner a chance to choose what happens next. Keeping the status green would preserve a pleasant colour at the expense of a useful conversation.
Friday: a decision, rather than a surprise
The speaker confirms. The email correction still needs testing. The owner delays invitations until Monday. That means less promotional time, but avoids selling an experience the team cannot yet confidently support.
They also agree who will monitor bookings, respond to customers and update attendee details. The person receiving the work needs to be ready, too.
Nothing about this week earns a dramatic transformation headline. The team has clarified its commitments, uncovered unrealistic assumptions and made a difficult decision while there is still time to act.
Try this at your next project meeting: replace “How is everything going?” with “What evidence would let us confidently approve the next step?”
Then give the answer an owner.
For practical support with these conversations, explore Compound Knowledge’s Project Management course. A useful plan should help people decide what to do next, even when the status colour becomes uncomfortable.