Name the outcome owner before the work begins

By the time a business decides to replace a system, there's usually a fairly good reason. Maybe someone is spending Friday afternoon copying information between applications because there isn't a reliable way to move it automatically. They're getting the work done, but it's taking time they could use elsewhere.

From there, the conversation can move pretty quickly into what the supplier will deliver and how long it will take, and working out the technical details takes enough effort that it's easy to assume everyone already agrees on the reason for doing the project.

That agreement can be less settled than it sounds. For example, a supplier may be delivering a configured application, with your technical team responsible for connecting it to the systems you already have. Both can finish exactly what they agreed to do while the people who asked for the project are still copying information between spreadsheets. Somewhere between the proposal and the implementation, the work needed to solve their problem has gone unassigned.

Nobody has to be careless for that to happen. Each person can be doing a perfectly competent job within the boundaries of their part of the work, but someone still needs to look across those boundaries and deal with whatever is left between them.

That's the person I'd want named before the work begins: the outcome owner. They stay involved long enough to find out whether the project actually did what the business needed it to do, and can get a decision made when it hasn't.

Get specific about what needs to change

Write down what should be different when the project is finished, in terms the people who asked for it would recognize. Then work back through what has to happen to get there, including the parts outside the delivery team's control. This is where I'd spend a little time asking people what they think they've agreed to, because a broad description can hide quite different expectations.

For example, a project to make client files easier to find might include moving them into a new document system. The move won't settle how people should name those files or who decides where they belong, and if those decisions are left to each person using the system, the business may end up with much the same difficulty in a different application. The owner needs to bring that work into the plan and find someone who can make the decisions.

Dependencies need the same attention. If an outside vendor needs several days to complete its part, allow for that in the schedule. If another department has to approve something first, establish when it can do so. Those people may have perfectly reasonable commitments elsewhere, and the project needs to account for them.

Be clear about what's outside the agreement too; if the expected result requires work that nobody has priced or scheduled, talk about it while the business can still choose whether to pay for it or change what it expects. It's a much harder conversation once everyone believes the project is nearly finished.

Give the owner a way to get decisions made

The problem with naming someone accountable but giving them no way to resolve a disagreement often becomes clear a few weeks later, when the same unresolved issue keeps appearing in their status report without getting any closer to an answer.

The owner and everyone involved need to understand what the owner can decide and who can settle matters outside their authority. Someone with authority over the project needs to be available when a decision is holding up the work.

A technical lead may be able to change the implementation sequence, while a decision to delay the business launch may need to go to the sponsor. Agree where that authority stops. Sensitive access decisions, for instance, still belong with the person authorized to grant them. The outcome owner is responsible for getting a decision from that person when the project needs it.

When a decision needs to go to the sponsor, explain the recommendation and its consequences. Be clear about when an answer is needed. "Waiting on approval" isn't much help if the business doesn't know that another week's delay will move the launch date.

Outside specialists need to fit into this arrangement as well. Bringing in someone who knows a particular system more deeply is often exactly the right move. The person leading the work still needs to understand how that specialist's work affects the rest of the project and follow up when something gets stuck. The business shouldn't have to become the go-between for everyone it hired to solve the problem.

Agree on how you'll know it worked

Decide how the result will be checked while you're planning the project. For a system change, have someone who normally does the work try an agreed business task from start to finish. Include an exception, especially if handling exceptions is where much of the manual effort goes now. Give that person enough time to use it properly and tell you where they're still having trouble.

If the promise is to save administrative time, find out how much time the work takes before making the change. You can compare that with the new approach after a few weeks of normal use. Agree who will collect the information and when you'll look at it. Launch day may be too early to know whether the project has delivered that part of its promise.

There will sometimes be a good business reason to proceed with something incomplete; perhaps a workaround is acceptable for a month. Record the limitation and have the person authorized to accept it do so explicitly. Assign the remaining work to someone, with a date to come back to it, so the compromise doesn't disappear from view when the project team moves on.

Plan for the handover

The person leading the project may hand responsibility to someone who will run the system or process day to day. That person needs time to learn how it works, with the access and documentation to look after it, so walk them through what's still unfinished and agree how they will get help when a problem comes up.

Put a date on a review after people have used the result in normal work. Make sure the outcome owner can act on what that review finds. It's easier to do that while the people who delivered the project are still expecting to be involved than after everyone has mentally filed it away.

For a smaller project, the essentials may fit on a page. A bigger piece of work will need more detail. I'd spend the time on the conversation behind it: ask the people commissioning the project and the people delivering it to explain what they think will be different when it's done. Include the people who will have to live with the result. If their answers don't match, there's something to resolve before the work gets much further.

Before approving the next project, ask who will come back after delivery and tell you whether it solved the problem the business set out to solve. Then make sure that person has the support to do something about it if it didn't.