software project red flags
SHARE:

Software Project Red Flags

Spread the love
Reading Time: 3 minutes

Every developer has experienced a project gone wrong and if you haven’t you will. In order to help you work out when things are going wrong we have a few software project red flags to watch out for. We’ll also include some tips but in some cases it’s just time to call it quits.

my face when poor requirements

#1 Poor Requirements

Ill defined or poor requirements in a project is the kiss of death for most projects out there. As a programmer, stringent and well defined requirements are the cornerstone of a successful project. Without that even the client is generally unsure of what the end result is going to be.

Expectation and poor communication is ultimately what will kill the project but the requirements are where we begin to see the cracks. We actually have a whole article just on requirements engineering that you can find here. Assuming the requirements can’t be salvaged then the project should be declined before it gets developed.

#2 Scope creep

Scope creep is another common project killer. It’s the allowance of someone to introduce additional scope in the project whilst keeping the deadlines and budget exactly the same. The best way of dealing with scope creep is to allow more time for requirements and work to an MVP. If your new scope is written into well defined tickets then it will be estimated for separately.

Generally allowing for this amount of granularity should stop scope creep in its tracks. Scope creep usually stems from poor client management and workflows. If you’re client management and your workflows are set up correctly you won’t encounter this issue.

softare project red flags

#3 Technical Difficulties

Not just a Racer X song. Technical difficulties cover a wide range of topics, most notably, technical feats that are not possible or will take way longer than the original timeline will allow. This mainly comes from the developers themselves not having enough experience dealing with projects of a specific kind.

The best thing to do here is account for a prototyping stage where you can build a reasonable proof of concept. Then you should be able to better estimate what it will take to build the full project.

#4 Aftercare Expectations

So you have developed an amazing software or website and now it’s out in the world. Now as users do, someone finds an issue or there’s something unexpected that it should have done. The grey area in this scenario generally leads companies to panic and just get it done without charging the client.

The best way of dealing with this is to offer aftercare packages for clients so that as problems arise you can budget fixing them without a huge amount of pressure.

#5 Too many cooks

So this is something I have experienced before where there are too many clients trying to give conflicting requirements and priorities. This is a relatively easy fix. Have the client go through a single mouthpiece. This streamlines the process for the development team and has reasonable sign offs from the client’s ambassador.

Making the ambassador sign off on the project at each stage also serves as their responsibility to check they are happy with the product before it goes live.



I hope this helps to serve as a good guide for your future projects. If you have experience with other software project red flags in projects please post them in the comments, we’d love to hear from you!

Written by

Dominic Cooper-Wootton

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.