Last month, we detailed the first five cues to watch for and steps to take to ensure a smooth requirements capture process, resulting in a project that falls within the constraints of time and budget.  Keys 6 through 10 below complete our list.

6. Make resources available. Your consultant needs access to your current system and your employees. It is only by fully understanding your existing business processes that the consultant can develop a system that fits your unique needs.

7. Include the employees who actually use the system. You have management goals and know what you need from the system. But, regardless of how great a system is, people will not use a system they don't like. Include your managers and your internal business experts who work with the current system in meetings with the consultant.

8. Let your employees know their input is important. If your employees complain that the consultant is focused on technology instead of your business, listen and take action. Your employees will be working with the consultant in a team environment, and they will have a good view of the consultant's effectiveness. Let employees know that their participation and expertise are critical to the consultant, to you, and to the overall success of the project.

9. Remember why you hired the consultant. You and your staff know your business. The consultant knows her business. Be very specific and do not take anything for granted when explaining your needs and your business functions. If you don't understand any aspect of the project, ask questions to ensure your needs are met. Remember that you hired the consultant to help achieve a specific business objective. You're on the same team, so work together.

10. Take ownership of the project. Requirements definition is the first - and one of the most critical - stages of the overall project. Your ownership and support of the project during this task sets the tone for the project's ultimate success. The outcome of your project is ultimately your responsibility. 

 Source:  D. C. Gause and G. M. Weinberg (1989)

As shown in the Gause and Weinberg chart, in software development, the earlier you identify a required function, the more cost-effective it is. Adding key functions after the system is 50% complete often means modifying existing code to accommodate the unplanned function, and this can take time and therefore, be expensive.

By following the 5 steps outlined in our June newsletter and the additional 5 steps in this newsletter, you will minimize dreaded scope creep. If coding for a requirement identified early in the process costs $200, the same requirement identified later in the process can easily run into the thousands of dollars. Clear requirements are like accurate blueprints; they greatly improve the probability that the final product will be on time, within budget, and will meet your needs and expectations. 

What To Do When You Must Make a Change

With custom software, the scope and features of your software development project may evolve as the project evolves.  Even a thorough requirements capture process that identifies every specific function of your new software cannot document all aspects of the way you will work with the system. You may discover that you would like to make a change after the software development project has started. 

As a custom software developer, your consultant’s primary focus is on providing you with the features you need so your business functions quickly and efficiently.  The specification is the developer’s guide for ensuring the software meets your business needs. However, a good developer will also factor in your feedback throughout the development process as you review prototypes and begin using early versions of the system.  Frequently, when you begin to use your new system, you and your consultant discover that what appeared to be a great choice when you were developing the requirements document does not work the way you anticipated.

What else may cause a deviation from the specification?  As you see a system develop, you may think of additional advantageous features and functions.  Or as a system develops, the consultant may glean additional information from you that allows him to suggest changes that will benefit you and your business.  

Are you stuck with exactly what you agreed to in the initial specification and scope of work--and nothing else?

No.

When a feature outside the original scope of the project is requested, then a change order is required.  A change order is like a mini-specification, and it defines an addition or change and how it fits into the overall system.  The same guidelines that apply to the initial requirements capture apply to change orders.  

Here are some considerations to keep in mind when you need to make a change to your system specification.

• Immediately identify any changes as soon as you are aware of them to keep the cost of the changes as low as possible.  As shown in the Gause and Weinberg chart, the longer you wait to make a change, the more it will affect the cost.

• A change affects both the schedule and the cost of your software development project.  Ask your consultant for feedback on how the change will affect both these parameters.

Here is the procedure for creating and authorizing a change:

• You or your consultant completes the change order form, detailing the change requested.  Identify what the change is, what you want to accomplish with the change, and where you think the change fits (which specific screen or menu option).

• The consultant may ask questions to ensure total understanding of a change order if you complete it.  After you are comfortable with the consultant’s understanding of the change, the consultant provides you with a signed copy of the change order that identifies how the change will affect the schedule and cost of the project.

• You need to review the change order and decide whether it is worth the cost.  If you decide to proceed with the change, you sign the change order and return a signed copy to your consultant.

• If you decide not to implement the change immediately, you still can choose to delay the change to a later release of the software. 

Only you can decide if a change is valuable enough to warrant the cost and time it takes to implement the change.  The return on investment of the change can dictate whether to make the change now or later.

The purpose of custom software is to provide you with the features you need to automate your business functions without changing them to fit into the pre-determined mold that packaged software requires.  Custom software means flexibility--if you need to deviate from the original scope of the software development project, you can do so.  Although your consultant should provide you with feedback on the consequences of implementing the change now instead of later, ultimately you must weigh the increase in cost and the change in the schedule against the advantages of the change to decide which is most important for your business.