If you are like me, you have sat through project kickoffs where everyone nods along in agreement about what is about to happen. There is a somewhat defined business problem. A team has been formed, maybe vendors are involved, and everyone leaves the room feeling like they know what they are supposed to do. Everything feels aligned.

I recall one of those projects. The project leader spent quite a bit of time describing the business pain points. They introduced the consulting firm that helped with the vendor selection. By the end of the kickoff, we all understood what software was to be purchased and integrated into our systems. Success seemed straightforward: roll out the new solution.

One of the pain points was downstream from a particular system. That team understood their role in the project was to modify their system. The data team understood that they had to augment and transform the data from that system before sending it on to the new system. And the implementation team understood that they were going to fix the problem inside the new system. Each solution reasonably solved the same pain point. Weeks of work went by before the conflict surfaced in a status meeting. The systems team announced that they had completed the work modifying their system and that the data team could begin their work.

We had agreement in the kickoff meeting, but we didn’t have a shared understanding of what success required. Alignment doesn’t mean that every team has the same plan, which might be unreasonable to achieve. Each team will have different responsibilities and different decisions to make. What needs to converge is the outcome.

If I asked five people from five different teams to describe a project, I would expect their descriptions of the work to be different. What I would hope to hear is essentially the same answer to the question: What will be different when the work is done? The words don’t need to match, but the understanding of the outcome should. A shared definition of success could have given the teams a basis for deciding which solution best served the outcome. It does not need to eliminate every unknown.

I have seen what that looks like when it works. I was the lead Enterprise Architect on a cloud migration project. We spent time establishing clarity around what needed to happen and who was responsible for each part. We worked through the migration sequence, what had to happen before the first site moved, and the boundaries between what would be left “as-is” and what would change. Once that was established, the teams started executing on their different responsibilities. During a status meeting, a project manager asked a question. One that could have been answered by several teams. Without hesitation, someone pointed out that the person who should make that decision was out of the office. What stuck with me was that the team understood where the decision belonged and why it mattered to the outcome. That one interaction gave me more confidence in the project’s shared understanding than any project charter or status report would have.

Agreement is not enough if people have different ideas about what success means. Clarity gives everyone a common point of reference to align around. After your next kickoff meeting, if you asked the people who were in the room to explain what success looked like, would their answers describe the same outcome?