If you’re a software architect or developer, one of your projects will fail at some point. And often, it’s the overlooked problems that end up derailing months (or years) of effort. Before your team starts missing deadlines and blowing budgets, here are the top signs your project could fail:
If your team members are increasingly pulled away to other projects, it’s time to worry: that’s a clear sign that your project isn’t a priority. “Stakeholder apathy strikes when you find yourself mired in a project that isn’t what’s at the top of your internal or external customers’ minds,” said Paul McReynolds, co-founder and CTO for Conspire, a social networking tool. “Where other warning signs might lead you to recommit yourself and your team, when people don’t want what you’re building, there’s no reward for pushing through.”
Solution: Swallow your pride, regroup and reorganize your team members, and try to forge ahead.
Too Many Moving Parts
A growing project also increases the risk of unintended consequences. Change one detail, and a related process or system might break. Fixing those breakages takes time and money, and can wreck a project altogether if they prove beyond repair. “Avoiding this sort of collateral damage starts in the planning phase, but sometimes you miss something or set your sights too high,” McReynolds said.
Solution: Do as much planning as possible from the outset; while that won’t eliminate everything that can possibly go wrong, it could save you some headaches later.
11th Hour Changes
Are the project’s requirements changing at the last minute? “If your team isn’t using and sticking to a well-defined Agile development methodology, such as Scrum, or doesn’t write and agree on formal requirements upfront, then inevitably executives and others will want to add features that change the schedule and increase risk,” said Brian Lawley, CEO and Founder of the 280 Group, a product management consulting and training firm.
At best, too many late changes can delay a project. At worst, they can wreck it.
Solution: From the get-go, make sure everybody knows what can (and can’t) change during an Agile sprint or longer development cycle.
QA Is Shrinking
If Quality Assurance resources shrink the closer you get to product release, be concerned. “Inevitably, development takes longer than anticipated, yet the release date for the product is usually firm and the team is dedicated to meeting that date,” Lawley said. As a result, teams will cut down the time for testing the software in order to make the release date—and in some cases, eliminate it altogether. It’s a recipe for failure, of course. Without a high-quality product, your team is going to lose credibility in the organization and with the customer.
Solution: Fight for Quality Assurance resources.
Disconnect Between IT & Business Side
Developers often complain that the potential impact of a project isn’t linked to its budget (whether the cost or benefit). When there’s a misalignment of technical goals and the business side, expect an increase in program costs, staff impact and cycle time.
That dreaded “misalignment” issue can easily doom a project, said Tom Fountain, CTO of Pneuron, an enterprise solutions provider: “Forward-leaning businesses adopt a policy that all IT project benefits—lower costs to run the business, additional sales or margin, or improved quality—must have direct linkage into the operating plans of their sponsoring customers.”
Solution: As Fountain said, align the project’s budget with its importance and impact.
Image: Ron Frank/Shutterstock.com