If you’re in the IT industry, you’ve heard the stats about the percentage of projects that fail. The typical study I’ve seen claims somewhere between 60% – 70% — more than two-thirds of all efforts!
A quick search reveals plenty of possible reasons why, and while I don’t necessarily disagree with most of the common suggestions, I believe there is a deeper root problem. These studies are measuring initiatives that are bound for failure from the onset.
That deeper root problem? It’s the “Project Mindset” — an approach that loses sight of business goals and instead creates a kind of project-only “tunnel vision.” It’s almost impossible to succeed with such a narrow perspective!
If you want to succeed, you need to expand your field view; think product! The “Product Mindset” is based on factors that are most critical to business, measuring success by market share, revenue, sustainability, user retention, support requests, and other metrics that drive or indicate a trend towards a very real return on investment.
Unfortunately, the success of software development initiatives is typically measured by scope, budget, and timelines. Don’t settle for these false measures of success. Even if you nail them, they are often seriously misaligned with business need.
Today, too many projects are detached from business goals and are driven by a project mindset rather than a product mindset. What’s really surprising is that the failure rate isn’t higher.
Consider the example of two teams developing a greenfield software asset:
- One team thinks project, sets a plan, and measures success by achieving a range of scope within a certain time and budget as indicated by the plan.
- The second team thinks product, sets a plan, and defines success by business metrics such as user adoption and retention, and the revenue or cost savings generated per feature.
Shortly after development has begun, an individual from both teams discover that 30% of the initial features have little to no value to the end user. What happens?
The first team likely didn’t even notice or consider the discovery important since it has no effect on the scope, time, or budget of the project. Assume that the individual that has made the discovery has a strong business sense and escalates it to the project manager. Remember, this team has defined their ultimate success by project-based parameters. Time, scope, and budget are key. The team is at an impasse, they must either plow forward, spending critical cycles on unimportant and misaligned features, or, they must reset project expectations, likely rendering the initial attempt a failure.
The second team is trained to focus on key business factors. It immediately takes action on this key discovery. Thirty percent of the features are immediately removed or re-prioritized from the product roadmap, and the next most valuable features are quickly moved into their place. The team realizes a major increase in productivity simply by avoiding low-value feature development. Success is much more likely because the features implemented are more likely to attract, retain, and generate revenue or cost savings from users. These realities align the team’s goals with the business goals.
This is one simple example of how a team’s thinking can impact performance and success. My experience shows that too many software teams think project, not product. For a business-minded client, that way of thinking is disastrous.