Whether you’re part of a front end development team or a project manager at a PR agency, you're used to traditional workloads built around final deliverables and concrete deadlines. For developers, that can mean the launch date for a new website. For project managers, it can be the date a big creative campaign microsite goes live.

Developers and creatives alike are accustomed to viewing deadlines not only as a mandate, but as a benchmark of success. To fulfill a deadline is to check a crucial box of competence and dependability. It’s the point at which many developers are used to sitting back and considering their work mostly done.

But these days, the notion of “done” is being redefined. Or more accurately, it’s being put to bed.

Across industries and project types, there’s a universal, user-driven demand for adaptability. This demand is driving deadlines into obsolescence and redefining what it means to see a project to completion. And this paradigm shift is putting the responsibility on companies and development teams to evolve their internal processes or risk losing the competitive edge.

The death of “done” and the rise of outcome-driven development

Within project management, the age of “done” is done – at least as we traditionally understand it. A decade ago, it made sense for a software development team to draw a line in the sand once a piece of software hit the marketplace. The product was the deliverable that signaled a definitive “done” point.

That era is over. These days, “done” is no longer defined by product, but by outcome. Today, successful project brainstorming sessions don’t begin with the question, “What will this look like?”, but instead, “What is our objective?” The product is not the end goal; it’s one element in an evolving model of outcome-driven development.

In theory, outcome-driven development is about investigating customer or end-user needs in order to work toward desired outcomes.

As a business idea, the outcome-based methodology has been circulating since at least 2002, when a Harvard Business Review contributor outlined a multi-step outcome-based process for business growth, beginning with conducting outcome-focused customer interviews; registering and noting desired outcomes; organizing and rating those outcomes based on degrees of customer satisfaction; and finally harnessing desired outcomes to inform product design.

But if the theoretical basis for outcome-driven development was laid nearly 20 years ago, it’s only in recent years that we’ve seen it take hold in industries like software development, where the traditional “Big Bang” software launch is quickly being supplanted by a model of continuous development and delivery.

Rather than focus on perfecting a piece of software in time for a perfect launch, innovative development teams view software as a constant work-in-progress.

Once a new piece of software is in the field, that’s an opportunity to listen to customer data and feedback, register their problems, and promptly devise solutions across a development team. In this way, outcome-driven development is very much aligned with Agile, in that both prioritize adaptability over perfection and collaboration over a singular vision. Ultimately, I view outcome-driven development as a great practice to set the most relevant goals for agile teams.

Roadblocks hindering outcome-driven development

As companies evolve in a market that’s increasingly defined by outcome-driven development, it will be important to identify and improve upon key points of weakness. These problem areas include:

  • Becoming too devoted to a methodology: If you look at what outcome-driven development means in practice, it’s simply about listening to customers and responding accordingly. And developers should remember this simplicity as they deploy a more outcome-driven approach. Because the reality is that it’s easy to become married to a methodology and forget the basic ideas it’s built around.
  • A lack of team knowledge and empowerment: When development teams lack autonomy, they won’t be able to truly investigate the desired outcome of their product and the factors influencing that outcome. Without this insight, these teams cannot do their job at an optimal level. Therefore, development teams need to be more autonomous and empowered with the knowledge and skills to confidently spearhead outcome-driven efforts.
  • Not having the right infrastructure in place: In order to successfully oversee outcome driven-development, you need to be able to effectively test your products irrespective of what’s going on across other teams. If you’re not in a workplace that allows and encourages rapid-fire experimentation, then you’re not going to be in a position to do outcome driven-development well.

Confronting and surmounting these roadblocks begins at the leadership level, with enterprise decisionmakers embracing and encouraging a more collaborative and transparent culture. When company leadership endorses a culture of transparency and teamwork, that empowers small teams with the autonomy to really drive projects forward.

Once smaller teams have a stronger feeling of empowerment, they can work internally to develop strategies that prioritize greater efficiency, including launching more interactive and visual workflows. Through these collaborative-focused steps, developers can put themselves in a strong position to maximize the benefits of the outcome-driven model.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access