I remember going onsite to visit a customer in 2020, and their QMS software had not been updated since 2008.  Keep in mind, most cell phones still had a stylus in 2008.  Yes, that long ago.  I remember discussing with them the reason they had not updated since 2008.  “Our system is too configured to update.  It would take us years”.

The definition of software evolution is “… the continual development of a piece of software after its initial release to address changing stakeholder and/or market requirements. Software evolution is important because organizations invest large amounts of money in their software and are completely dependent on this software.” 

So, what’s at the core of the issue?  Well, there are several components.  Let’s break those down:

Flexibility of Business Processes

This one can be a bit tricky.  As a consultant, you want your customer to be happy, and provide as much benefit to the software as possible, so configurations can get technical, and large.  Additionally, your customer might not want to adjust their business processes to fit the software.  Finding middle or common ground to resolve this can be tough, so balance is key.  Creating a list of deal-breakers for the customer is necessary when things start down the path of heavily configured”.  A deal-breaker list forces them to think more deeply about what truly cannot be passed up at the moment, and what can be added later.  Along with the deal-breaker list, the implementation team needs to be cautious during the build, to ensure whatever deal-breakers need to be built, they are done so to allow long-term flexibility with the growth of the system.

Start Small, and Scale

This works directly with #1, but needs to be discussed up front.  When you over-complicate your QMS software system from day 1, you will fail.  From changes in personnel, not documenting the process or providing clear and concise training, anything can happen to make your software difficult and challenging to use.  Start small, and scale as you need.   Unless the customer buys a huge amount of hours, and the desire to build a massive system is discussed up front, with all the caveats, and requirements,  start small.

Train, Train, Train

When users are not comfortable with the software and there are gaps and challenges, they will be unhappy, and that can quickly escalate to the top, causing challenges and questions to whether the right software was chosen.  When this happens, it can take a long time, if ever, to get buy in from top management again.  Make sure that training is delivered in a very concise and structured roll out.  If there are bugs or gaps, make sure they are noted and identified that they will be addressed, and if there are any workarounds currently, point those out.  Training can be the difference between calm, or a storm. 

While this list is not exhaustive by any means, it does cover a few of the key areas that should be addressed before any QMS software project gets going.  If you need help identifying your gaps and direction, or you’ve built your system and you need concise training plans developed, call us.  We can help.