A recent Computer Weekly article reported on Nov 3, 2011 that the U.S. Military is moving towards open standards and agile practices for it's ERP implementation after running into significant headwinds with current vendors. According to the article:
“It is nearly 10 years since US military divisions followed the millennial trend in public computing by pooling their purchasing and embarking on the ambitious, clean-slate replacement of hundreds of business systems with all-encompassing Enterprise Resource planning software.
Then they followed the ERP trend of going years over-schedule and billions of dollars over-budget.
Now the Department of Defense claims it is going agile, adopting open standards and embracing the semantic web. “
Elizabeth McGrath, deputy chief management officer at the Department of Defense, in her testimony to the U.S. House of Representatives stated:
"Through the next release of the [Business Enterprise Architecture], we will apply open standards and protocols to architecture development, leveraging Semantic web technologies, common business process modeling approaches, and agile development methodologies,"
ERP implementation failures are well known and documented in the information technology field. CIO magazine ran an article on 10 famous ERP system implementation failures in 2009. Computer World UK also ran a list of ERP disasters. All of this points to the difficulty around implementing ERP systems. But is the U.S. Military's use of agile practices a solution with precedent or just wishful thinking?
The Guerilla Project Management blog has some conversation around the topic of using agile practices in ERP implementations. According to the case study an SAP system was delivered to a client using agile practices and resulted in completion ahead of schedule.
According to the case study audio interview with Jason Fair, CEO of Genesis Consulting:
“...the amount of time we actually spend on customer value add activities was so small.”.
Jason estimated that under traditional waterfall process implementing ERP they spent no more than 5-10% on client value added activities. By boosting this to just 20% they would achieve significantly better value to their client.
Agile Scout did an interview with Mike Curl from Bluefin, which specializes in SAP implementations. He provided a list of recommended practices for using agility in an ERP implementation:
Chose a suitable first trial project with a trusted business customer, a real problem and challenging timescales.
-
Don’t just get a bunch of people together and start ‘doing stuff’. You need a real problem to solve and genuine business demand leading to an empowered Product Owner.
-
Give careful consideration to how many SCRUMS you’ll be running and the resource mix of each. As the number of SCRUM teams increase, so does the complexity of coordination, communication and the risk of conflicting development.
-
You can’t expect project teams to adapt to new methods overnight. Training, education and coaching are needed, as is some serious change management to sell the benefits and overcome the cynicism which traditionally accompanies the move to agile.
-
The agile world lends itself to having fewer, more skilled senior resources and this is especially true in the SAP world. Agile team members need to be able to think, design, develop, troubleshoot, test and communicate, often at the same time! Weaker resources soon stand out and become a bottleneck.
-
The pressure to deliver is constant and relentless. Keeping the team focused and motivated on longer engagements is a real challenge.
-
Things will go wrong. You need to be pragmatic and adapt. If a finger pointing culture starts to emerge, it needs to be quashed quickly or it will poison the environment and lead to risk avoiding behaviors.
-
Use some form of micro-blogging so that everyone knows what you’re doing at all times. This helps prevent misunderstandings, promotes good communication and also saves time.
-
The concept of regression testing doesn’t easily fit into agile methodologies where development often goes to the wire. When you’re building on critical SAP systems, it’s the only way to ensure that your ‘working software’ doesn’t lead to broken software somewhere else.
-
When multiple components and technologies are being used at the same time, there is a tendency for teams to seek out the ‘weakest link’ and try to pin responsibility for under delivery or slippage on them. This is a cultural problem which needs to be addressed - the whole project succeeds or fails, not individual parts of it.
-
The impact on support models and organizations must not be an after thought. Throwing something into production and then immediately focusing on the next iteration of delivery isn’t likely to win the project or the agile approach any popularity contests.
Still, debates exist on the web for using agile practices on ERP implementations. Here's some excerpts from a conversation on www.focus.com.
According to Kamanraj Shankar:
Agile methodology can be applied for large & complex ERP implementations. Typically ERP implementations used Waterfall or vendor/implementer specific methodologies, which had phases such as Requirement, Blue Print, Build, Test/Train an Deploy.
Agile methodology is focused on delivering specific measurable results with close collaboration with clients in short time intervals called sprints ( typically 2 to 4 weeks).
Clients would love to use Agile methodology to get visibility all along the project.
Now, to apply Agile for ERP requires initial planning for:
- Distributing the full project scope into deliverable that can be fit into sprints
- Including clients to manage backlogs from one sprint to another
- Effectively assigning resources on-demand for each sprint
Most important is to have a PM trained in Agile methodology with an ERP back ground.
I am willing to answer any specific challenges using Agile for ERP.
Bill Wood had a different view:
To the points raised here, "Agile" according to the definition in the "Agile Manifesto" is a complete and total disaster on large ERP projects.
As already mentioned, the large, interconnected, integrated dependencies of the software project make it nearly impossible without a carefully structured approach.
However, having said that, EVERYTHING is being called "Agile" these days. Including traditional project management methods that go 180 degrees away from the "Agile Manifesto" requirements.
So, "Agile" as it was originally conceived is a complete disaster on ERP projects. Traditional project management methods that some people call "Agile" work fine.
-------------------
As a testament to the Agile disaster on ERP projects, I work in the SAP ERP space. SAP in the early and mid 1990's had repeated failed projects and repeatedly expensive and troublesome projects. They immediately set about to create a specialized, step by step methodology to address this. This was the ASAP methodology and it is still in use today.
TENS of THOUSANDS of projects later, literally, this methodology has proven to be an absolute must.
But, the ASAP methodology violates the basic project principles of the "Agile Manifesto."
The success of the U.S. Military's new direction for ERP implementation is not known yet. But, the business world has grown tired of ERP project failure and new approaches are being explored as a result. So what do you think? Will agile save companies from ERP disasters?
