Contracting for custom software development can be daunting. For many of us, it’s like wading into deep water in terms of technical specs, jargon, and the myriad details and decisions that determine whether your deliverable provides the enterprise solution you and your colleagues envisioned at the start of the process.
But if you have selected a high-quality development shop, getting what you want is a matter of doing your homework up front and understanding the level of detailed communication it takes to build custom software. In short, the number-one cause of project failure—i.e. not on time, not on budget, and/or not functioning as desired—is the customer changing requirements after the project begins.
Avoiding that slippery slope of in-project add-ons and changes requires upfront work, namely in the form of a carefully conceived Business Requirements Document (or BRD, for short). A BRD is your detailed written description of what exactly you want your software to do and what you want it to look like.
What a lot of people don’t understand is that when you change the requirements once coding has begun, you have in fact created a new project— everything has to be evaluated all over again. Because of the complexity of sequencing in coding projects, even wanting to slip in “just one small change” mid-stream can cost your
organization much more money and time than creating a new mini-project after the original development has been completed. Better yet, avoid all those pitfalls entirely by creating your perfect BRD before the coding ever begins.
To that end, a BRD should include descriptions of desired functions, features, workflows, data collection, and reporting. Pictures and diagrams go a long way toward clear communication. Any interfaces to external systems need to be outlined. Moreover, every function and feature has an input, a process, and an output that need to be described. The more you can think like a programmer, the greater the success of your project. In custom development, structure and logic win the day.
For many organizations, it is best to hire a good business analyst to help you with your first BRD. Prior to finalizing the BRD, you will need to talk to everyone who has a stake and everyone who has a requirement in a new application. You need them all to buy in and agree what needs to be done and how it needs to be done. A business analyst is trained in parsing out the information needed for a BRD and will help you structure the BRD so that you get what you envision.
After your organization delivers its perfected BRD to the development shop, the next step is for the development team to create functional specifications in the form of a functional requirements document. This is where the developers tell you what they are going to do and how it is going to work. And, no! Vague agreements based on hallway conversations do NOT work.
After the planning phases have been completed, the coding and subsequent testing may begin. For the start to finish process, the AML Partners development shop uses what is called a modified waterfall approach with a development protocol called RAD (Rapid Application Development). The steps in our modified waterfall, which can be represented graphically, include the following steps:
1. BRD (Completed by the client)
2. Functional Requirements Specification (Completed by the development shop)
3. Coding/Development
4. Unit testing (testing each function in the project independently)*
5. Quality assurance (an end-to-end test of the entire application)
6. Deployment to user’s test environment
7. User acceptance testing
8. Production deployment
*Steps 4-7 may be repeated depending on what is discovered in the testing.
