Exploring the Challenges of Digital/Software Projects: Avoiding Common Pitfalls

Many digital, software, and IT projects encounter difficulties due to issues with scope and timelines. One of the biggest challenges in developing software is managing scope, as it can be frustrating when the scope of a project changes or was not detailed enough from the start.

This is often caused by people underestimating the complexities of developing software and not providing developers with enough information to understand the project’s needs. Timelines also play a role in project failure, as a lack of detailed scope can lead to features and functions taking longer than expected to implement.

To avoid these issues, it is crucial to spend more time scoping projects. This includes detailing every feature and function that needs to be built, and spending additional time on the user experience and wire-framing components of the project before any code is written. This allows both the client and developer to understand exactly what will be built, how it will function, and what data will be saved. If additional budget is needed, it is important to let the client know, and if necessary, charge for scoping services. While it may not solve all issues, investing more time in scoping can help ensure that both parties have a clear understanding of the project and can avoid misunderstandings and delays. 99% of the time it comes down to two reasons; 1) scope and 2) timelines.

1) Scope

I can almost guarantee that from the outset of every single digital/software/IT project everyone involved wants a good outcome; designing and building software would have to be one of the most enjoyable ‘jobs’ you can be in, for both client and as a developer. It’s by no means easy though; developing software is hard and at times can be super frustrating. The hard part isn’t usually coding or building the product though (although there will be hurdles; code that doesn’t work, bugs to fix &/or functions and features that take much longer to implement than expected — you can counter all of these things with padding time in your scope) by far the biggest hurdle and frustration is scope; or more, changing scope or scope that was never even close to detailed enough from the outset.

 

UX design

Simply put its people; people are wrong all the time and people don’t really know what they want…

So why is this? If everyone has the projects best interests at heart from the outset why do so many go astray along the way? Simply put its people; people are wrong all the time and people don’t really know what they want, they think they do but they don’t. You’d be amazed how many clients we’ve worked with over the years that have an almost overconfidence bias yet may have never written a line of code in their lives or been involved in a complex digital, software or app project prior; or even if they have they assume this one will be the same, better, easier, different. People unfortunately underestimate the complexities of developing software so simply underestimate the need for providing developers the detailed scope they should be from the very outset; this could be related to the dunning-kruger-effect.

The unfortunate issue is both parties i.e. the client and the developer/business delivering the work are susceptible to these problems as both parties involve people (I know I am!); the client thinks they’ve provided all the info they should and assumes they have thought about everything they need the project to do; and so in turn the developer also thinks they know exactly what the client wants.

Then the client realises they need more along the way post-quoting or even worse post-delivery of the project or a part of the project. This can then become an issue for both parties especially if a fixed-quote has been provided; the client becomes shirty because they expected XYZ but only XY was quoted for OR because XYZ was quoted and delivered but X also required X.1, X.2, X.3 > X.18! but the client didn’t advise of this need in detail during the scoping stages (it was assumed the developer would just ‘know’). It’s pretty obvious why this would be an issue for a developer/business; i.e. they quoted 200 hours to deliver XYZ but they thought X needed 80 hours when in fact it alone needs 160 hours of development time.

 

2) Timelines

This goes almost hand in hand with scope; when the client thinks they have provided all the intricate details of a projects requirements to a developer and the developer provides an itemised quote and even line item costings to each function within the project scope all is fine at the kick-off; things can however go sideways when a simple feature or function that was scoped to take 8 hours ends up taking 16 and then the next which was scoped to take 16 takes 32, 10 takes 40 and away we go; all because scope was not provided properly or in enough detail from the outset. If more money/budget is available to allocate to these features not properly understood its fine; but sometimes its not.

Further, and more inline with timelines, is the actual delivery and go live dates of a project; i.e. if we go back to our XYZ example, how can a developer or business provide a delivery date based on XYZ if they never knew about the detailed points outlined in X.1, X.2, X.3 > X.18 — you know the ones that the client assumed the developer already knew.

 

So how do we fix these issues?

I’d say that is is obvious and unfortunately it is – but again its not easy…. it still may not solve the issue as people are still involved and as people we all make mistakes and assumptions; on ourselves and on each other.

SPEND FAR MORE TIME SCOPING! Far, far, far more time scoping; detail every feature and function that needs to be built line by line, spend additional time on the UX/wire-framing component of the project BEFORE a single line of code is written so BOTH parties know exactly what is being built, how it will function, what will happen when you press a button, where it will go, what data will be saved, what reports can be generated, etc etc. If things are picked up here great! Will it cost more? Let the client know then and there, if they can’t afford to build all the points in X.1, X.2, X.3 > X.18 now then so be it, you can only build X.1 > X.5 now for their available budget, the rest can be built later when more money is available. If need be (and possible!) charge the client for scoping too, especially if it will take a long time.

Everyone involved in the project needs to be 100% aligned. After all of this unfortunately things may still go amiss though…why? Well, because people; people just don’t really know what they want sometimes or they simply assume you know what they want, or you assume you know what they want.

Like anything this is all ‘easier said than done’ but take your time with scoping; get it right as best you can.

This article was originally posted on Medium as Exploring the Challenges of Digital/Software Projects: Avoiding Common Pitfalls