5 Steps Before Commissioning Custom Software

Five Must-Do Steps Before Commissioning a Custom Software Project

There is almost nothing more important to your company’s success than your digital assets. Your digital ecosystem impacts profit as well as business valuation. Forward-thinking companies are investing in custom digital solutions designed specifically to differentiate them and give them a sustainable edge in the market.

With the future of your company possibly riding on your digital assets, it’s critical to approach any custom software project with a sound plan for managing it through its entire lifecycle. If you don’t plan properly, your software project can easily fail.

These five management steps will help ensure your project goes smoothly and achieves its objectives.

1. Assemble an Input Team

Before you start a software project, you need to have a core team in place composed of critical players. Most project teams are headed by a “keeper of the vision,” usually the executive who not only owns the strategy behind the project, but also has the power to say yes or no. Naturally, your company’s subject matter experts should be on the team in appropriate positions as well. If it’s a financial product, your accounting department should be represented. A manufacturing program team should include engineers. A medical software should be informed by the physicians and professionals who will use it. Beyond that, an effective team needs input from the foot soldiers who have been struggling with the tools that represent “the old way,” and who understand the practical aspects of the end product from a hands-on perspective.

The input team exists to define the intention of the project before a development team is engaged. They won’t interface with the developers on a routine basis (they may on a limited basis, on occasion). Their primary purpose is to make sure that the project is clearly visualized upfront and that every possible opportunity and threat is considered. To interface with your development team, choose one point of contact or a very small, focused team.

2. Write an Effective Project Brief

The work product from your input team should be a formal project brief. It’s not critical that the brief be perfect. It’s unlikely your internal team will include all the technical expertise you need to fill in all the details, but the brief should be as thorough as you’re able to make it. If you select the right development partner, they can help you refine your brief. Your brief should include the following key components:

Initial Concept: The initial idea should be a high-level overview that tells the developer what you are envisioning. You’ve probably written some sort of internal document describing the project; that’s most likely how you got the project to the point where you could begin to talk to developers about it. Your initial writings should be refined as much as possible so that someone outside your organization can readily see what you’re trying to accomplish. Your rough drawings on cocktail napkins and whiteboards should be turned into simple flowcharts and diagrams that illustrate the components of the application as best you can. These will contribute to the development partner’s wireframes, so they should explain it as clearly as possible.

Project Goals: What do you want this custom tool to do for your business? Are there specific sales metrics you believe the solution can help you achieve? Will the product improve your labor efficiency, and if so, how and by how much? Will it redefine your core brand value? Many organizations are building custom digital products to transform themselves from product and service-driven brands supported by digital tools, into complete digital value-delivery systems that are redefining markets. Think deeply about the possibilities and set your strategic goals as well as your operational goals accordingly.

Functionality Requirements: Your brief should tell your developers what the various components of the software should do. For example, you may be building a web app that lets customers configure a complex industrial product and then order it. You need to communicate this functionality to the developer. You should not need to tell the developer that when a user gets to a certain step, they should press a button or select from a drop-down; these are UX/UI design decisions that should be made based on best practices your developer should already know. A development firm that needs this sort of detailed input from you might not have the design capabilities to steer you from concept to completion.

Technical Requirements: You need to be aware of the platforms your software will run on, and the implications of those platforms on development. Your internal network architecture will dictate language options for products that are built to run on your own system. For web apps, the hosting environment must be considered. And knowing or deciding upfront what mobile operating system to design for is also critical. A company that issues Android devices to its employees will be fine developing an Android app, right up until management decides to switch to a bring-your-own-device (BYOD) policy, at which point a separate iOS version of your app will have to be built. Technical requirements are usually simple to document, but if they’re not correct from the beginning, the project can crash.

Operational Requirements: Your developers will need to know how many simultaneous users the product should support, what kinds of data will be uploaded and downloaded, and whether the product has to be compliant with any legal requirements (HIPAA, for example) or industry standards. Security requirements have to be communicated as well, and these can be complex. Does the product handle personal or financial data or sensitive or secret corporate information? Could a competitor copy or compromise your system if they got access? Do you need a certain level of permissions for one type of user and a different level for another? Does the software integrate with other products, such as your ERP or accounting software? If so, will it need an API (application program interface)? The more of these operational issues that are identified at the outset, the more accurate your developers can be in projecting a budget and committing to a schedule.

