What is the biggest organizational difference between a software innovator like Amazon and a company that struggles to maintain relevance as tech giants and startups threaten its market position and viability? Over the past decade I’ve met with hundreds of IT leaders and executives who are grappling with the answer to this question as they pursue digital transformation initiatives.
Frequent answers I hear include a lack of developer talent, technical debt in the form of legacy systems, and the inability to leverage cloud-native and microservice architectures that can facilitate innovation.
While those differences are relevant, there is one dominant organizational paradigm that determines whether an organization is on track to software innovation or if it will continue to struggle: Innovators manage their software offerings as products measured by business outcomes, while laggards manage theirs as projects measured by time frames and budgets.
Over the last 10 years or so, movements such as agile and DevOps have transformed the team and technical dynamics of how software is built, both in companies that are digital natives and, increasingly, in larger enterprise IT shops. These practices focus on incremental and continuous delivery of business value to shorten feedback loops.
While the practices have matured at a technical level, organizations that manage their technology and IT investments with a project-oriented mindset end up with a structure that is fundamentally misaligned to the flow, feedback, and continual learning that forms the core of DevOps and lean software delivery.
Why then is the project-oriented management mindset so prevalent, and why is it such an impediment to effective software delivery?
Project management’s purpose, and where it excels
Some of the world’s most visible and impressive accomplishments were achieved through project management. The discipline was developed by Henry Gantt in the early 20th century and used shortly afterward to construct the Hoover Dam—the largest concrete structure of its time. Project management excels in cases like this, when the outcome is well-defined, resources and dependencies can be planned ahead of time, and there are limited degrees of freedom and emergent phenomena that arise during delivery.
However, the success of agile methods taught us that software development processes are better when they are adaptable to variables such as the ever-changing technology landscape or the need to pivot around product-market fit. The fact that project management is suited to solving well-defined problems causes some major disconnects. For example, the uncertain nature of a new software product could mean that long projects are padded with such large time and cost buffers that the market and technology landscape will change significantly during the project’s delivery. In that scenario, it renders the assumptions made at the start of the project useless.
Because it’s closely tied into business inputs, budgeting is one of the first places that you see the breakdown when trying to manage software delivery with a project-oriented approach. By design, project budgets need to bake in all of the uncertainty and risk of a software project. They need to have a well-defined start and end. If something changes fundamentally during the course of the project, a new project is usually created. Because there is a focus on cost and scope, addressing risks or considering redesign opportunities to reduce core issues such as technical debt are resisted. And at project’s end, there is a switch from a development focus to a maintenance focus, often with outsourcing.
In terms of bringing a successful product to market and evolving it based on market feedback, all of this spells disaster because it’s based on flawed assumptions. Software products do not have a discrete start and end; they have a lifecycle. In a changing marketplace, it is not feasible to bake in all product risk up front. As such, the project is either going to bake in too little risk or too much padding in terms of budget or time frame. And given that a software product has no discrete end, the investment in the product needs to continue as long as the product is generating business results.
The shift from project to product management
This disconnect between project management and business results is at the crux of the problem. When building a dam—or a new building—the business results are all specified up front. But in product delivery, business results need to be tracked incrementally across the lifecycle of the product.
For example, when a manufacturer creates a new car, depending on the market demand for that car, the company can increase production or add additional options and editions. It can do this because it tracks a business value metric, as well as the flow of business value through the product’s value stream. This is the exact mindset that software innovators adopt with their digital offerings by releasing software early and often and then tracking the business results generated by the software product.
In contrast, the results of a project are generally not known until project’s end, or even later, at which point the market could have shifted completely. As the project’s end nears, the pressure for results increases, but the market knowledge that was the impetus for what was to be delivered may be a year or two old at this point.
Complaints of lack of visibility, lack of results, and lack of fit then abound, prompting people to blame the various project stakeholders. But the fundamental problem is not with the people doing the work, but with the paradigm used to manage that work. If you want to be a software innovator, start making the transition from project to product.
Why you should be more like Amazon
This fundamental shift in management paradigm, from project management to product management, is required to rapidly experiment and innovate on digital offerings.
Companies born in the age of software already exemplify how business strategy can be connected to software execution through the discipline of product management. Those companies that want to compete in a business landscape increasingly defined by software innovators like Amazon must change their software and IT management practice to be more like those leaders.
To learn more on this subject, read my new book, "Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework," which was just released this week.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
