10 Top Killers of
Custom Software Projects
And how to avoid the common problems
that sabotage the value of your software.
The majority of
software development
If you’re to try to put a little shine on the reality, you could say software development projects don’t succeed as planned.
They go over-budget. They’re not
completed on time. Above all, they don’t deliver the value expected to satisfy important business objectives.
As practitioners of enterprise software delivery, failing to achieve successful outcomes for our clients—even a tiny percentage of them—would doom our business. We won’t have it. And whether you develop software in-house, outsource it, or some combination thereof, we hope you feel the same.
Executive summary.
Strategic misalignment . . . 5
Losing sight of the customer value . . . .6
The wrong mix of talent . . . 7
Perfection obsession . . . 8
Feature frenzy . . . 9
Blurry product vision . . . 10
Communication breakdowns . . . .11
Quality assurance neglect . . . 12
Resistance to change . . . 13
Future-unfriendly software. . . 14
Closing thoughts . . . 15
Table of contents
The majority of software
development projects fail.
Sources:
1.) 2019 State of Agile Report
2.) How to Ensure the Success of IT Projects / Agilsoft + CIO Forum 3.) 2015 Chaos Report / Standish Group
4.) McKinsey-Oxford study on forecasting IT projects
“A problem well-stated
is
half-solved.”
In this brief guide, we aim to give due to this oft-quoted idiom and present the problems we know to cause custom software projects to fail or all fall short. Yes, we’ve called them “killers,” and that’s dramatic.
But we make no apologies. The problems that destroy—or threaten to derail—your software projects are expensive. The good news is that they’re also avoidable. The thoughts in the pages that follow tap into decades of experience in the business not only to reveal the problems that sabotage enterprise software development but also to propose practical solutions.
How many IT projects fail?
First, let’s take a look at how many IT projects fail and what “fail” actually means. Here are the results of three surveys on IT project success rates.
Why do IT projects fail?
Next, among those IT projects that do fail, here are the main reasons leaders cited for why that failure occured for projects with IT budgets greater than $15 million.4
Missing focus Unclear objectives or a lack of business focus Execution issues Unrealistic schedule or reactive planning Content issues Shifting requirements or technical complexity Skill issues Unailgned teams or a lack of skills Unexplained causes Other reason or no reason given 2019 State of Agile Report1
Agiloft / CIO Forum Survey2 2015 Chaos survey3 Successful project Challenged project Failed project 75% 25% 52% 48% 52% 19% 29% 29% 25% 20% 13% 13%
Top killers of custom software projects:
1. Strategic misalignment.
In software development projects, far too often, business
directors are at odds with the IT teams that support them.
Business leaders may press for unrealistic timetables or
have different ideas about the deliverable itself.
Satisfying the needs of a project from a business point of view requires aligning the two constituencies so they work toward a shared goal and create a product that generates value for the organization.
Often, communication breaks down after the product’s high-level architecture is established. Teams begin working in silos focused strictly on specific goals and drift in different directions.
To succeed consistently, business and IT needs a reliable communication channel and insightful reporting structure to align their efforts.
Frequent, iterative communication
checkpoints in the product development cycle help ensure everyone is solving the same problem together. These checkpoints ensure that decisions can be made more effectively and projects go forward more efficiently.
Additionally, requirements should be made crystal clear in the first phase of the project. Any misunderstanding as to exactly what’s needed is bound to result in disappointments along the way or in the final product.
2. Losing sight of the
customer value.
Aligning with the customer experience is now the North Star
of effective business models. In software development, the
idea boils down to focusing on the customer above and
beyond the technology itself to deliver quantifiable value.
The essential question is: what problemwill the software solve? Subsequently,
the issue becomes: which features are most important?
When these questions are ignored, little things tend to derail the project and value gives way to the workflow. Done correctly, a high degree of
alignment and customer focus results in value-driven development.
Everyone wins. We advocate for a
value-driven development
approach, where features that bring the greatest value are prioritized in the product backlog and built first.
Value-driven development, simplified
Ask, “why?” Define value Build value
Using the above process, you can iteratively add value, evaluate your assumptions, and gain consensus while maintaining focus on the customer.
3. The wrong mix of talent.
Sometimes the work lands in the laps of the wrong
software developers. They’re tasked with projects that
simply don’t match their skills.
Why does this happen?
• Product owners and development teams are pre-assigned to working together regardless of the demands of the software.
• Business managers and/or product owners are the only ones with any say on a product team’s composition.
A better approach
Include IT leadership in the team-building and decision-making processes. Here are some positives that will result:
• Business objectives will drive decisions regarding the allocation of technical skills. Plans may even include matching the requirements of specific releases to specific developers.
• Higher risk projects will be assigned to more experienced developers.
4. Perfection obsession.
Software development teams often are forced to create
the perfect product. Instead of focusing on an effective
minimum viable product (MVP) and the core features
needed to support it, they try to “boil the ocean,” that is,
nail everything in one take.
The result is often disastrously bloated products with numerous issues.
Customers get stuck with a product that’s functional, but far from ideal. It’s not optimized as it should be or tested to see if it’s actually a worthwhile use of development time and effort.
The agile software development model aims to solve these issues. Agile is about taking iterative steps toward the end goal, rather than finishing the product to perfection in one extended cycle.
Along the way, assumptions are
verified with actual customer feedback. Software products are tested at early, foundational stages of development to inform decisions going forward.
5. Feature frenzy.
You may recall the mysterious voice from Field of Dreams
who whispered,
“If you build it, they will come.”
It’s an
iconic movie line, but
the notion flies in the face of smart
enterprise software development. Essentially, hunches can
be expensive and crippling.
The goal instead is to remove the mystery. The way to do it is to involve users early in the process to validate any or all assumptions.
How’s that done? You deliver working prototypes to users to test at each critical iteration and collect data regarding their experience. Valuable measurements may come from heat mapping, various indications of user engagement, and more.
The idea, of course, is to develop a
stronger understanding of the user’s needs and to validate any assumptions made— or product plans—with actual data that indicates which features will or won’t fly. You never know what you’ll learn but without user experience data, you won’t know anything. Obviously, circling back at late stages of the development cycle means you’ll have more to fix and product improvements will come at a much higher price.
6. Blurry product vision.
In many organizations and across many software
development efforts, those dubbed “product owners” or
“product managers” don’t actually
own
or
manage
much of anything. They’re not empowered to make
key decisions that could change the direction of the
software for the better.
Without empowerment, they’re simply relegated to serving as administrative task managers. Essentially, they play “telephone.” As a result, the development team’s insight is not heard.
They should be product, not project,
managers and be given the power to guide the product vision and work with the development team to better satisfy the customer needs more.
In other words, the product manager advises on big picture strategy. Big-picture thinking helps avoid ill-conceived product visions and wasteful band-aid projects. Remember, the goal isn’t to
build “safe code” so as to not break older systems, it’s to achieve
long-term business initiatives. By empowering your product owners to make decisions that influence the product roadmap, you’ll get the valuable feedback critical to producing greater value—faster and more efficiently.
7. Communication breakdowns.
A lack of communication between the software
development team and business teams is another culprit.
A failure, or reluctance, to regularly measure progress
against your initial plan can produce disappointing results.
Whether the delivery team is internal ora contracted custom software vendor, transparent communications are needed to clearly establish what success looks like and achieve it. Communications must include iterative checkpoints designed to track specific success metrics and make necessary updates.
Custom enterprise software has no blueprints. Plans must be flexible and evolve throughout the software development lifecycle. While the team must remain in-step with the established goals, it’s important to recognize the path to that goal may change. Agility is key.
There are numerous ways to
communicate and review project status including email, messaging and one-to-one conversations, however frequent project status meetings tend to be the most effective approach.
Whatever review system you rely on, it needs to accommodate frequent feedback loops. It also needs to help foster a culture of shared ownership.
If product owners are always focused solely on the next project or release…
They don’t have the time to help the team during the project.
If product owners are always in firefighting mode…
They’re not
communicating with their customers to better plan the next release.
If product owners can’t make time to
communicate with the customer…
Dangerous assumptions can rear their ugly heads.
8. Quality assurance neglect.
Quality assurance (QA) is frequently the Achilles heel of enterprise software
development. The problem at large: development teams think of QA as the final line of
defense before a customer gets their hands on the software.
However, when testing occurs in the “waterfall” methodology at the final stage of a production cycle, it becomes a bottleneck. Lengthy gaps occur between building and testing. As such, flaws, bugs, errors, or incorrect assumptions go undiscovered until the final stages of production. For obvious reasons,
problems are difficult to detect and fixing them can severely slow production. “Build, test and repeat” is our mantra. In other words, QA testing should occur at every stage of deployment and accelerated with automated testing technology.
And once again, even in QA, we maintain alignment is all-important. The QA
team shouldn’t be thought of as merely bug exterminators, but as analysts.
They should focus on ensuring the customer’s needs are met. They must be up-to-speed on business goals, integral members of the cross-functional product team and baked into the product development lifecycle from start to finish. When the QA team understands the product and its customer value, testing becomes more holistic. It isn’t just about testing functionality; it’s about testing the product’s validity.
The QA doesn’t focus solely on if the software works, but also, if it works the right way. Does it solve the problem effectively? Can it be done better? In summary, it’s important to make the QA team an integral part of the communication loop throughout the process and allow the critical insights they provide to influence the development of the product.
9. Resistance to change.
While products are in development, product managers and all leaders involved need to recognize the value of any information gathered from developers, the QA team and users. These findings should be used it to make data-informed decisions to fine-tune and guide the development roadmap. For software development at large, new tools continuously enter the fray. Many offer great potential to help make processes more effective and therefore must be reviewed and considered. Clearly, custom enterprise software development evolves constantly. An unwillingness to implement productive new approaches and methodologies can be a serious impediment to success.
Sometimes, in environments where the technology stack doesn’t make room for adaptation, it may be necessary to start from scratch. You have to let go of the “sunk-cost” fallacy. More often than not, it’s cheaper and more effective to start from scratch and rebuild.
Resistance to change is in our DNA as humans. In software
development, and all things, you often need to do just the
opposite: embrace change.
Sunk-cost fallacy
When you’re already invested in a system or technology, it’s natural to feel like future expenditures may justify that sunk cost. In software, be sure to weigh the maintanance costs of your current software when evaluating whether to improve that current system versus starting over.
10. Future-unfriendly software.
Custom software products should be easy to maintain and
update. They seldom are.
While the product vision should be forward-thinking, when teams get rolling, all too often, development devolves into a myopic assembly line. It’s up to the leaders—on both the business and technology side of things—to keep their eyes on the horizon.
Business leaders
must ask:
• We’re building something customers want now, but will they in a year? What about in three years?
• Are we well-positioned to be nimble and adapt to changing business models?
• Will this product easily scale with our business?
IT leaders must ask:
• How great is our technical debt?Is an unwieldy or old code base holding back innovation?
• How maintainable will our product be in the future?
• Is our underlying platform well-suited to our organization’s goals?
• Do we have appropriate documentation in place to ensure continuity if we experience staff churn?
When you’re in the middle of building a product, it’s easy to get caught in the rhythm of aiming for the next development checkpoint. The job of the leaders is to think about future product versions and ensure the teams are aiming for the same goals.
Forte Group delivers services that empower enterprises to accelerate the development of custom software, achieve greater scale and realize more value. In fact, what we call “value-driven development” instills a proven delivery machine that allows the principals and practices of agile software development to work.
We focus on what’s most important to you, foster a path to a valuable solution, and build an outcome-based partnership. When a project is finished, you can be sure you’ll realize new business efficiencies and measurable results.
Learn more about how Forte Group can build a quality custom software product to realize your business vision at fortegrp.com/contact-us
