Get certified - Transform your world of work today

Close

An Agile Approach to Software Package Implementation

6 July 2015

Alok Kumar
Tata Consultancy Services


Agile has its roots in pure software development, delivering quality code faster. Since its beginning, Agile has grown and matured into a management ecosystem that is suitable for many applications, whether in software development or other fields.

One area in software that has not yet been addressed adequately is the acquisition of packaged software, in spite of the large proportion of companies today that acquire and use it. The "buy versus build" scenario has been around for many years, with more companies today opting for the "buy" solution for commodity-type systems, or any solution that does not deliver a competitive advantage.

Here we will outline an approach for executing package implementation programs using Agile methods.
 

The need for Agile in software package implementations

The process for evaluating competing packaged software products and determining the relative value of each package is an arduous one. IT organizations typically go through a process of determining customer needs, developing evaluation criteria, contacting vendors for demos and discussions, and following all this with trial periods.

By way of example, a typical enterprise resource planning (ERP) implementation takes, on average, 20 months to complete. Is it reasonable to suggest that in 20 months a business will look the same as it does now? Chances are that if you follow the traditional Waterfall approach and lock down your requirements and follow them to the letter, you will wind up with a solution that no longer fits your requirements.

In the case of a typical commercial off-the-shelf (COTS) implementation, there is a large up-front effort focused on identifying what modules are needed and the features within those modules. Much debate takes place among users of those modules regarding needed features simply because those who use them traditionally do different work (e.g., post cash, apply unallocated funds, sweep accounts, make GL entries, etc.). After much toil and debate, the features are usually entered into a complex spreadsheet that contains weighting and formulas for ranking vendor responses based on their being "out of the box," "configurable," or "customizable." The spreadsheet is then sent to each vendor, and the wait for their responses begins. After the responses are returned and the analysis is done, the demo period begins, during which the short-listed vendors "show" their product.

On average, this process can take 6 to 10 months to determine:
  • The extent to which the overall product will meet their needs.
  • The package offerings in the product with respect to needs identified in developing the evaluation criteria.
  • The extent to which the packages can be configured, customized, or both for the buyer's effective use.
  • Whether the purchase represents a fair value for the price, considering the constraints on the packages; their characteristics and functionality, ease of use, configurability, and customizability; and other criteria.
And, in most cases, the purchased product demands customization and configuration particular to the client's needs. These modifications can incur additional costs beyond the initial purchase for new development, enhancement, configuration, and the like. In our experience, these projects can take up to eight months to complete, resulting in an implemented package that may not fully meet the user's needs, because those needs have changed over the one-and-a-half- to two-year time frame of the purchase.
 

Our approach

We believe there's an easier and better way to quickly determine the optimal package purchase for a client's needs.

Agile practices in the acquisition and customization phases can get the client to the final decision point more quickly and with concrete information for easier decision making. We propose the following approach to using Agile principles during the acquisition phase:
  1. The customer identifies the needed package components (e.g., accounts payable, accounts receivable, general ledger, etc.).
  2. The customer develops a short list of appropriate vendors.
  3. The vendor installs a base package with out-of-the-box functionality.
  4. The appropriate accounting staff from each component area is identified as part of a Scrum team.
  5. User stories are developed by the team that mirror a typical day of their activities.
  6. The teams execute those stories with the base package in two-week sprints and note what they:
    • Need to do and could do with the package in its original form.
    • Need to do and could do but had to do it differently, reflecting additional acceptance criteria for existing functionality.
    • Need to do but could not do at all, resulting in user stores for new development.
  7. Results are passed to the vendors to determine whether solutions to adapted or new functionality can be addressed by configurations or custom development. Or, the vendors decide that they cannot or will not address the solution because it does not generate ROI for them.
  8. Agree to a two-week turnaround with the vendors to make requested changes.
  9. Retest changes with new or existing user stories.
  10. Run a parallel production as components are completed.
  11. The entire process is illustrated in the figure below.
Figure 1: Agile package implementation approach
 
Overall, this process seems rather simple, and it is. However, implementation is not easy, as it requires the typical shift in mindset that Agile requires. Creating a team of business people for the time needed requires a real commitment from the business camp. The team must be formed and led as an Agile team, which takes practice and effort. There are also real organizational constraints to consider in taking this approach, such as procurement practices and decision practices, that can lengthen the time for a team using this model for the first time.

However, this approach can be very effective. Experience with selecting this path to acquiring package software has delivered the following results:
  • Reduction in time from three to six months to one to three months overall for the purchase decision
  • Reduction in time from six to eight months to one to three months as a result of specific configurations by the vendor
  • Elimination of new development needed by the vendor, as process change and configuration change achieved the desired results
  • Reduction in customer spend as a result of having clear and demonstrable requirements for configuration changes and customization
  • Reduction in internal IT spend as a result of having a smaller set of new requirements that the vendor did not agree to build


Conclusion

A 2008 Panorama survey shows that only one out of five companies actually realizes more than 50 percent of expected benefits from their ERP implementation, and more than half of those have experienced significant operational disruptions after they go live.

The objective for applying Agile principles for a package implementation is the same objective for applying the principles in a pure development effort, which is to get the clients what they need more quickly, thus realizing a quicker ROI.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Luke Lam, CSM, 1/17/2017 12:51:14 PM
Great approach, except there seems to be a big jump from step 2 to 3. It might be instructive to learn more about the process of narrowing down to a vendor within Scrum cycle.
Monique Dolan, CSPO, 2/6/2017 11:17:26 AM
Hi - wondering if there is an article or if you have advice on how to write stories when you have already decided on the solution, you have a backlog of prioritized features (epics) and now need to decompose those epics into detailed stories. We want to stay as close to industry standards and OOB configuration as we can. How would you go about decomposing the epics?
Monique Dolan, CSPO, 2/6/2017 11:53:14 AM
Hi - wondering if there is an article or if you have advice on how to write stories when you have already decided on the solution, you have a backlog of prioritized features (epics) and now need to decompose those epics into detailed stories. We want to stay as close to industry standards and OOB configuration as we can. How would you go about decomposing the epics?

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe