INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Agile Project Methods for SAP ERP Projects?

October 29th, 2012 by
Agile or Waterfall on SAP ERP projects?

SAP Project Guidance

 

Looking at the “Agile Manifesto” and how Agile methods are applied generally involves small, discrete, “digestible” work and task components. 

Trying to juggle the number and complexity of dependencies on a full scale SAP ERP project involves management and coordination efforts which completely go against the idea of Agile methods.   

======

ERP projects tend to have too many moving parts for Agile–, there are too many dependencies and Agile provides too little control and coordination.  The level of coordination required for a large business package implementation flies in the face of “Agile” methods and techniques.  For example, you have to coordinate:

  • process configuration teams,
  • custom code development teams,
  • data conversion,
  • change management,
  • training,
  • testing,
  • governance,
  • infrastructure, etc. 

On complex projects like this all those “sprints” that are not carefully coordinated and planned (which goes against the “Agile Manifesto” listed below) become completely disjointed disasters.  There are too many work streams with dependencies that can not be going in “their own direction” regardless of the impact to other work streams.

Agile Manifesto Activities

The following chart, from the Agile Manifesto, illustrates serious trouble spots for ERP projects like SAP.

Valued

DE-Valued

Individuals and interactions

Processes and tools

Working software

Comprehensive documentation

Customer collaboration

Contract negotiation

Responding to change

Following a plan

Notice, 3 out of 4 of those items on the RIGHT side are often precursors to ERP implementation failures according to the academic literature.  Numerous case studies prove Agile “De-Valued” areas are the places ERP projects fail.  For example:

  • Failure to follow good processes and have solid tools.
  • Failing to have adequate documentation (training materials, help, etc.)
  • NOT following a well laid out plan (i.e. SAP’s PROVEN ASAP implementation methodology, including sample project plans, templates, etc.).

The only Agile Manifesto item that might have strong need to be followed in the ERP space is the focus on the customer over the system integrator contract.

All of those Competing Stakeholders and Constituents

Not only are the project related dependencies and work streams significant, there are numerous competing constituencies which must also be coordinated:

  • business stakeholders or organization,
  • IT,
  • external business customers,
  • external vendors,
  • system integrators (when you use consulting companies),
  • internal business senior management,
  • business department heads who don’t always agree with each other, etc.

While Agile methods might work well for small, discrete, component areas of an SAP or other ERP project the academic literature proves it is a disaster for ERP implementations. 

Agile is not a waste of time, it must just be understood and used in the PROPER CONTEXT of an overall SAP project.  Even the ASAP Methodology includes an “Agile” overlay.  This is an overlay of the existing ASAP Methodology–, it does not replace more traditional waterfall methods and does NOT adopt the “de-vauled” Agile Manifesto areas.

Does Agile Have a Place in ERP Projects?

It might. 

Agile is not suitable for projects with multiple, overlapping / parallel activities with dependencies between them.  The parallel and overlapping dependencies create a requirement that is more suitable to traditional project management methods with:

  • full project plans,
  • discretely defined tasks and responsibilities (to avoid “border wars” at transition points),
  • clearly defined deliverables,
  • management of parallel work-streams and parallel critical paths, etc.

Applying Agile principles to an overall SAP project creates a high likelihood of blown timelines, blown budgets, and collapsed scope — delivery  suffers while  stress balloons.

Agile in SAP ERP Project Examples

I know about the struggles, stresses and messes of Agile SAP projects.  I’ve been on three of these types of projects and none of them went well.

On one SAP project they tried to manage it with “Agile” and it was a complete mess –, the coordination and responsibility struggles forced  a change to the more traditional waterfall approach.  Using Agile methods the project had an unsustainable burn rate for the budget,  dates were ALWAYS slipping, inter-team coordination and planning were a complete disaster, and before the mid-course correction this project was not  going to go live. 

Worse still because of the “Agile” methods of only planning small, discrete work components just before they are due, each dependent group tried to minimize their own work and risk by dumping many of their traditional responsibilities and tasks onto any other group.  With Agile they were allowed to “self define” much of their own effort and naturally tried to minimize their effort while maximizing their success (at the expense of other project participants and work streams).

I do NOT place this responsibility on the clients who hire outside help, they obviously recognized a capability gap or a need they are willing to pay for.   I hold the outside project managers responsible for this and if you ever encounter one of these snake oil salesmen then you should FIRE THEM!

My Conclusion on SAP and Agile Deployments?

