The Frogslayer team has written extensively about the keys to project and product success, as well as measures taken to achieve desired success criteria that reflect iterative progress for our clients and our development team.
For example, Ross recently shared how our pre-project consulting process aids in avoiding failures through critical steps taken with clients even before project kickoff, while Brad discussed how unaddressed technical debt can put projects and products on a course for failure, and Tim highlighted the importance of involving end-users early on to significantly reduce the risk of product failure.
This post aims to further explore project pitfalls after the planning phase of software development.
What is software planning?
Software planning is the process of defining objectives, requirements, scope, feasibility, and other critical aspects of a software project or product.
At Frogslayer, the software planning phase is called Validation, Design, & Planning (VDP), which represents a crucial phase in the product development lifecycle. The consulting team brings the product idea to life by delving deeply into the issues faced by the client. The ultimate objective of the VDP is to produce a set of artifacts essential for success in the subsequent build phase. These artifacts include clear definitions of business value, requirements, technical design and architecture, end-to-end UI mockups, roadmap(s), and time/cost estimates to build the product.
Common Reasons Software Projects Fail Before Development
The VDP phase of a project is part of our risk mitigation strategy to prevent failures later in the development process. They are often intense and exciting; however, one of the most challenging aspects of the VDP is transitioning to the next phase – development and delivery. With that in mind, below are some of the most common reasons projects fail to progress beyond the planning phase.
Scope Creep (and, by extension, sticker shock)
Deciding to build a new product should never be taken lightly, but the fact is that there are numerous advantages to developing custom software. The desire to follow innovation trends (such as ChatGPT), “wow” users with impressive features, or differentiate from existing products can lead to bloat in scope, resulting in an increase in time and cost required to build the first version of a new product. This can be tricky territory to navigate. To maintain momentum, we make every effort to ensure the business goals, objectives, and success criteria are well-defined ahead of any point where complex product decisions are made.
Expectations are based on the belief that an individual’s or team’s actions will produce desired outcomes. While the best products are built with outcomes in mind, they are also designed and engineered by highly multi-disciplinary teams of crafters and stakeholders. Different perspectives inherently mean there will be different – and sometimes competing – expectations where personal needs and/or experience slow progress toward success.
One scenario that could lead to misaligned expectations is when building a product to support multiple related business units that share many needs but have different priorities and expectations around what should be built first to demonstrate growth and/or efficiency. Another scenario involves personal experience with smaller-scale software development projects that set unrealistic expectations regarding the time, effort, and cost needed to develop a modern and secure application.
Changes in Priorities
Businesses are constantly evolving, driven mainly by external factors such as competitors or partners/suppliers. Project teams working towards outcomes over a period of six months or more, and sometimes even five years, are inevitably affected by changes in priorities within an organization. Even seemingly minor changes made several levels above a project can have an impact. Often, this can be a confusing experience for all involved, and it’s an ongoing challenge for business sponsors and project/product managers or owners to navigate these changes or shield the team from them as much as possible.
One of the most common changes impacting custom software projects is when a shift in priorities leads to a change in leadership, especially in the sponsor or product owner role. This may require a leader to assume responsibility over a wider range of products or services and must re-evaluate project priorities.
Too little. Too much. Too little time spent with end users. Too much time between phases. Too little time dedicated to the project. Too much emphasis on time and not on value or outcomes. There are many ways time can become an enemy to the process of moving beyond the validation, design, and planning stage of a custom software product development.
In some cases, time is often a distraction from essential conversations around product vision, prioritization, and expectations in favor of rapid planning. On the other hand, some ascribe to Parkinson’s law or the idea that “work expands so as to fill the time available for its completion,” which can drive us to responsibly trim the timeline to ensure any extra time doesn’t lead to inefficiency.
Ultimately, the success of a project or product is often measured in terms of time to achieve measurable business value. The longer it takes to achieve actual outcomes, the higher the likelihood of failure.
Looking Ahead to Project Success
While numerous factors could hinder progress from the planning phase to the development phase, scope creep, misaligned expectations, changes in priorities, and time are the most common contributing factors. Our team has developed effective risk mitigation strategies to address these challenges and others as they arise. In our experience, proactively managing risk can significantly increase the likelihood of project success.