It takes the creative resources of an entire organization to ship a successful software product. Marketing, design, infrastructure and engineers must all come together in a technical ballet of brilliance and coordination. Proper organization of all these people and processes is not a solved formula. There is no development methodology that ensures success 100% of the time. Knowing this, what are some warning signs that things may not be going according to plan?

There is no plan.

The plan for What the #%*&! is this software supposed to do? doesn’t exist, or changes at the whim of the executive sponsor or product owner. Moving goal posts and expanding scope demoralize and destabilize the project more than anything else. If your project is following some flavor of ‘agile,’ be sure to make functionality adjustments after the work is done so the product can be evaluated as a whole. The product plan doesn’t necessarily need to be technical. It can be a summary of goals, such as “allow customers to connect with their dogs in a curated safe space.” Evaluate any feature change against these goals.

Leave Quality For Last

“Quality” is not a completable task that can be lumped together with other project requirements. Quality must be an ongoing part of the development process through unit testing, integration testing, manual testing and user feedback. After each project milestone, the state of the project should be assessed in terms of time, budget and quality (via number of bugs or user reported defects.) Massive dips in quality are signs that development needs to slow down to do things right. Poor specifications and vague business requirements also impact the perceived quality of software product. Specifications aren’t required to be overly technical, but should at least include success criteria.

Low Morale

Hard work doesn’t make talented people quit jobs, but low morale often does. Low morale is typically a symptom of other organizational dysfunction, and can kill any well-planned project. A toxic work environment sucks up creative energy and expends it on petty infighting and territorial politics. What can you do if the team is in a funk? The causes of low morale are complicated, and often grow out of long-term resentment and frustration. There is no fix-all cure, but recognizing low morale exists and guarding yourself against its effects can act as a hedge against the productivity-sucking effects. Be mindful of how much you and others on the team complain. Make an effort to be constructive and suggest solutions when identifying problems. Laugh at the chaos; it’s just a job anyway.

Missed Deadlines

Of course, missed deadlines are the clearest sign that the development process is not proceeding according to schedule. A well-run organization will take this feedback and make necessary adjustments, such as streamlining project requirements, cutting back on time-wasting meetings, or better facilitating collaboration between stakeholders. A poorly run organization will double-down and impose harsh penalties on missed deadlines. The solution to not miss a deadline is to simply work harder, right? (just kidding.) Re-evaluate scope and cut frivolous features to get back on track. Pay down that technical debt!

Poor Coordination

Tribal knowledge, poor communication and lack of documentation all hamper the flow of important information. Poorly defined processes (or no process at all) are signs of inexperienced leadership who prioritize ‘get it done’ over ‘do it right.’ Without properly defined channels, it is difficult for people to coordinate across functional boundaries at scale. Political silos and departmental infighting can ruin a project faster than bugs or bad code. Consider information and processes to be like blood — good circulation and organization make a healthy team.

Skipped Input

Custom software is not the type of product which can be ordered from a catalog and shipped reliably at scale. The complicated nature of tech requires technical stakeholders to be involved in the planning process to ensure specifications are feasible (and if they aren’t, what it would take to make them feasible). Input from the people entrusted to do the work builds a sense of buy-in from everyone involved. Excluding technical leadership from the process all but ensures disaster, as the timelines and specifications will most likely be either impossible, or so vague that success is unattainable.

Unproven Tech

New, shiny tech is enjoyable to play with on hobby projects, and that’s precisely where it belongs. Employing trendy but unproven tech not only means every engineer is inexperienced, but that scalability requirements, architecture and edge cases are all unknown or untested. It may look like the cutting edge choice during system design, but it introduces an inordinate amount of risk that could easily be avoided. Stick with what your team knows. If it requires ramp-up time to become familiar with something different, be honest about what it will take to achieve a professional level of competency.

If you recognize these danger signs in your software development project; failure is not imminent. Now you know what to look for and what to avoid in order to turn it around.