Wide application of Agile is a disaster  on any major SAP, ERP, or business software implementation project.  I can absolutely guarantee you that any Agile SAP project delivery “success” claim violated the Agile Manifesto to get there.   There are too many moving parts and too many constituents to use pure Agile on a full blown SAP project.

Related Posts:

Figuring Out IT’s Future in an Organization

October 23rd, 2012 by
Business Transformation

Business Transformation

 

“What is the value proposition for IT in your organization?”

IT can be just a service organization, providing a commodity service (and be outsourced to a cheaper provider), or they can identify where to add value to an organization, to the business, and to business leadership.

Hallmark does not sell greeting cards – you can buy the same card cheaper at the grocery store – Hallmark sells empathy, and customer intimacy. 

Exemplary restaurants do not sell food, they sell service. You can buy food anyplace.

Apple is NOT a computer or technology company, but sells instead, a compelling user experience. 

It may not be intuitive, what one’s value proposition actually is. In each case, the distinction between just someone in each of their industries, and being superlative, is understanding that regardless of the currency of trade (technology, in Apple’s case), the value proposition itself is what distinguishes your organization, your company, your success from everyone else. 

IT Organization Leadership

Leadership is not something that is done by the tired cliche of leading by example, but in creating a compelling vision, unique value, and the ability to enable others to succeed, that gets you to the top.  You rise not on the backs of others, but carried on their shoulders in triumph.  What can you do to make your business counterparts into heroes? It is not about making IT look good, but in making the business players be everything possible with your help. 

What Can You Do as an IT Leader to Move to the Next Level?

  • Get IT people invited to staff meetings in every organization.
  • Create a liaison/business partners group with technical people that can understand business.
  • Meet the business leaders daily – find out what they need;
    • share the unique insights as to what IT capabilities can provide;
    • work out if it makes financial sense, balancing the risk/reward tradeoffs. 

And Mr. CIO, take down that wall.  If you want to be part of business then join the business.  Change the dialog.  A CIO should be 80% outside of IT; the 80% inside is your VP/IT’s function.

You think disaster recovery is an IT function? You weren’t listening. 80% of business continuity and disaster recovery don’t even have an IT component. Be the leader, and bring the WHOLE plan into play, not just getting your data back. 

You think system reliability is measured in 3-4-5 nines? The business could give a rat’s behind. They care about 2 things; tolerance for planned downtime measured in window of opportunity and duration, and tolerance for unplanned downtime measured in duration and time to recovery. The latter provide a completely different engineered result, with far different costs that some arbitrary statistical number. 

Learn to speak in those (and other) business terms, and business will be your partner, not your customer.

Conclusion and Summary on Building a Business Centered IT Organization

IT today, typically covers half of what the functional role of the organization should be – the half that all IT organizations are comfortable with striving to deliver. 

The other half is business intimacy – moving from the back end of business requirements to the front end, and moving to a business partner, who works hand in hand on solving identified needs, up to business peer, collaboratively identifying new needs and how IT can expand business success, and maybe even to business leader, where business capabilities encompass how technology can best enable future business strategy. The transition is from reactive services organization, to improved business interactions, to trusted adviser, to proactive definition of future state business vision. 

If your organization is in a functional delivery role then your CIO is functionally equivalent to a VP of IT, with an inflated title.  If your organization is integrating with the business then your CIO is on the path to C Suite success and peer respect. Welcome to a small, but highly successful group.

Related Posts:

SAP Change Management Program Success

July 30th, 2012 by
SAP Change Management

SAP Change Management

Lots of literature, information, and resources focus on change management for successful enterprise application projects.  To help address SAP change management the SAP ASAP Methodology provides lots of resources, tools, and templates along with guidance for Change Management during your SAP project.  This is one of the key reasons for Why to Use the SAP ASAP Methodology?

Even though the ASAP methodology and various other resource provide some great sources the high level guiding framework always seems to be a little vague.  For example, there is a constant message that people resist change and that it is so hard.  That is not true.  As I have often said, if people resisted change no new product or service would ever be sold.  No new invention, gadget, method, or anything else would ever be developed.  There would be NO innovation in anything.

People do NOT simply resist change–, they resist change they do not understand and change they perceive is a threat.

Applying Sales and Marketing Principles to SAP Change Management

If sales and marketing departments for every type of organization in the world manage to sell new products or services maybe we should look to them for what works.  For both marketing and sales there are four key phases for customers considering a purchase:

  • Awareness (Marketing)
  • Consideration (Marketing, sales)
  • Evaluation (Sales, marketing)
  • Purchase (Sales)

These four general stages or phases of buyer behavior correlate well to a solid change management program–, messaging, engagement, credibility, and commitment.  To be successful you must be committed to Leading Change (and Change Management).

