When it comes to technology, the buy vs. build conundrum is particularly problematic. Both approaches are the right way to go and both are wrong for you. It just depends on how you answer critical questions, like these five:
1. What is the need you are trying to fill? For example, is the need for a website, or is the need that customers be able to retrieve updated project documents? A website, program or app is just a tool, and before you know what tool you need, you have to know what you’re trying to accomplish.
2. What are the basic requirements? In any company big enough to be considering a custom programmed solution, bringing in different teams to collaborate on requirements is important. You have to get end users and line staff involved in any discussion to make sure that you know how things really need to work.
3. What are key design factors? A lot of this is needed for any RFQ:
High availability: Is it a 24X7X365 function that is critical to the business? If so, factor in redundant servers in diverse locations, the ability to switch over automatically and functionality maintained dynamically.
Integration: Make sure you know all the systems you may want to integrate with.
Operating systems and devices: Who is going to be using the system or site? If it’s public-facing, you will need to make sure it will work with all kinds of devices, browsers and operating systems.
Security: Will you be accessing or collecting any sensitive data here? Credit card numbers, customer information? If so, you just kicked up to a new level of design. If you are holding sensitive information you want to take every possible step to secure it.
4. What’s out there already? Once you know what you want in a system or application, you have a blueprint for exploring what is already out there. Check out websites, ask vendors, look at other sites. You may even be able to do some competitor research. If you find an app or cloud application or service that seems to do what you want, contact the company for a free trial. Ask questions about security, backup and redundancy.
5. What can we support? Customization is not a write-it-and-forget-it process. Security particularly is a function requiring constant diligence. If you have a public-facing system, like a website, you will need to be prepared for thorough testing when new operating systems come out, when one of your integration partners changes its software, when new devices are released. If you don’t have the staff or the budget for thorough maintenance from an outside developer, you may need to back off of building it and move into “buy it.”
These are a lot of questions – not so many answers. But, in the words of a friend, you don’t know what you don’t know. Once you know the right questions, the answers and the path they lead you down will be a lot easier for you to figure out.
[break]
Laura Haight is the president of Portfolio (portfoliosc.com), a communications company based in Greenville that leverages the power of technology and digital media to communicate effectively with clients, customers and your staff. She is a former IT executive, journalist and newspaper editor.
