A project can have a detailed schedule and still lack a clear purpose. Before assigning tasks, I recommend writing down the problem the project should solve and the change the organisation expects to see. A new system, building or service is an output. The reason for investing in it should explain what will improve once people use it.

Write a brief that people can challenge

Keep the first description short enough for the sponsor and intended users to read. State the problem, the proposed result, the main constraints and the assumptions that could affect the decision to proceed. Avoid presenting an early estimate as an approved commitment.

For example, a fictional team proposing a booking system might want to reduce avoidable telephone enquiries. The system itself is not the benefit. The team needs to agree which enquiries it expects to reduce, how it will measure the change and who will own that measurement.

Establish authority early

Name the person accountable for the investment and clarify who will manage the work. Identify the users who can explain what is needed and the suppliers who can judge whether it is technically achievable. A job title alone does not establish project authority; responsibilities need to be agreed.

Separate starting up from detailed initiation

PRINCE2 distinguishes the early check that a project is viable and worthwhile from the work of establishing its detailed foundations. That distinction helps prevent a weak idea from consuming substantial planning effort.

Before developing the full plan, ask whether the organisation has enough information to make the next decision. If the purpose is unclear, the best next action may be a short investigation rather than immediate delivery. A useful project brief makes that choice visible.