This is one of the crucial reasons projects can be unsuccessful. You <u>can </u>bring a project in on-time and on-budget, but if it’s not fit-for-purpose then it is not a successful project.
In our previous article we briefly compared two project methodologies: waterfall and agile. If you have a waterfall approach and you spec out what you want and you deliver exactly what you specced out, then from one perspective, you can say “it was a successful project”. However, if it didn't actually <u>solve the need</u> that created the project in the first place, then you can equally say that it was a failure, regardless of whether it met the functional requirements outlined.
There are a lot of examples of this. For example, government projects are typically over-time and over-budget. And, typically, they're actually not very fit-for-purpose.
Why does it happen?
In one sentence: not capturing the technical requirements.
What do we mean by that? In additional to the functional requirements we covered in a previous article, when you sit down to architect a particular piece of software, you typically have in mind some aspirations for things that you want to achieve technically. Some of those aspirations may be requirements to meet particular goals related to how we're going to be using the software.
Performance requirements: how fast does it have to do this particular job that you need it to do?
Scalability requirements: is this going to be used by 10 people? (In which case you probably don't care how scalable it is) Or is it going to be 10 million? (In which case you do, or should, care)
Security requirements: if you're a financial institution it's baked into your bones and everything you do is looked at through that lens, but there are times when you might be building an application that has very low security requirements.
Maintainability: how easy is it for the support teams that have to look after this software to actually maintain it? How easily can someone who's supporting the software understand what has happened, what's gone wrong, and then fix it within a reasonable period of time?
Technical debt: Any time you make a change to a piece of software, it increases what's called the “technical debt” and this technical debt is simply the amount of effort that it takes to make a change to the software.
If you have a software that has very low technical debt, then you might be able to add some simple feature within a day. If this application has high technical debt, then the development might take a week to be able to implement it because “under the hood”, it might be “spaghetti code” (code that is very poorly put together, very poorly architected). This might simply be the result of a lot of rush jobs and a lot of things that people have said, “Oh, I'll come back and fix this later. For now, I'm just going to get it working quickly.” Every time someone makes that decision, it increases the technical debt because it increases the cost of making changes in the future.
Usability: If you get an engineer to design a user interface, it'll work, but will it be designed in the best way for the end-user? Generally speaking, engineers don't do the UX and UI design. That’s left to qualified UX/UI designers.
What happens if you don’t get it right?
Scoping the project correctly is so crucial. If you miss any of the requirements because you didn't ask the right questions or you didn't look at it from enough different angles – or if you design systems <u>without ever actually talking to the people that were intended to use the system</u>, then you’re bound to have a project that is not fit-for-purpose.
I have seen this happen. The end result is an embarrassing situation where they show it to the users, thinking ''Hey, they're going to be so excited! Look what we've built for them.'' Then the user turns around and says ''I can't use that because it doesn't do this, or it doesn't do that.” This is a classic example of** not doing the work upfront to figure out what you need to build**.
The MVP solution
I'd like to finish this article with the concept of the minimum viable product. Sometimes it is appropriate to create one and sometimes it isn't.
If you know you've got product-market fit and you know that you've got requirements captured, then you possibly don't need one. For example, if it’s an internal tool that you're developing for your own business, to be able to achieve some business objectives, then you probably don't need it.
However, if it's something that you haven't established the product-market fit for, or if you don't know that you've necessarily captured all the requirements, then I would hundred percent recommend doing a minimum viable product.
This means doing the *least *amount of work possible to understand whether you've got that product-market fit. If you do find you’ve got product-market fit then you can move forward with confidence and build on the product with the feedback you’re getting from your market about the features that they would like to be in the software. All without spending time and money developing a fully featured product where you don't have product-market fit and nobody wants it. A situation you most definitely DON’T want to be in.
If you’ve got a software project idea that you’d like to discuss, CLICK HERE to book a time for a scoping call to run through your idea.