Executive Overview

From time to time, an organization is faced with a problem that can be resolved or improved by automation. You should first look for an off-the-shelf solution. Off-the-shelf solutions are shrink-wrapped software which has been designed and developed to solve a specific problem; a problem likely faced by many people or organizations. An off-the-shelf solution that is a good fit will be a more cost effective solution because of the obvious power in numbers: the more copies of a solution that are sold, the lower the cost of each copy.

If an off-the-shelf solution can NOT be found, there is an alternative: a custom built solution. A custom built solution can be built to your exact specifications and process. The following notes provide some perspective on stepping into the realm of commissioning a custom built software solution.

The Assessment & Decision for Off-The-Shelf vs. Custom Built

Simply put, if an off-the-shelf solution is available, use it. It will cost you less over the long haul. If an off-the-shelf solution isn't a good fit, investigate whether there is a close fit that can be customized. And if you must endeavor into a custom built solution, follow these guidelines to maintain control of the development and implementation process.

The following are points to consider when searching for a solution:

• Choose a shrink-wrapped solution when it is a good fit to reduce expense.
• Find a 'close enough' solution when there is no possible way to fund a custom developed solution.
• Choose a custom solution when your need (problem) is unique.
• Choose a custom solution if you want absolute control over the shape of the solution and its functions.
• Consolidate change requests when possible to reduce the cost of the changes.

The Development Process

The development process will vary, depending on what your requirements, goals and budget dictate. The more complex the design, the deeper the process may become. On simpler projects, some of these steps may be combined. On larger projects, some set of these steps may have to be repeated to refine the resulting solution. In general, the process is as follows:

1. Define the purpose and scope of the solution.
2. Define the intended audience/user group as well as their general knowledge level.
3. Define whether the solution is to be used internally, externally, or both.
4. Lay out a flow diagram of where information comes from and where it goes to: system to system, people to system, etc.
5. Identify existing data, reports, and forms that are relevant to the problem or solution.
6. Design (diagram) solution infrastructure and data flow.
7. Review the design with coworkers and identify needed changes and enhancements.
8. Modify design document.
9. Re-review.
10. Build data structure/database.
11. Develop solution.
12. Gather, import, and enter test data.
13. Review solution, noting areas needing additional work.
14. Modify solution as needed to address issues identified during testing.
15. Go live with the solution.

The process above is straight forward, as long as you have a sound idea of your problem set and the goal solution.

Write a Requirements Specification

Taking time to write a requirements specification, whether formal or informal, puts your thoughts to paper on the problem you are addressing and your concept of the solution to the problem. In a perfect world, the requirements specification is complete and includes every detail about what is needed. However, that is a very tall order. Take your best shot and document what you can, and don't worry if you're not an English major. The point is to document and communicate the requirements; not to publish a novel.

1. How many users will use the solution?
2. Does the solution need to interact with any other solutions or software packages?
   • Write data to?
   • Read data from?
   • Export data?
   • Import data?
3. What is the desired platform? Desktop, Intranet or Internet?
4. Is remote access needed?
5. Are all users in one office or are they geographically dispersed?
6. What is the estimated size of the data that will be managed with this solution?
7. Does it replace a paper-based process?
   • What is the paper-based process that is being replaced?
   • Do you have existing forms and reports that should be duplicated or from which design ideas can be drawn?

Design Specification

This can often be combined with the Requirements Specification by including diagrams and a description of what the diagram tells the reader. A design specification does not need to be a large undertaking, but can include flow diagrams of data and process, or the role of team members or outside parties. A design specification should, at a minimum, describe or illustrate the main components of the solution, the flow of data, and who is involved in adding or accessing the data.

Interim Reviews

During the development process, your key person needs to review the solution with the developer. He/she should look for misunderstood and missing requirements, as well as to take time to discuss these topics with the developer.

Testing

Someone in your organization must be involved in testing the design. Too many custom solutions are dropped into an operational environment with no testing. When things fall apart, finger pointing ensues. Testing validates the design and should give you a feeling of pending success. Further, testing should be redundant.

As-Built Documentation

The as-built documentation should be an updated copy of the design specification, reflecting how the solution has actually been implemented. A simplified version of the As-Built can be instrumental in educating team members on the solution they are being provided. It should explain or illustrate how the solution works.

Integration with Existing Software Products

