Software developers face a big challenge trying to create and deliver software that suits a customer’s need and streamlines their business process. There are many pitfalls to avoid during the software development cycle and the roadmap is often not clear. Many times, customers don’t understand the inefficiencies in their own business process, or if they do, they don’t understand how to apply a software solution to make it more efficient. In large part, that is the job of the software developer.
In typical scenarios, a software developer is approached by a customer who is currently engaged in an inefficient, expensive business process. For example, perhaps a requisition and approval process for resources is being managed using a series of disjointed spreadsheets and constant phone calls to ensure the continued flow of the process. Off-the-shelf software has been tried but does not meet the specific needs of the company in question. This is when a software developer is called in to develop a custom application that can be used to manage the process in a streamlined, cost-effective manner. Successful execution of this task can be broken down into ten specific steps.
Step One: Understand the Customer’s Business Process Flow
It is critical to understand the process flow for which the software is being developed. Meet with the customer and discuss his or her business. What processes are currently being used to manage the business? Ask questions and probe the customer for details. By the end of the meeting, or perhaps several meetings, the developer should understand the business process so well that she could explain it thoroughly to someone else, or perhaps even train an employee on it. Once the process is understood, the developer works with the customer on possible ways to streamline the process with a software solution.
Step Two: Gather Specific Requirements from the Customer
Requirements gathering is the foundation on which the rest of the software project will be built. Without good requirements, the typical result is software that does not meet the customer’s needs or does not fit their business process flow. Requirements make up the detailed blueprint for the software program to be developed. They are detailed lists and descriptions of specific actions that the software must perform. This often includes defining levels of security, or access to the software, data setup and storage requirements, specific functionality throughout the application, reporting capabilities and other details. All of this needs to be hashed out with the customer as completely as possible before one line of code is written. This is why it’s crucial to understand the problem the software is addressing and the business flow the software is being developed to support. Requirements should cover every step of that process.
Step Three: Document the Requirements
Once all the requirements have been gathered and sketched out on poster board, white boards and bar napkins, it’s time to write a proper requirements document. Organize the requirements in a way that follows the business process flow. Create a concise, clean document that embodies all the customer requirements. This not only provides the developer with a good blueprint for the program, but it also serves to hold the customer accountable later (as detailed in Step 7: Avoid Scope Creep).
Step Four: Review the Requirements with the Customer
Meet with the customer once more, or as many times as it takes, to review the requirements document. Go over every detail to be sure that everything is covered. This will ensure that the program will perfectly meet the customer’s needs and will fully support their business process flow. That was joke; it will never be perfect. This will simply help minimize the number of requirements misses that will come up later and impact the coding process. The more thoroughly the job of requirements gathering is done, the smoother the coding cycle will be, but there will always be things that are forgotten by the customer (or even the developer, shudder!), missed in the discussions, or misunderstood all around.
Step Five: Agree on an Estimated Completion Date
Discuss the project time-frame with the customer. Ideally, the deadline will be flexible enough to allow enough time for the proper development, testing and release of the application. Realistically, the customer usually has a deadline that in part dictates the schedule. If it is too aggressive, there are a couple of choices. First, more developers could be added to the project. This can ultimately speed up development time, but team development comes with its own challenges and deserves its own article. Secondly, the developer and the customer can start the process of trimming down the requirements in an effort to shorten the development time. Perhaps there are some requirements that can wait for a second release of the software, or some that can be combined or simply dropped as having been “nice to have.” In the end, agree on a date and stick to it. Not only will the customer be happy, but the developer can then move on to the next project. Nothing kills the spirit of developers faster than a forever-project that is never completed, always in need of more tweaking.
Step Six: Code the Application
With customer-approved requirements in hand, it is time to go forth and code the application. For most developers, this is the fun part. Often a copious amount of caffeine is involved. Coding is the time for the developer to flex his technical and creative muscles. The smart developer will take each project as an opportunity to stretch technical understanding and learn a new skill or two. Try something a bit different than the last time; continue to grow in skill and technique. During the coding phase, don’t be afraid to meet with the customer when necessary in order to get clarification on, or refine a requirement.
Step Seven: Avoid Scope Creep
“Scope creep” is a well-hated term known by any developer who has ever written software. It is the process by which the customer continues to add or change requirements well into the code phase, or even the testing phase. This is where the requirements document comes into play. Politely point out to the customer that, while a brilliant idea, it was not captured in the agreed-upon requirements and refer to the document if necessary. In most cases, the change or feature can be shelved until after the initial release and a second version is being considered. Sometimes, however, the requirement that was missed is so important that the customer plays the dreaded “well we just won’t be able to use this without it” card. At this point the developer can concede and incorporate the change into the software. Alternatively, she can print out all the source code, burn it on her gas grill and walk away.
Step Eight: Developer Tests the Application
It is highly recommended that the developer test his own work as development is going on, and once coding is completed. Run through every scenario possible in the software, use it like the customer will, abuse it like the customer will. The goal is to ferret out as many bugs as possible before releasing it to the customer for testing. The customer will still find plenty to complain about, but hopefully by way of performing off-the-wall actions, not finding obvious issues. It’s a good rule of thumb that every good software tester finds about one third of the bugs, so find some impartial good testers if possible. They can shake down the application before it gets to the customer.
Step Nine: Release it to the Customer for Testing
Meet with the customer and demo the finished product. Answer any questions and help the customer see how the software addresses the business needs. Many customers don’t have any idea how to test software, so explain the basics to them. Have them go through most if not all of the different screens and functions of the program. Tell the customer they should “try to break it.” Most people like that challenge and will test more thoroughly. If necessary, provide the customer with some testing scripts, steps to follow for testing, to prime the pump and get them started. Establish a good process for the customer to use to document bugs. Sending the developer an email each time a bug is found is not a good process. Rapidly listing a litany of issues over the phone to the developer is not a good process. Have the customer document the bugs in bug-tracking software, or even just a spreadsheet. Show them how to provide screen shots that show the application state and error. As bugs are fixed, the document can be updated to reflect the fix.
Step 10: Release to Production
Finally, the project is complete and it is time to release it to production. It will now be used to manage the customer’s business process. Try not to get roped into writing the training materials for the customer unless they are specifically paying for that service. Even then, hire a starving writer to do that. Good software development skills should not be wasted on writing training material. Often, the customer or part of his staff will write the training materials while testing is going on so it is ready before the release. Agree on a date of release and remind the customer that communication about the new software should be going out to the company weeks in advance so that people are prepared for the change. If possible, the customer should also hold any necessary training classes needed before the release or shortly after it. After release, check with the customer on how the software is working for them and determine if there are any problems that need to be fixed. Success is not guaranteed by following these ten steps, but chances of creating useful software are much better. Software projects, especially very large projects, are extremely difficult to smoothly execute. It takes experience to gain the necessary skills for a good project, but each time the process is completed, the developer should become more capable of avoiding common pitfalls and releasing a great product.