Plan, Write, and Implement a Successful Software Project

Thankfully, most software projects succeed. Look around, virtually everything is running on software, and it all (pretty much) works. Maybe an out-of-the-box solution will work, or maybe you need to buy and modify that out-of-the-box software to suit your needs. Or maybe you will write your own. The worry, of course, is that software projects can fail.

How do successful projects differ from failures? How can you manage your software project for success? Here are some suggestions drawn from more than 20 years in the transportation software industry:

Plan before programming: Think things out before you start. What do you want the software to accomplish? What data is required? Where will it come from? What needs to happen first? Etc. Good software is the result of thousands of nitty-gritty decisions woven together. Analyze your workflow to anticipate as many of those decisions as possible. Some changes after you start are normal as opportunities or anomalies present themselves. Some will be small and easy to do. But some could strain your schedule and budget. Knowing exactly how you want the software to work before programming starts will help reduce the need for changes along the way. A great way to find out what you need is to design the reports you want first, then work your way back to make sure what you need is in the flow of the system.

Consider software that you already like: What are the best elements of that software? Is it an intuitive feel? A short learning curve? Reporting capability? Ease of integration? Scalability? Try to identify specific capabilities or traits that apply to your development project.

Intelligently structure the project: Have one person in charge. If a committee is required to make certain that various departments or functions are properly represented, select a single point person for programmers. That person should be able to make many decisions immediately—though obviously not all. Establish a realistic schedule before you start. Take into account vacations and holidays, especially in the summer and December.

Select the right vendor: Unless your project is entirely in-house, you'll be dealing with an outside vendor. Carefully check that vendor's references. Keep in mind that every vendor has at least one client who will tell you great things about him/her. You need more than that. Checking references is of paramount importance. Beyond that, be certain you have a match with whoever will be the point person on the vendor side. If it's a big project, you will be spending a lot of time with that person. Chemistry is important. Talk over the project from different points of view. Be as certain as you can that you're both talking about the same things, that you share an approach to the project, and that you're on the same wavelength.

Start with Version 1.0: Define your project's scope conservatively: There is a temptation to reach for the stars, to deal with more than the initial challenge. It's good to plan ahead, but the more you take on in a single project, the more complication you add, and the greater the risk of going over budget, missing deadlines, or even failure.

Build in flexibility: Missions change and so may your company's business processes. While you don't want to write a piece of software that attempts to do everything, what you do write should clearly reflect the basic business process it's being created for. If at all possible, it should allow for revisions to meet future needs. You can't anticipate all that the future might bring, but you can be aware of some possibilities, perhaps by following the media in your industry.

Plan your rollout: If at all possible, roll out your project one piece at a time. Enable people to learn the software in steps so they recognize benefits early in the process. That kind of acceptance makes adding features, options, and general complexity easier. Similarly, roll out to as small a group of people as possible to limit the impact of any day-one problems. You can more smoothly work out bugs if the entire business hasn't come to a halt.

Programmers should talk with users: Programmers who talk to end users will have a better understanding of what is expected of the software, what the outcomes should be, and what pitfalls in the process to avoid. Solicit suggestions from early users. Sometimes, simple tweaks or changes from early users can have an outsized impact.

Define success: The software you end up with may or may not please everyone. Perhaps management will be thrilled, but the staff will grumble. Maybe the customer experience will make Sales happy but Accounting will not like the reporting capabilities. Maybe it will boost your bottom line, maybe it won't. Whether or not your software project is a success will depend at least to a degree on your own definition of what that is.