Successful software projects deliver business value. But the path to such value isn’t always straightforward. Even when teams strive to build as quickly and economically as possible — and with the advantages of working with expressive languages, trunk-based development, and DevOps tooling — they can still get bogged down by issues ranging from unclear or missing requirements and scope creep, to unrealistic schedules and a lack of demos to gauge the project’s working status.

The resulting delays and budget overruns decrease the overall value the project provides. A McKinsey study revealed that large-scale projects that fell behind schedule and exceeded their budgets delivered 56% less value than those that didn’t. Similarly, the Project Management Institute (PMI) found that although just 14% of projects failed outright, almost one-third didn’t accomplish their goals and nearly half were delayed.

PMI’s numbers suggest that teams can overcome setbacks and complete their projects, but only with increased costs and additional risks along the way. For example, a project might get stalled because of unmanaged stakeholder expectations, leading to a new PM being brought on to realign scope, schedule, and budget and preserve business value. Fortunately, it’s possible to minimize these types of potential disruptions through a combination of planning ahead and maintaining flexibility. Here are four sets of strategies and tactics to consider.

1. Create shared understanding of what’s being built.

Uncertainty about what is being built is a central cause of project failure. A team might find itself facing tight timelines while working toward unclear goals and acceptance criteria. This disconnect leads to burnout and stakeholder frustration — even more so on large projects with vast and ever-evolving scopes and requirements, not to mention numerous unknowns. Costs and schedules subsequently become tough to manage.

Steve McConnell’s “cone of uncertainty” is a useful framework for understanding the dangers here, i.e. of overpromising and making overly optimistic estimates when a large project is still in its early stages. A developer might not know how to precisely estimate a particular feature they’ve not built before, while a product owner might be confronted with an unrefined backlog and accordingly not be able to set clear-cut priorities and a realistic roadmap for the project.

Because transparency is a core value of Agile, it’s important to embrace what Atlassian has called “conscious collaboration” early on in a complex project, to avoid such problems and ensure everyone is clear on goals, ownership, and the roadmap. More specifically, teams should be cross-functional and work together on:

– Proactive communications, roadmap creation, and task prioritization

All three of these actions support a clearer, more structured business vision for the project.

From the start, teams should collaborate to set goals collectively and to ensure shared agreement of roles, responsibilities, and schedules. The product owner should map everyone’s work to the architecture in use, and also build and share a roadmap that outlines the strategy and provides a big-picture view of the project, as a counterpart to the more granular items contained in the backlog.

Moreover, an effective and up-to-date roadmap that ties user stories to strategic themes can help inform backlog item prioritization. With a roadmap, teams can make aligned decisions about what to prioritize, such as opting to deliver the highest-value features first, a common solution to the cone of uncertainty. Platforms such as Jira plus other tools like Gantt charts may be used to further organize and prioritize specific tasks.

Any updates to project scope and timelines, which are inevitable, should be proactively communicated to team members, not just in meetings but via asynchronous channels such as Slack and GitHub as needed. Similarly, frequent reviews and demos every two weeks are useful in collecting feedback from cross-functional teams and maintaining alignment.

– Backlog refinement and breaking work into smaller batches

Because complex projects contain numerous unknowns, it’s not advisable to initially plan and then release them in large chunks. Requirements will change and the costs of misaligned major releases — which may have resulted from an overall lack of clarity — are high.

Breaking work into smaller batches during sprint planning enables better understanding of the requirements in question, as well as increased team velocity and superior adaptability to change. “Vertical slicing” of backlog items, for example, supports more consistent creation of working software that can be continuously tested and refined at low risk, compared to horizontal slicing by architectural layer or simply working on them in larger increments.

– Staying flexible at every stage of development

The largest projects present the biggest challenges in estimation and scope management, due to all of the unknowns and changes involved. This fact makes Waterfall and its linear structure a poor fit here.

In contrast, predicting with certainty the outcome of a project from the outset isn’t the point of Agile — remaining flexible is. High flexibility is necessary for integrating feedback and striking the right balance between time, resources, and scope (sometimes called the “iron triangle” of project management) as the project evolves.