Integrating two solutions raises the stakes and increases complications. Careful planning can reduce the cost and increase your level of success. Two systems that share data should abide by the same set of rules. Before integrating two packages, you should take some time to ensure that your data in each system is concise. Categories should be precisely what your organization intends, not what accidentally was 'fat-fingered' into the system. Clean up your data first and avoid mismatching data elements.

Multi-User Environment

Your Requirements Specification and Design Specification should outline your best guess at how many people will be using your solution, and generally speaking, in what types of roles. In general, most if not all information system solutions should be designed for multiple users. The number of users may not affect the design of the user interface, but it will certainly affect the plans for the load on the hosting server.

Portability

A well-designed solution can be moved when needed, given that all associated pieces of the solution and underlying data are moved in accordance with prescribed procedures. We will be glad to assist you through any move.

Backup and Security of Data

Building a great solution is just that. It's great! But even after the solution has been designed, built and implemented, there's more to do. Plan for and set up a backup for the data involved in your new solution, you must protect your organization's new valuable data source. We recommend using an automated backup tool that can use a predetermined schedule for unmanned backups.

The Cost Associated with Custom Built Solutions

In the pursuit of acquiring and implementing a custom built solution, there are factors that can impact the cost. Likewise, there are actions you can take to minimize those factors. Some of these factors are provided here to aid your understanding of mitigating potential impacts.

Issues That Impact Cost

1. A poor understanding of your problem.
2. Poor communication of the planned solution.
3. Delays in development.
4. Continuous changes to requirements (requirements creep), large and small.

Methods of Controlling Costs

1. Assess the problem your organization is facing (trying to solve) and write a clear problem statement. This does not need to be as long or detailed as the Webster dictionary, but it should be written so that someone not familiar with the problem can get a clear understanding of the problem. Do take the time to discuss the problem with others who are familiar with it. And ask for their view of a solution.
2. Take a few minutes to document the planned solution as best you can. This might include writing a few diagrams and a chart or two. A good effort at this step may save you headaches further into the process.
3. Perform a status check with the developer, at a minimum, every two weeks. Too much time may allow the project to stagnate. When project development isn't a continuous active process, the developer or development team must come back up to speed on the project and may loose time in doing so. Also, your regular review of where the development is at, and where it is going, allows you to make adjustments to the requirements and design before the needed change affects more completed portions of the project.
4. Requirements creep is often the leading cause of cost impacts. Changes requested after implementation has begun will cost time and money. A good effort should be made to complete and communicate your requirements before final design. Changes, when necessary, should NOT be avoided. The reason for interim reviews is to allow for tweaking the solution, with intent to refine your requirements and the final product. The more effort invested in communicating all requirements up front will be well worth the result: a better solution, and better controlled cost and schedule. Fuzzy areas of logic and reasoning can be a source of cost impact.

The Cost of Not Solving the Problem

Don't allow this information to scare you away from developing the solution you need. Unaddressed problems may appear to be the sort of thing that you can put off. "It's only impacting us a little bit" you might say, but what is the cost adding up to over the long haul? Are you missing opportunities for work or revenue that you never collect? Do you have people within your organization that expend hours per day or per week, that add up to a small fortune? If so, you may want to give serious consideration to finding a solution to the problem to increase the likelihood of your business being more successful and more profitable.

A Good Solution Doesn't Change Your Process

OK. That's a bold statement. The point is, if you have assessed the problem, and assessed the processes within the related business area, and you have determined that the particular process is sound, then you should seek a solution that does not un-necessarily change your process. Solution developers often charge in and propose a solution that requires serious changes to your process. Be sure the change is warranted before it happens.

Identify a 'Cheerleader' to Carry the Solution Forward

Human nature is to resist change, even if the change is for the better of the individual or the organization. Change of any type is almost always assumed to mean "more work for me", although a good solution has just the opposite affect over time. Increase the likelihood of your success and reduce the time it takes to make the new solution useful by having an in-house 'cheerleader' be your lead user of the solution. Your 'cheerleader' can demonstrate the benefits of the new solution to others and win over the rest of the team. There is no better tool available to make a solution a success than a lead team member who understands the solution and who is passionate about its impact.

For More Information

Please contact us to learn more about custom built solutions and how to make your efforts more successful. Click here to read about some of the solutions we have deployed.