This is part two of a two-part post examining the use case for moving your business from spreadsheets to custom software. Part 1 helps you identify whether you're at an operational inflection point, and this blog offers considerations to help you manage this transition without sacrificing the qualities that make your business successful.

Pick the right person to manage the project

For a new software project, a product manager is one of the most important roles that a business can have. A good product manager is able to synthesize the business’s needs and desires and communicate them effectively to the developers. Although many small businesses and organizations may not be able to hire someone to fulfill this exclusively, a stakeholder can play the role effectively. Regardless, the role remains a critical one and should not be overlooked, and every business should be careful that they choose the right employee for this all-important role.

The person inside of the business who is chosen should understand and buy into the vision of the application. They should know the business well, and also be invested in the success of the new application. While being technical is not a requirement, they should be comfortable using and working with technology. Someone who is used to working with technology will often be able to make intuitive and accurate judgement calls when it comes to decisions regarding the product’s implementation. I have seen developers build applications that don’t fully meet the business’s needs because the person that the business assigned as the product manager didn’t have the knowledge, insight, and intuition that was needed. In each case, the person either ended up quitting or being let go.

Custom software projects can go haywire when the product manager isn’t on the same page as other stakeholders in the business. A few simple checks and balances can go a long way to ensure that the product manager you have selected is on track for making sure that the developers deliver an application that meets the business’s needs:

• Ensure that they are able to articulate the vision and objectives of the project before the project begins.
• Have stakeholders sit in on demos of the application on a regular or semi-regular basis.
• Have regular check-ins with the person fulfilling the product manager role and have them discuss how the project is meeting expectations.

Choose the right developer

Not all software developers and software development firms are created equally. If you are making the transition to custom software for the first time, the best thing you can do is invest wisely in the appropriate person or firm to complete the work. What often happens is that businesses hire people they know without a full understanding of whether that person is truly the right one for the job.

While not an exhaustive list, below are a couple of key questions you can ask to help determine whether the person or agency is going to set your software up for success:

What are the developer’s testing practices?

Test Driven Development (TDD) is a preferred practice that ensures there is unit test coverage for all production code that is written. All software applications should grow and change over time. When new developers must roll onto the team, unit tests can serve as extra documentation, as well as a security blanket to know their changes are not breaking any of the existing functionality.

What is the development philosophy?

You should not consider a developer who does not have a well-articulated approach or philosophy to writing software—period. Most of the applications that my team has had to salvage are due to the fact that there were no apparent overarching principles that the previous software developer or developers used to construct the code. The result is spaghetti code—code that is difficult to understand and maintain. Having someone to be able to articulate how the code they write will be maintainable should be a top priority. For example, we rely heavily on SOLID Principles and Agile development practices to inform how we design and deliver the code that we write. Bonus points should go to the development firm that offers some sort of guarantee that the code they write will perform as expected, and are willing and able to maintain the code that they write.

Preparing for Launch

The most successful software launches that I’ve been a part of are the ones where we were able to find a way for the business to be able to begin using the new custom application with a small group of clients or in a specific department of the business. This has a couple of distinct advantages.

First, it enables both the business and developers to be able to test out their assumptions in real life scenarios. Until a member of the business is actually using the system as they would throughout the course of a normal day, it’s hard to get accurate feedback on whether design and development assumptions were correct.

Second, change is hard. So, finding an incremental way to introduce a large operational change is typically a preferred approach—especially when there are a lot of staff members to consider. If you’re able to have one department at a time begin adopting the new system, you lessen the risk of having a major disruption in your business. At the same time, you’ll be able to gain more internal advocates, as well as people who can help others as more and more departments are introduced to the new application.

Post-Launch

After your new software application has been launched, it’s important to keep in mind that two distinct streams of work will remain:

Ongoing Projects

Software applications should grow and change over time. This is especially true if your initial launch was an MVP with limited features. But as your business needs, your customers, your industry, and the society change, you’ll want your software to remain relevant. It is normal to have ongoing projects for the purpose of responding to these changes. These projects may be big or small, and they may or may not run in rapid succession. Those decisions will largely be based on your particular business and budget.

Support and Maintenance

No application is ever perfect at its onset. Of course, this does not mean that it should be unstable. Far from it. You should expect a stable system. However, you’ll likely find that there will need to be small tweaks and changes to how the software is operating to accommodate new edge cases you didn’t anticipate. Additionally, since all modern applications rely on other software libraries, ensuring that those libraries are up to date should remain a top priority.

If you choose to have one development team handle both streams of work simultaneously, you’ll need to make sure you have the proper expectations—recognizing that a focus at any given time on one particular stream of work can mean delays for the other stream. Otherwise, this can be solved by organizing the two workstreams appropriately and assigning a separate team or separate developers for each. In either case you’ll see that supporting and maintaining the software application will always be a priority.

Moving Forward

Once your custom software is live and your business is starting to get into a new flow of operating, you can celebrate making it through an operational inflection point. It won’t be the last one, but growth and change will reveal new ones over time.