What Are the Problems With Making Changes to My Custom Software Project?

Here at SOLTECH, we get this question all the time: “What are the problems with making changes to my custom software project?” Everyone changes their mind from time to time. In software development, sometimes things come up that make us change our decision on something or create a need to alter a project. It’s inevitable. We understand this is something you may be worried about. The answer is – it depends.

It depends if you’re asking the developers to change the color of a font or asking for an entirely new function to be added. Regardless of the size of the request you make, your changes can affect many things. The two focused on in this article, are timeline and budget.

So in short, no, you cannot make any changes to your custom software project without any problems — but the size of the “problem” will depend on your request.

Can I Exchange This?

Like stores have return policies to exchange or return items we change our minds on, developers are going to understand that you’re likely going to want to make changes to your custom software.

Unfortunately, you’re not going to find an exact return or exchange policy at the bottom of your receipt when “ordering” custom software from a developer. Instead, you’re going to find out how your changes may affect your project on a case-by-case basis.

Keep in mind, one of the best parts about working with a local agency is that you have the ability to meet in-person to not only review the project but also to do the initial discovery phase. These make communicating your requirements and requests to change things much simpler than having to consistently communicate via email.

Let’s go over a couple of situations to help you better understand why changes can affect your timeline and budget.

Change Is Hard (to determine and price)

Undoubtedly, making any size change to your project will affect your budget and the length of time needed to get your project to you. These changes may be critical and worth affecting both the timeline and budget or, once you’re given an answer of how these things will be affected, you may say never mind.

This is why it is important to leave some “wiggle room” in your budget for things like this as well as extra time in your timeline in the event of these occurrences.

This also falls under the “perks” of the working methodology Agile, where the team works in two-week sprints, giving you updates after each milestone. With that, there’s more flexibility in making modifications to a design right away, versus using Waterfall where the entire project is done from start-to-finish without you seeing the results until the very end.

Making Small Changes to Your Custom Software

Asking your UX designer to change a font style or a font color sounds easy, right? You’re right, it is, but there are things to consider if you request this type change.

Is your application going to be translated into other languages? Then the font could create an issue. Are you asking for the font to be bigger or smaller? Don’t forget, it needs to be able to scale.

In the end, the developer’s goal is to ensure you are happy with the project. It’s important to think of it as people think differently and communication is extremely important on both ends to make sure things are the way you want them to be.

In this example, this should not be a very time-consuming task, but do remember that more hours are going to be added to your project in order to implement the requested changes. More hours, mean more money and more time added to your projected release date, which means you could be affected to a degree.

Don’t hesitate to communicate clearly with your UX designer and also incorporate links and images of examples in your conversation. The more ways you communicate the inspiration behind a need or want for your project, the better results you’re going to get straight from the start. This saves you time and money as these changes won’t need to be made later on.

Large Scale Changes

Adding new functions, like the way a customer registers as a user on your application or having to suddenly comply with HIPCA regulations, however, are large requests. These will absolutely end up costing you more in the end. Be sure you have as many ducks in a row as possible before giving the green light to the developers to start your project to avoid cost and time additions such as these.

Is It Worth It?

Unfortunately, you can’t request a two-door convertible sports car on a four-door sedan budget. Developers can’t make magic happen. What they can do is take all of your requirements and wish-lists and aide you in categorizing them by priority and capability.

If a change does come up, be sure to communicate this to your project manager right away so the developers do not continue to work on something that may be scratched.

Only you can decide if making any sized modifications are worth increasing your budget and timeline. You can, however, ask for second opinions. Ask your team and ask the developers for their input:

Is it something you can add on later with a different budget?

Is it vital to make your application work now?

To help determine if these changes are necessary, ask yourself these three questions:

Do I need it? Or do I want it? (think special features and unnecessary functions)

Will it make the product better?

Be sure to ask yourself what matters now in order to get the project out the door and in the hands of your customers because ultimately, that will be the most important.

What Are My Options? How Can I Avoid Major Changes?

Well, you can break the project into two stages in order to fulfill the extra functions and designs with a second budget, obtained later. If you go that route, be sure to let the firm know in the beginning so that the project can be made extensible.

Another option to note is the Minimum Viable Product. The best way to explain MVP is this: you want a donut. The most popular donuts always have frosting and sprinkles on them, but in order to serve someone a donut, do they necessarily need the frosting and sprinkles to eat and enjoy the donut? No. Would they like it with those things, though? Probably. Does it make the donut better? Sometimes, but it depends on who you ask. Some may prefer the plain donut while others may crave the extra toppings.

The point is, sometimes you need to create a simpler, but still useful, product in order to avoid ballooning costs and to speed up delivery time.

Test, confirm repeat. This will become your mantra when developing software. Continually testing the product and confirming the developers are going in the right direction, or, being able to give them feedback on what needs to change will assist in ensuring things are done correctly and timely each round.

Above all, the best thing a client can do is have a clear and concise idea of what you need your project to do before you start having it developed.

Don’t forget to grab a copy of our FREE e-book, 6 Non-Negotiable Items of Successful Software by downloading it below!