Home
 > Research and Reports > TEC Blog > Requirements Definition For Package Implementations

Requirements Definition For Package Implementations

Written By: Joe Strub
Published On: January 28 2003

Premise

Defining the requirements of software is where a company sets the expectations of the software and specifies how it is to function in specific circumstances. This should not be the initial attempt at this process. As part of the package selection process, the broad specifications of the software should have already been defined and used to evaluate and ensure that the selected software is the best fit for your company. In the requirements definition task, you should be expanding and extending the Request For Proposal (RFP) with more details, examples, and specificity. If you appear to be starting from scratch and are handed a blank sheet of paper, be afraid, be very afraid.

As typified with today's ERP software, applications have soft controls, switches, and settings to determine how they function. Additionally, there are fields with variable meanings and purposes. Determining the settings and field values are the deliverables from the requirements definition task. This task consists of the As Is, To Be, and Gap Analysis phases. As depicted below, a progression through these phases should provide users with a clear vision on the operation of the software.

As we will see later, the typical sequence of these phases is As Is, To Be, and, then, the Gap Analysis. The software that you purchased acts a bridge to get you all or part of the way to the To Be environment. The Gap Analysis will determine how much weight this bridge can accommodate. We will discuss each phase in more detail, indicating the approach, deliverables, and potential speed bumps.

As Is Phase

As its name suggests, in the As Is phase we are documenting the current practices, methodologies, and procedures of the business. Users frequently want to bypass this phase as being unnecessary. This would be a mistake. Complaints like "What value is there in knowing how things were done yesterday?" or "Let's gets started on re-designing the future" are all too common. Instead, once getting pass these objections, users can be heard to say "I was just doing it that way because I thought you needed it that way," "I could have saved you time by doing that way", or, my personal favorite, "You mean that I spend hours preparing that report and you throw it away."

When starting this phase, if existing documentation or flowcharts are available, this information can be put to good use. However, the currency of this information must be validated. Regardless, and assuming on the availability of the process experts, multiple and iterative "white board" sessions are a valuable technique to flush out the process flows. For example, in the manufacturing process, the experts would describe:

  • How are raw materials allocated

  • How are resources selected and scheduled

  • How is the routing determined

  • How are yields calculated and variances handled

  • How is production reported

  • How is/are ..

As the experts go through the flows, questions are dealt with and issues are addressed. The natural tendency is to drift into a discussion on how things should be done. This should be avoided or discouraged else you will miss the target of the exercise, namely a validated understanding of how things are done today.

Typically, you will have engaged consultants from the package vendor to assist in implementation and training. The As Is phase is an excellent opportunity to bring the consultants up to speed on your company's business and practices. While the consultant's role will be more of a passive nature in this phase, their contributions and activities will increase significantly in the next two phases.

Finally, it is beneficial for the entire project team to see the final version of all of the process flows. This could mark the start of breaking down of the barriers that may exist between departments and eliminate the tunnel vision that may have infected the organization. If not eliminated, these obstructions will become more contentious in an integrated ERP or CRM environments.

To Be Phase

In the To Be phase, you get a chance to play king or queen for the day. As if you owned the company, you can legitimately ask, "How should things be done?" This may be a little farfetched but you clearly should think outside the box. Using the As Is documentation to identify the bottlenecks and obstacles to making or increasing profits, you now decide how to eliminate or, at least, minimize them.

The biggest problem encountered in this phase is that project teams and users go hog wild. Let's face it; you are not painting a picture starting with a blank canvas. You already have a charcoal outline in terms of the solution provided by the package software that has been selected. You still need to stay within the lines and, as with colors, ensure that the requirements blend and integrate with each other. In this phase, you expect the consultant to play an active role in channeling ideas and improvements that can be best satisfied by the selected package. While not to suggest that creativity be stifled, the reality of the situation is that decisions have been made and contracts have been signed. Unless you are prepared to, or even can, undo the selection process, you need to keep a tight reign on the To Be phase.

Another potential problem is a company that states that it will rely solely on the best practices of the software. This is rarely realistic or practical. Taking this misguided approach in the To Be phase will result in problems surfacing when the software is being piloted. Take the time and perform the due diligence now to anticipate the future needs of your company.

Gap Analysis Phase

So far you know: (1) what you are doing today via the As Is and (2) what you want to do going forward via the To Be. Now, in the Gap Analysis, you will determine how far down the road the selected software will take you to your To Be state and, more importantly, the sections of roadway missing or under serious construction. Having identified these gaps, there are three alternatives to filling them:

  • Change current practices to eliminate the gap

  • Use the best practices of the software and associated procedures

  • Enhance the package so that it conforms to your business practices

The first two alternatives are the least costly and troublesome and, to be candid, make the most of your investment in the software. The enhancement alternative can have long-term impact in terms of costs and support. As Olin Thompson stated in his article on software modifications, Should You Modify an Application Product, "Are modifications bad? The answer is yes." A good rule of thumb is that an enhancement today will cost an additional 20% each time the enhancement has to be retrofitted to a new release. Assuming that the initial cost of enhancement was $50,000 and at least one new release or service pack is issued each year, over the 5-year period the true cost of the enhancement is $100,000. Consequently, when determining the cost/benefit, ROI, or payback period, you need to consider the total cost of the enhancement.

A useful control technique regarding enhancements is to assign budgetary responsibility for enhancements to each user department. In so doing, departments are more adapt to control themselves as to the necessity of an enhancement

Summary

Perhaps an example will illustrate how the As Is, To Be, and Gap Analysis phases can work together. Assume that your company's current business practice entails utilizing a factor for its receivables. This becomes apparent when the flow is diagramed on the "white board" during the As Is. However, going forward and to reduce the costs of outside services, the company intends on establishing separate credit terms and limits and finance orders internally. This requirement was outlined by both Vice Presidents of Finance and Customer Service during your To Be discussions and interviews. In the Gap Analysis, you confirmed with the consultants that the desired credit terms processing is a standard feature of the package. However, factoring is not part of the standard functionality. The price tag for enhancing the package to accommodate factoring is estimated to be $125,000 or $250,000 over a 5-year period. Since the intent to phase out factoring altogether, the recommendation is to handle factoring offline and avoid the expense of the enhancement.

You might think that the above scenario is just a simple example to illustrate a point. Simple, yes, but taken from a real project. By involving all concerned parties in the process, the rationale for the decision was understood and a consensus was obtained.

The importance of correctly defining the requirements cannot be overstated. Following a logical and deliberate path will help ensure that you will avoid any detours, maneuver through obstacles, and achieve the stated objectives.

Finally, the sequence of phases discussed in this article will encourage the full participation of the project team, users, and executive management and increase the overall confidence in the software. If done correctly, you will be surprised by what you will learn and you will be able to balance all of those plates!

About the Author

Joseph J. Strub has extensive experience as a manager and senior consultant in planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the food & beverage, chemical, and CPG process industries. Additionally, Mr. Strub was a consultant and Information Systems Auditor with PricewaterhouseCoopers and an applications development and support manager for a Fortune 100 company.

He can be reached at JoeStrub@writecompanyplus.com.

 
comments powered by Disqus

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.