The building process of your development project begins once an agreement has been settled between you and your developer, regarding all the requested technical requirements. However, as an entrepreneur, you may sometimes change your mind regarding some features and decide on a different route, even during the building process. Requirement changes are alteration requests that the client asks for, that fall beyond the scope of the initial agreement. The timing and nature of those changes may result in additional charges, and therefore should be carefully considered.  

As an entrepreneur, it is advised not to allow requirement changes while the development phase starts, so that you can control your budget and time. 

There are four situations when you can allow requirements changes:

  • A major event that changes how you fundamentally do business 

Unexpected events can make your initial hypotheses and theories no longer relevant. For example, if COVID-19 strikes while you are building a new software to help people meet offline, then your software is no longer significant. However, it all depends on your goals. If you want to start generating revenue in a few months, then the project is bound to fail. But if your initial goal is for the longer term, then go for it. 

  • You discover new information about your target customer that makes your project useless

Here’s an example: I once built a platform that filters freelance jobs from the web, presenting me with the jobs that are exactly relevant to me. Doing so would allow me to apply to jobs that reflect my expertise. However, freelancers were not interested and there wasn’t enough demand. It turned out that most freelancers get clients via word of mouth, while those who are not specialized use Upwork. Therefore, I always research your ideas before starting to code.

  • Not changing puts your business at risk

If you have an accounting software, and 90% of your revenue comes from one client, you have to answer their every request. If they ask for a change or else take their business to another developer, then you can’t refuse. Therefore, make sure to assess the whole perspective, including the business one. 

  • You realize you’ve been missing a major feature that your project cannot launch without 

Do not launch your business unless it is completely ready and usable. For example, if you are creating a customer relationship management software but don’t have the ability to add customers, then what’s the purpose of the project?

There are four situations when you should NOT allow requirements changes:

  • Remove all bells and whistles that can be added in a future version

Bells and whistles are anything that doesn’t prevent you from selling your product.   Start building the initial version of your product that you can sell, and postpone features that you can develop in a future version. 

  • If you are constantly jumping from one project to another

If you start building an accounting software and then decide you should add support ticketing, an invoicing system, a client management system, etc. At this point, you are being distracted and should stick to addressing one business problem at a time. 

  • If you’re not convinced you should change 

You should only change what you’re working on if you are personally convinced you should, regardless of anyone else’s opinion. For example, as a developer, I personally choose the projects I work on based on strong convictions I reached after my struggle with porn addiction for 10 years. I nowadays turn down any client seeking to build a project related to porn. Always do what you think is right for your project or your business, regardless of how much money you can make or what other people think you should change. 

If you are interested in building software on time and on budget, then this course is exactly what you need. I have shared a link below the lesson’s video that will give you a whole strategy that you can apply to achieve your goals.