1.  Messaging – This is the beginning of the stakeholder analysis process.  Exploration, active listening, and facilitation are critical.  At this stage messaging is outbound.

Product or Service Sales Phase

Awareness

Customers understand and can communicate their desire or problem or need.  What are your constituents facing?  What are their struggles and what will help them do what they need to do better?  If the change will add more burden to them then why is the change necessary? 

Enterprise Change Phase

Discovery and blueprinting

A good SAP or enterprise application change program must start right from the beginning of the project.  First the identification of the key stakeholders at all levels of the organization must be made.  Afterward a clear effort must focus on the benefits to the affected users.  You must focus on the WHY of Achieving Business Value from SAP Investment.

A system-centric blueprint which does not connect to user needs will only breed mistrust and fear.

Analysis

Surveys are distributed and results tabulated.

2.  Engagement – Deeper determination of the issues, active communication, and targeted messaging.  Stakeholders at all levels must be encouraged to participate and be heard.  At this stage communications and messaging just start to go both ways (inbound and outbound).

Product or Service Sales Phase

Consideration

Marketing and communications are directed at addressing customer desires, problems, or needs.  Assurances are provided that the product or service will meet those issues.  The customer begins to solidify whether or not to explore a purchase decision.

Enterprise Change Phase

System functionality demonstrations and stakeholder feedback

Key stakeholders have the first part of their issues addressed.  There are 4 key types of change categories each user fits into here.  They are:

  • Opposed
  • Unsure, anxious, or fearful
  • Accepting or willing
  • Promoting

This phase of the change process is designed to aggressively uncover and then address those who are opposed or anxious about the upcoming changes.  These key stakeholders must be heard and their concerns answered.  It is also where the key message around SAP Service Delivery versus Value Delivery is promoted.

Analysis

Survey results are synthesized, reviewed, and then communicated to the broader enterprise.  Action plans to address the survey results are developed.  Any evaluation metrics are defined.

3.  Credibility  – benefits messages, demonstrations, insight, and information.  Change activities must promote openness and clearer understanding of the reasons for change.  More of an inbound and outbound dialog begins to occur.  Communications are actively going both ways.

Product or Service Sales Phase

Evaluation

Understanding of key features of a product or service and how they are different or better than competitors occurs.  Price considerations are also important.

Enterprise Change Phase

Aggressive information sharing and open dialog

One way you can Achieve Business Benefit is Through SAP Prototype Demonstrations.  Part of the communication and benefits program involves live system demonstrations (demo days), active engagement of super users, subject matter experts, and key change agents throughout the organization.  Messaging would also include external web resources, links, presentations, and other information to help “sell” the organization on the coming changes.

The goal of this phase is to overcome objections, fear, and anxiety.

Analysis

Action plans from the surveys are communicated to the organization and execution activities are carried out.   Evaluation metrics are refined, communicated, and adjusted to the organizational requirements.

4.  Commitment  – full user participation is critical at this stage.  If they are not involved in the process all of the previous effort falls apart here.

Product or Service Sales Phase

Purchase

For the purchase of a car this is the test drive and price negotiation.  For services or other items it is the understanding of key differentiators and how the service will help or enhance the customer’s issue, customer references, and possibly case studies.

Whether it is a test drive, understanding differentiators, price negotiations, or the benefits of a product or service these are all directly related to building a level of trust which in turn produces commitment.

Enterprise Change Phase

Acceptance, Adoption, and Promotion

More user demonstrations, training, super user network, subject matter experts, and pilot processes are all important here.  This is where everything starts to come together. 

This is also where any changes to originally expected benefits or reductions in scope must be carefully managed.  Another key area is the Organizational Change Management Inside the SAP IT Support Organization.  A key component at this phase involves Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1 (and Part 2).

The goal of this phase is to produce acceptance and even promotion of the changes.  However acceptance, adoption and promotion are not possible if the stakeholders have not established trust in the coming change. 

Analysis

Execution activities are carried out and nearing completion.  Reviewing, analyzing, and then distributing the results of the previously defined metrics results occur.  Lessons learned are captured and communicated.

Conclusion on SAP Change Management for Business Application Project Success

Every phase of your SAP or enterprise application project must be wrapped in the appropriate change management processes.  Just as with sales and marketing people do not resist change as much as they resist change which they perceive as a threat or do not understand.  So the key is to learn to sell the change and its benefits so that the perception of a threat is removed.  In doing so you will help to transform your project and company into a winner, both now and in the future.

Related Posts: