Default Strategies for fluctuating ROI

Wie reagiert man am besten auf geänderte Anforderungen?

IT-Projekte dauern oft Monate und Jahre. Währenddessen kann sich der erwartete Marktwert drastisch ändern. Die Reaktion auf diese Änderung ist oftmals eher intuitiv, von “mehr Features” und “mehr Entwickler” zu “durchhalten” oder “einstampfen”.

Vorliegender englischer Artikel veröffentlicht erstmals unser Framework, indem wir den zehn üblichen Trajektorien zehn Normstrategien gegenüberstellen.

Default strategies for fluctuating projected value in ongoing IT projects

Summary

The expected value of IT developments fluctuates during development. We identify five common trajectories and two relevant time segments, proposing default strategies for these ten recurring states. Default strategies provide unaffectionate guidance amidst uncertainty.

Introduction

IT projects, as any long-running endeavors, are susceptible to change in the projected return on investment. Scopes change, and so do demand and competition. IT solutions can become unicorns or fall obsolete.

These fluctuations are often handled ad-hoc, based on emotional attachment, rather than an established framework. This article suggests such a framework of default strategies.

Default strategies might be best-known from frameworks like BCG-4, McKinsey-9 or ADL-20: Finding common qualities over a vast number of individual cases, and recommending procedures that best match these commonalities.

As with all such frameworks, the proposed actions are to be taken with a grain of salt. Yet, they provide guidance in high-stress, high-stakes situations.

Visualizing value fluctuations

Let’s visualize the project with the development progress on the abscissa and the projected ROI on the ordinate.

The dotted markings signify the original expected value (horizontal) and the 30% completion mark (vertical). A project with a near-constant expected value hence hovers around the dotted horizontal line.

Fluctuation matrix: The 10 stages

This results in a matrix of 10 different situations that most IT executives will be instantly familiar with:

• A: Constant projection in the early stage of the project
• B: Declined projection in the early stage of the project
• C: Declining projection in the early stage of the project, with further declines expected.
• D & E: Early rise with constant, respectively further rising, projections.
• F-J: Analog for later project stages.

Default strategies – early stage

The proposed default strategies, as applied in our consulting, are:

A: Constant projection in the early stage of the project

The default state: No relevant changes to original expectations.

Strategy: Expect the unexpected. At this early stage, keep options open and actively monitor for new opportunities. Focus on expendable architectures and keep in touch with major stakeholders. Periodically ask for altered requirements and new ideas.

B: Declined projection in the early stage of the project

Shortly after project start, some assumptions proven wrong or became obsolete.

Strategy: Consider removing some optional features. The reduced scope might allow for downsizing the budget, releasing resources for other projects.

C: Declining projection in the early stage of the project, with further declines expected.

Shortly after project start, the project keeps losing expected value.

Strategy: Consider cancelling the project altogether, or implementing it as a bare-minimum MVP. Stay ahead of your projections by budgeting for the anticipated trajectory rather than the optimistic remains of expected value.

D: Rising projection in the early stage of the project

Shortly after project start, additional use cases or benefits became apparent.

Strategy: Review project priority and resource allocation. You might make the project faster, better (more mature architecture) or bigger (more features). Actively introduce stakeholders to all new features, and ask for use cases unlocked by the new features. Seek opportunities to move the project towards trajectory E.

E: Rising projection in the early stage of the project, with further gains expected.

Shortly after project start, additional use cases or benefits keep appearing.

Strategy: Counterintuitively, consider reducing project scope and pushing an MVP into production ASAP. Incorporate all removed features into a follow-up project, which you open for new ideas and feature requests.

Avoid the two most common MVP pitfalls:

a) Reduce features, but not architectural flexibility. The MVP must be expandable and future-proof.

b) Finalize the planning of the follow-up project while the MVP is still under development. Do not allow your team to lose traction: The follow-up must feel like a natural continuation of the MVP. If appropriate in your industry, employ continuous delivery.

Default strategies – late stage

Starting at about 30% completion, the strategies slightly change:

F: Constant projections

The default state: No relevant changes to original expectations.

Strategy: Keep it simple, keep controlling and monitoring, and avoid disturbing the project flow.

G: Declined projection in the late stage of the project

Midway through the project, some assumptions prove wrong or became obsolete.

Strategy: Acknowledge that this project will not live up to expectations. Reduce priority. While you will still save some budget by removing features, the far greater impact lies in releasing resources for better prospects.

H: Declining projection in the late stage of the project, with further declines expected.

Midway through the project, it keeps losing expected value.

Strategy: While cancellation is an option, you might lose value in what is already completed. Re-scope the project to closely match what has been done so far. Ask yourself: If we quit today, what could we use? Then allow for the steps to tie up loose ends. Actively seek for use cases of the reduced product: Can you sell it as “light”, or can you automate some steps of the process you intended? Keep your team out of blame’s way: Issues are on the business side, it’s not the development that failed. Let them know.

I: Rising projection in the early stage of the project

Midway through the project, additional use cases or benefits became apparent.

Strategy: Focus on getting it done. Be careful with adding new features and resources. Most likely, these would delay the completion of a project that just got more valuable. This includes adding new workforce: New personnel must be brought up to speed by existing personnel, resulting in a temporary decline in development speed and quality. Clearly communicate that you intend to stick to the original scope and timeline, but that you will actively collect new features to be released after the initial development went live.

J: Rising projection in the later stage of the project, with further gains expected.

Midway through the project, additional use cases or benefits keep appearing.

Strategy: Again, focus on getting things done, while establishing or extending the roadmap. Either way, use any additional budget in a way that will not disturb development. For software sold or leased, additional marketing is always an option. Communicate that you have seen and understood these new opportunities, and that you sticking to original plans is not negligence but the best way to get your product out there.

Key take-aways

Some projects die midway, others are your next big thing. Early on, you can take big swings, add resources or even cancel projects. The more mature the project, the smaller the adjustments you want to take.

Either way, scope creep is always discouraged: The higher the project’s value becomes, the more you want to get it done. Additional features are almost always best placed in future iterations.