the same old thinking and disappointing results, closed loop or negative feedback mindset concept - a napkin doodle with a cup of coffee

Most digital projects are set up for failure

As traditional projects fail to create value, digital product management is the way forward for companies seeking true digital transformation.

Building bridges and mass-producing consumer goods are examples of important tasks and challenges in the industrial age. So, the management practices created during this era were perfected for such operations.

However, these management principles are ineffective when applied to today’s digital products. The reason? The characteristics of digital innovation – and the way software enables continuous value creation in an ever-changing market – fundamentally differs from activities such as construction work and perfecting assembly lines.

The inability to understand and leverage these differences represents a great risk for any organization. Such businesses are in danger of repeating the failures of Kodak or Iridium.

A main part of the problem is approaching digital transformation with a series of more or less connected projects with a defined start and end date.

What makes more sense is to manage digital products.

In this article we will shed some light on the difference between these two mindsets, and how this will help you succeed in creating value within the digital world.

What’s wrong with projects?

A project can be defined as a piece of planned work or an activity that is finished over a period of time and intended to achieve a particular purpose. Let us make this clear up front: we believe the concept of a «project» will continue to be relevant in many situations.

However, we are convinced that «the project» has some fundamental shortcomings when it comes to digital product innovation – especially as a digital product needs continuous development to survive in the market.

In software projects, success is often defined as staying within the constraints of time, cost and scope – visualized as the “iron triangle”. These constraints depend on each other in the sense that changing one constraint will impact at least one of the others. For example, it is not realistic to increase the scope of the project without re-calibrating the time frame and budget. If scope is increased while time and cost remain fixed, quality is likely to suffer.

triangle 600x422 Most digital projects are set up for failure

 

The sad irony is that budget overruns, delays, and unsatisfactory quality are so common that projects that are kept more or less within bounds tend to be celebrated as successes, no matter how poor the outcome is.

What’s worse, many large enterprises organize their software development as a series of phase-gated projects, each of which build upon the previous. We believe this approach to be both wasteful and risky.

The largest source of waste: building the wrong thing

The project is usually founded on a set of assumptions that were formed when the uncertainty was at is highest. These assumptions may take the form of a business case or pitch that suggests a certain return of investment.

According to research by Donald Reinertsen, it is typical for 50 percent of total product development time to be spent in “fuzzy front end” activities. In the book Lean Enterprise, the authors show how “this leads to poor investment decisions and needlessly long product development cycles, delaying the feedback the team needs to build the best possible solution”.

The single largest risk by far, according to Reinertsen, is failure to create value for users. In the worst cases, this leads to projects being cancelled or never implemented in the organization at all. It is baffling how some managers, in their desire for control, fail to take this risk into account.

Proper product management, however, counteracts this uncertainty by understanding that every digital service of importance needs to combine two dimensions; exploration and exploitation. For digital products to evolve and create value over time, stakeholders need to shift their focus away from requirements to discovery and from control to flow.

Successful businesses do:

  • Product evolution based on hypotheses and feedback, not assumptions and gut feelings. New ideas come with a promise of value for the users, and the means to evaluate if the criteria are met. A seasoned product manager knows that even HiPPOs can be countered with “Great idea, let’s do an experiment and measure how it flies! What are the metrics we should set up?»
  • Less reporting on time and material, and more on the actual outcome. “Building the wrong thing” is far worse than not getting all the features you expected up front. A great product manager helps the team pursue the most promising features first, iterate, and continuously evaluate the product in terms of value. As a stakeholder you might not get all that you expected – you will probably get something far better. But you’d better get used to get turned down from time to time.

Even in agile projects we often see that this perspective gets lost between product owners, scrum masters, and project managers. A team with a product mindset will challenge the project limitations and produce superior results.

The second largest source of waste: handovers

Since projects by definition are resource constrained, teams are set up to deliver a certain outcome within a certain time frame, before moving on to other tasks. In many cases the project organization is separate from the line organization, or the project teams are temporarily put together with people from the line. Consequently, the project outcome has to be passed on to other parts of the organization for the next step in its life cycle, for example Operations or Maintenance.

 Most digital projects are set up for failure

