Web-enabling SAP: common issues and answers
By Michael Czerniak
The following is a question posed to Michael Czerniak, our Web-enabling expert. Visit the Ask the Expert forums on searchSAP for more great SAP advice.
What are the most common problems in your experience when dealing with Web-enabling SAP systems projects?
Ulrich Schubert, SerCon/IBM Global Services, Germany (firstname.lastname@example.org)
When implementing e-business applications in general, the project manager usually underestimates the risks of the project. Web-enabling implementations cannot be handled in the same way as ERP implementations.
Some reasons are:
* Implementation timeframe is shorter
* The view on existing data is for Web-enabling projects different than for internal employees (e.g. specific information like material availability or pricing should not be disclosed.)
* Integration efforts are usually be underestimated. It could be a "big deal" to integrate proprietary systems into the Web-landscape.
I've identified the following reasons why "Web-enabling SAP" projects usually have failed:
* Lack of executive support
It is very important to have clear executive sponsorship for the project. Otherwise the project could be delayed or killed by micromanagement of department managers who are not willing to give up their positions. A top-down strategy works best in order to minimize these risks. The executive sponsor will make sure that the project progress will not be delayed by internal politics.
* Ambiguous requirements
When writing a specification for an application the requirements are very often not specific enough. Expectations are very difficult to express in written language, especially if a global project team consists of employees with different native languages. Remember the "Mary had a little lamb" story? At least 10 or more interpretations of this statement are possible. And valid of course! Just to give you an idea:
For example, is Mary a little girl who just ate a portion of lamb for dinner? Is Mary the owner of a little lamb? Is Mary the name of the mother sheep that just gave birth to a little lamb?
* Changing requirements, "feature creep"
I've experienced very often during a project that a customer wants specific additional functionality. We all heard statements like this: "Can't you do this quickly? It does not consume too much time! And it's easy to do."
Implementation of specific functionality is not covering the whole story: design, implementation, testing in the whole application context and documentation are very important issues which very often are not mentioned when discussing "feature creep". A rule of thumb: if implementation of specific functionality takes about 10 staff days, add at least another 10 staff days for design, Q&A and documenting.
* Insufficient QA/change control
* Lack of focus, too many distractions, not addressing the business problem A Web-enabling project does not deal with technologies because they are fun or philosophy. The business problem should be the guiding light during the whole project.
* Prioritizing technology over solutions
* Paying insufficient attention to customers
An application will usually be built for users. If the user does not accept the application because of usability issues or improper process design, it will automatically be a failure.
* Uncommitted team
A big problem, no doubt about that.
* Mismanaged risk
Risk cannot be avoided. Risk should be managed. Therefore, it is crucial to have a methodology for implementing Web-enabling projects, helping you to discover hidden risks and make these risks manageable.
Surprises cannot be avoided and are funny. However, if a project manager is totally under pressure due to the other bullets on this list, she/he has not the power left to deal with surprises.
How can you minimize some of these risks?
By using a specific implementation strategy!
At HAHT Commerce we use Rapid Application Deployment Project Methodology (RPM). It is a proven methodology and a very effective too, as HAHT's customer success stories can tell you.
HAHT e-Solution Group has used RPM on all of its engagements for quite some time now with much success. This methodology is based on some key principles, which in many respects are quite unlike traditional sequential and monolithic project methodologies like the "waterfall" approach.
* Revolve all perspectives around end users:
All RPM processes are wrapped around the end user view. End users are involved in all phases, from day one. Discovery phases determine end user business problems and solutions the end user will use. Project documentation describes what the end user will be delivered. Project estimation and measurement is performed only on end user functionality. Development, testing, delivery and demo and reviews are done with end users on end user functions. Stress testing scenarios are built on end user use cases from the version plans. Project audits measure variances from end user expectations. In summary, all project functional elements are cast from the perspective of the ultimate end-user. We usually preface each of these functional requirements with: "The end-user will have the ability to..."
* Discovery is continuous:
Effective discovery is, of course, a fundamental success factor of any project. RPM acknowledges that discovery occurs not only at project start, such as during the requirements gathering or analysis phase, but throughout the project. RPM is prepared for, in fact embraces, changes along the way and is able to manage them. RPM does in fact require a formal discovery process at the beginning of the project. However, discovery continues throughout the project until the final delivery is made.
* The application is the specification:
Other techniques mandate the expenditure of much effort to obtain "the" requirements specification and "the" design specification. RPM is based on the notion that these written language specifications will always be too ambiguous to be a reasonable representation of the ultimate application desired by the end users. RPM recognizes that it is much more effective to simply use the application itself as a description of what the end user wants, instead of a body of words. All design, demonstrations, reviews and modifications are done with the application itself as the central component. A picture really is worth a thousand words.
* Delivery is incremental:
In order to treat the application as the specification, traditional monolithic deliveries would be completely unacceptable. It is vital that the end users be able to see, review and comment on the application often before it diverges too far from the desired result. RPM requires the applications to be delivered, in the true sense of the word, in increments. At each increment a pre-agreed portion of the final functionality is delivered. At each increment, a full application demo and review is done. The "specification" is thus refined along the way in an unambiguous way.
* Milestones are short:
To accommodate incremental deliveries, the major milestones must be close to each other. In many eSG projects, these milestones, during which the application is delivered, might be 2-3 weeks apart.
* Change is expected and welcome:
Since deliveries are very close together, and since only portions of functionality are delivered, it is a foregone conclusion that there will be change requests. In fact, change is encouraged and solicited at these early phases, because there is little effort that might need to be "undone", and because only when the end users see the working application will the true nature of the business problem and its proposed business solution be understood. Such new understanding inevitably leads to change.
* Risk is managed:
By moving all the change, surprises, and end user acceptance to the very beginning of the project, risk is managed, expectations continue to be set, and schedules and plans can be refined in small increments.
* Entire system is probed early:
Since each deliverable is a functioning application using the customer's live systems, all interfaces, implementations and functionality of these back-end systems are validated and probed very early. This allows early recovery from surprises.
* Goal is production Go Live:
The goal of every RPM project is getting the client fully live in production, not just delivering an application. This forces attention beyond the narrow view of just technology. Instead RPM projects are concerned with the broader issues of the entire implementation, including infrastructure, end user training, business process changes, stress testing, and so on. Thus, full solutions are provided, not just point technologies.
Thanks goes to Vic Tolomei at HAHT Commerce for his guidance and help during numerous RPM projects.
Did you like this tip? Send us an email to let us know.