Your Desired Schedule: It’s important to document benchmarks and deadlines and to discuss these in detail with your development partner. If you have a major launch or promotion, or a strategic milestone the product has to coincide with, shortchanging the scheduling process can be disastrous. Knowing your needs allows your providers to manage their workflows to deliver what you expect when you need it. In cases of extreme deadlines, you might want to consider a Minimum Viable Product (MVP) approach, which means a limited but functional product can be delivered by a certain date and then updated to its final form after critical benchmarks are met.

3. Understand the Landscape

There are many variables that affect a software plan, and to be successful, it’s critical to consider as many of them as possible. An obvious element of the software development landscape is budget. What you ultimately get is dependent on what you spend, but as you take your project out for bids, you are very likely to get back a wide range of pricing. A development house that sells purely on price or seriously underbids competitors is very likely to end up having to add change orders to make up for what they left on the table in the bidding stage. That shows, at best, a lack of understanding of the project, and at worst, a willingness to be dishonest. It’s a good idea for managers to research the custom software marketplace to get a sense of what development projects cost.

It should go without saying that experience – on the company level and the individual employee level – can play a huge part in the success of your project. Are the leaders of your development firm seasoned business people who understand your situation? Or are they, like many in software, younger specialists whose expertise is primarily technical? Do they really have the breadth of experience to see your objectives as business problems and technical problems at the same time?

It’s also important to establish with your development partners an understanding of the culture of the users you want to reach. Some things that may seem obvious to people in your own culture require unexpected explanation to overseas developers. Communication is critical to a successful digital project, and it generally goes deeper than mere language, which is really the easiest barrier to cross.

Before COVID, the ability to meet face-to-face was important, and we believe it will be again one day. Fortunately, teleconferencing can put you “eye-to-eye” with your working partners now, and that makes a huge difference in establishing rapport.

4. Leverage the Project’s Brand Asset Value

We believe your brand is, at its essence, your underlying promise of value. So it follows that your digital ecosystem is a fundamental component of your corporate brand. More than just adhering to the parts of your brand style guide that apply to UI design, custom software becomes a measurable asset that can impact your brand in many ways. Tools that improve performance and reduce costs have a direct impact on the bottom line. Systems that enhance processes and stakeholder engagement attract people who create long-term value. Technologies that provide substantive differentiation give you a sustainable advantage that is difficult to co-opt or copy.

When you’re planning a custom software project or digital transformation initiative, do a thorough analysis of how it will add value to your brand and pay off in sales, talent acquisition, operating profit, market position and equity. Oftentimes, even a relatively simple software product can be leveraged to increase tangible or intangible value.

5. Plan an Effective Testing Regimen

A critical, but often underemphasized, phase of custom software development is testing. It is almost always more time-intensive and difficult than expected. You should count on testing to be a significant portion of the effort you make in launching an effective software product. If your product goes into service without adequate testing, there’s a good chance you’ll have some sort of costly failure that costs you time, money or reputation.

Talk to your development team about their internal testing regimen. They should approach testing your product from the point of view of a real user, and not just from the standpoint of a technician. A good firm will have a set of guidelines and digital tools they use internally and make available to your testing team, which will help ensure thoroughness and clear communication.
Your testing team should include a mix of stakeholders with different points of view. In addition to the executives and managers who have commissioned the project, you should include staff personnel as well. Perhaps most importantly, you should recruit a team of beta testers from your most engaged customers. Such inclusion can go a long way to locking in loyalty and can give you the most valuable feedback.

Make sure your testing system limits the type of generalized feedback that focuses on “great ideas.” You’ve already had the great idea and you’ve already shelled out to build the great idea. “Improvements” are likely to result in change orders once you’ve reached the testing phase. Testers must be given clear guidance on what to look for and should focus on whether the product will achieve the objectives you established at the beginning of the project.

By following these five steps before you embark on a custom software project, you lay a proper foundation for success. By skipping a formal project planning process, you run the risk of failing to foresee obstacles that may arise, under (or over) budgeting the project, missing critical opportunities to solve problems and build value, and not giving your internal and external teams sufficient time or resources to deliver what you really need.