2. Start with high-level requirements and iterate on them.

In the aforementioned PMI survey, “inaccurate requirements gathering” was the second most cited cause of project failure. When requirements aren’t handled properly, teams can end up building something the customer doesn’t need, resulting in delays and budget crunches.

One traditional approach to requirements gathering is to get a detailed written list from a customer and then distribute it to the project team. This usually doesn’t work, for two main reasons:

• Each team member may come to their own separate conclusions about what a document really means, which contributes to the uncertainty discussed in the previous section.
• The number (and complexity) of customer requirements grows as the project progresses, and teams become overwhelmed by all the heavy, detailed documentation involved.

A better alternative is to forego super-detailed documents, such as large BRDs, if possible and instead start with lighter weight high-level requirements that can be iterated on. Capturing these requirements in a simple two-layered structure is often beneficial, as it gives you:

• First layer: The user story containing the perspective of the business stakeholders and the primary value-added components and outcomes.
• Second layer: The underlying materials, which contain additional details on the story’s meaning and which get refined over time.

Cross-functional team collaboration and a generally iterative process are both essential to succeeding in this approach to requirements. For starters, conducting initial in-depth interviews with product owners, business stakeholders, and technical personnel is important to ensuring shared understanding of the project’s entire value chain, namely what’s being built, for what purposes, and how.

From there, ongoing cross-functional feedback sessions with engineers, designers, and product managers offer the opportunity to define specific phases and features, integrate user testing and validation, and identify any defects in existing documentation. Among other benefits, this methodology helps ensure that teams don’t invest a lot of their time and energy building something without a definite understanding of what a requirement means.

3. Structure and manage the project as a series of releases.

We mentioned the importance of small batches of work earlier. When things like backlog items are “sliced,” or otherwise made smaller, it becomes easier to estimate their completion times and also to limit the impact of an inaccurate estimate, which is much more substantial with a larger item. In turn, working software can be produced more quickly, thanks to tighter feedback loops and more manageable workloads.

Likewise, managing a large-scale project as a series of relatively small releases can pay dividends in the form of sustainable, incremental, and visible progress toward the finished product. Each release represents an iteration on a requirement, and it can be distributed and used by someone, even if it doesn’t go to an end customer right away. Subsequent feedback from stakeholders, whether internal or external, can either provide the momentum to keep the release strategy on track or prompt a reassessment of its trajectory.

On a more technical level, a release-based strategy fuels ongoing visibility into whether a team is hitting its KPIs for releasing functionality and then getting it accepted. For example, burndown charts in Jira are particularly useful for tracking release forecasts, iterative progress, and scope evolution in an Agile project. Accordingly, teams can better understand the ebb and flow of their current work and realistically manage it even within the larger context of a big, complicated project.

4. Take an adaptive approach to sustain momentum.

An adaptive (iterative) approach that elevates lightweight planning and continuous learning helps teams sustain their momentum amid numerous changes and challenges. By being adaptive, cross-functional teams can avoid ever getting too far off course and succumbing to the major delays and budgetary excesses that siphon off business value.

Adaptive teams that release regularly, receive stakeholder feedback, and monitor their KPIs (as discussed in the previous section) are well-positioned not only to keep a project moving forward, but to identify and address issues with it as they arise. For example, if sprint attendance drops and working code stops getting integrated, an adaptive approach provides the framework to quickly re-baseline the project, roll back to the last known good release and discuss what went wrong in a retrospective.

Being adaptive also means conducting frequent reviews and demos to gauge the status of the project, and having product managers who can reliably surface specific risks. This methodology can reduce the risk of problems being hidden or obfuscated until the last minute, when the cost of failure becomes highest.

Between them, these four sets of strategies and tactics will deliver more consistent business value, with fewer delays and budget overruns, for your project. At Transcenda, our team has honed an approach to large-scale projects that delivers the business value that our customers expect. Connect with us to get started with your next project.