What Does Success Look Like?

After writing about the Dayton Flyers and the Buffalo Bills in a recent post, I realized that there’s a difference between those sports teams, and the teams of people dedicated to making data projects succeed. A key difference, in fact: for the sports teams, their definition of success is clear. For the Bills, it’s to win the Super Bowl; for the Flyers, it’s to win the NCAA Tournament in March.

But what about for a team putting together a data project within your organization? What's their definition of success? It’s a lot less cut-and-dried, however, without a clear way to measure whether or not they’ve achieved success, the organization is likely to follow one of two paths - neither of which is really all that great:

• The organization will continue to haphazardly chase new capabilities without a true framework for deciding what’s next;

• OR the organization will run out of momentum, and the project will fizzle out.

Obviously, neither of these outcomes is ideal. Let’s start with the second outcome first - the project fizzling to a stop. This can easily happen - and I’ve seen it happen - when organizations don’t take the time to identify their most critical use cases first, and focus their project and development efforts appropriately. Too many times, project managers or key stakeholders throw up their hands while trying to determine project priorities, putting every last possible use case into the “critical” bucket.

The development team gets understandably overwhelmed, unsure of where to focus, and jumping from development focus to development focus whenever they encounter a roadblock. They’re so intent on delivering some value that they are afraid to spend too much time working through a tough problem, lest it look like progress is held up - so in time, it turns out that no tough problems get solved and the data project gets nowhere. Management gets frustrated, “ghost” projects pop up elsewhere in the organization, interest wanes, key technologists leave, the project putters to a stop.

On the other hand, the first situation actually may deliver a bit of value! That sounds great, and for a brief while it is. However, without a clear definition of success, stakeholders may feel like the solution that’s been delivered represents “80 percent” of what they need, and will tack on additional feature needs on-the-fly. The development team will dutifully go and build out the new features, deliver them, and key stakeholders - maybe a different one, now - will identify another 80/20 gap and add that to the development queue as well.

Over time, not only has your data project started to take on a Frankenstein’s Monster look, with pieces and parts bolted on here and tacked on there, but your development team is feeling down and underappreciated. There’s been no celebration of success, no recognition of their work, no capping off a project with a declaration that it was completed - and done well, to boot! They start questioning whether there’s any real direction, start finding reasons to focus on less important things, shift into new roles, get plucked by other projects, and your data project lumbers on, zombie-like, one more item that will be someday regarded as a “legacy” asset that needs to be retired.

The important thing to realize is: it doesn’t have to be this way.

Stakeholders and project and product managers have the opportunity to define success criteria early: in terms of supportable use cases, delivered features, or migrated legacy systems, for example. Then over the course of the project, priorities may change, but by keeping track of those original success criteria, whether they shift backward, fall off completely, or get pulled forward, stakeholders and managers can keep the team informed as to how they’re progressing against those original goals.

Adding new use cases throughout the development efforts is going to happen - in fact, it’s a necessary and expected part of most Agile methodologies - but those original use cases, those original success criteria, those have got to remain special. They’re what your development team signed on for and what they dedicated themselves to building.

When the last of those success criteria is complete, it’s time to celebrate. Send out a note, get a cake, something for the team to enjoy and to look back on their accomplishments. From a project management perspective, conduct a post-project conversation about what went well and what opportunities exist for improvement.

Then gather the team, review the latest use cases, feature requests, and so forth, decide on a tranche that you’ll call the next phase of success, and kick off the next portion of your project.

As my grandfather would say, plan the work, then work the plan.