HITORI

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

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

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

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 Creative Technical Director – founder at HITORI

Digital Transformation: The Key to Future-Proof Your Business

Opportunities in HealthTech and Healthcare

What is Digital Automation?

We work with innovators to build digital products that improve lives

W2 09 / 87 Gladstone Street, South Melbourne, VIC 3205 (03) 9682 8003 hello@hitori-inc com Copyright © 2011-2023 Hitori Pty Ltd – Privacy Policy – read our FAQ's Hitori acknowledges the Wurundjeri people of the Kulin Nation who are the traditional custodians of this land We pay our respects to Indigenous Elders past, present and emerging Hitori embraces diversity and celebrates all people