Water-scrum-fall considered harmful. Source: Humble, Molesky, O’Reilly: Lean Enterprise: How High Performance Organizations Innovate at Scale

According to Lean software development, unnecessary handover leads to waste. Furthermore, it assumes that a product at some time will be «done», which is rarely true in any digital context.

The biggest problems with this are:

  • Lack of ownership of achieved business value: stakeholders usually have a vision giving mandate and direction for the project. The vision is usually tied to a desired business outcome. Either way, handovers reduce ownership to that vision and to what extent the business outcome is achieved. Furthermore, such a handover indicates that the solution is complete and that the business outcome will come as a result. However, in reality, real business value requires continued effort improving the solution.
  • Lost momentum and knowledge: the knowledge a team accumulates by working with a set of problems over time should be considered a big asset for the organization. However, transferring this experience comes at a high cost, and no amount of documentation and training will keep unique domain knowledge from getting lost. This extends to team dynamics too: an effective, motivated team has learned a lot about how to work together, and this momentum is lost when the team is replaced with for example an operations team that needs to handle other products simultaneously.
  • The product becomes obsolete before it is put in front of the users: The world does not stop changing because your system was rolled out. Chances are you have just scratched the surface of the user needs. A competitor may have launched a better service, or user expectations change during the roll-out phase. With the transition between teams (and operating models), you risk falling behind quickly.

With a digital product management mindset, the teams are not set up to be temporary, and the products are not set up to be handed over to someone else; instead, the product owner makes a long-running team responsible for a certain outcome; for example increasing customer engagement or improving online sales. The skilled product manager sets the team up for long-lasting success. Some of the most important mechanisms she’ll use are:

  • Nurturing a culture of learning and accountability, where failing is regarded as a natural part of building experience and improving both the product and the process. The team as a whole is accountable for the outcome, not the output – that is, improvements according to business goal, not number of features implemented. The product manager is not afraid to challenge the vision, or to suggest changes in direction based on the team’s experiences. She’ll also suggest more meaningful ways of measuring progress.
  • Autonomous team: Self-organizing teams usually outperform traditional command-and-control setups in environments with high information flow. This is largely due to managers becoming bottlenecks, being unable to make decisions with the pace that the team members require. The experienced product manager takes a step back and lets the team take responsibility for execution so that she can focus on priorities, metrics and product strategy in cooperation with the product owner.
  • Multidisciplinary team: To optimize for learning as well as reducing risk, the product manager makes sure that the feedback loops are kept close, making the time from hypothesis to feedback as short as possible. This means no room for wasteful handover activities, so the team needs to be able to handle the entire flow of delivery, from design via development to operations. This is where Lean UX, Agile and DevOps fit together beautifully.

Conclusion

While the project paradigm remains useful in some contexts, it becomes limiting in the world of digital transformation.

The mindset of product management overcomes these challenges by viewing software development as a continuous flow of improvements rather than temporary, resource-constrained efforts. You still have to strictly prioritize new features, but with a value-driven mindset you are more likely to reduce risk and get higher returns on investments.

The bad news is that some businesses have some hard work ahead of them. The good news: with the right skillset and attitude, it is just hard work.

Further reading:

Beck, K. et al., 2001. Manifesto for Agile Software Development. [Internet] Available at: http://agilemanifesto.org/iso/no/ [Retrieved 12 01 2016].

Humble, J., Molesky, J. & O’Reilly, B., 2015. Lean Enterprise: How High Performance Organizations Innovate at Scale. Sebastopol: O’Reilly Media

Gothelf, J. & Seiden, J., 2013. Lean UX: Applying Lean Principles to Improve User Experience. Sebastopol: O’Reilly Media.

Kaul, S.,2016. Why you should never hire a good Product Manager for your company? [Internet] Available at: https://www.linkedin.com/pulse/who-product-managers-why-you-should-never-hire-good-manager-kaul [Retrieved 22.01.2016]

Narayan, S., 2015. Agile IT Organization Design: For Digital Transformation and Continuous Delivery. New Jersey, Pearson

Publisert