How Agile techniques can improve enterprise software implementation

Selecting best-fit enterprise software is critical to maximizing ROI, but, of course, that is only part of the story. That software must still be properly implemented. For a real world perspective on this, I interviewed Dan Raven, a project management consultant based in the San Francisco Bay Area who specializes in ERP implementations. To date, Dan has about 15 SAP implementations under his belt, written a book on implementing SAP, and has done two Kenandy implementations (Kenandy is a cloud ERP built on the Salesforce platform).

Dan started the conversation by describing the benefits of learning from mistakes he and others have made, and gave an example from an SAP APO implementation some years ago. The implementation consultants captured the rather challenging business requirements, designed the system and presented it to the client. Unfortunately, their design would not work for that client. The consultants noted the shortcomings of their design, went through the cycle a second time and had the same result. It had taken over two months to reach this point, and there still was no workable design.

Then the customer proposed something new, namely that the consultants work on site with their business and IT teams, understand the needs and jointly develop a solution. This approach worked, and the experience led Dan to develop an Agile-like ERP implementation methodology.

Although Agile originated in the software development world, parts of Agile can be used in enterprise system implementations like ERP with great success. The core of the Agile implementation concept is to continuously design, test and implement smaller parts of the system, and then move on to the next part.

The alternative, of course, is the big bang implementation. But big bangs are dangerous! They can destroy things, for example, see the Foxmeyer Drugs case where an ERP implementation bankrupted the company. However, sometimes the existing situation may force a company to go live with a big bang. For example, the cost of building interfaces between the old and new systems may be so high that a big bang approach is the only practical way to go live.

Even when the go live is a big bang, the implementation project can still use the Agile approach. Here the business users are part of the implementation team and responsible for their areas. The key is keeping those business users involved and in constant communication with the implementation consultants, for example by having them relay requirements to consultants, perform and document testing, etc. To avoid siloes developing, use a project war room where everybody works together, and communication is encouraged.

At the macro level, an example of an Agile implementation is a phased ERP rollout at a multi-site company. Here you rollout the software at one site where you learn what to expect in terms of company-specific problems that may be encountered, business processes that might need tweaking and so on. This information is then used to improve rollouts at subsequent sites.

For me, one intriguing question was how requirements are typically gathered for these projects. Dan commented that before Agile implementations, companies would spend much effort and time documenting their actual business process flows. Consultants would spend weeks digesting that information, and then ask questions of the business team to validate their understanding. All of this would happen before any system configuration started. The problem with this approach is that it was too slow and that occasionally the documentation was not that accurate.

I asked Dan how often requirements from the software evaluation and selection were given to the implementation team, and he replied that this was only done in about half of the projects. This lack of reuse of evaluation requirements suggests that the concept of front loading requirements development to reduce implementation risks is an opportunity for further improvement.

With an Agile implementation, requirements gathering starts with scrum type meetings. Business users show the consultants the transactions being performed in the system today. The consultants then show the users how those transactions would be performed in the ERP system “out of the box” and the differences would be discussed. If “out of the box” would not work, the business users explain the problem to the consultants.

Documentation with Agile is much less formal, for example, consultants may use requirements management software like Jira to capture use cases or user stories. Next, the consultants and the developers configure the system to resolve each use case. Finally, those resolved cases are shown to the users for confirmation that they would work. This approach is relatively fast and often done in two-week sprints. The important point is that consultants are in front of users at least every two weeks with the latest updates. These updates would then be tested in the sandbox and any problems fixed immediately.

The key takeaways from the Agile implementation process for enterprise software like ERP are these:

• Holding scrum type meetings with users greatly accelerates the development of requirements compared to traditional methods of documenting requirements.
• By keeping configuration and development cycles short, e.g. in two-week sprints, problems get caught early by the users, and they don’t compound.

An Agile-like implementation methodology can greatly reduce the risk of an enterprise software implementation project not being on time and on budget. This is true even if circumstances demand a big bang go live event.

With thanks to Dan Raven for his input to this article.