Consumers today have more options and flexibility in the technology they use — from smartphones and computers to social networks and media — which changes the way they work and behave. They are exposed more than ever to the possibilities and limitations of computing. This has not only resulted in a blurring of the lines between personal and professional computing, but it has also increased the need for empowerment of the end users of enterprise applications, such as SAP systems. Although empowering the end user offers some great benefits for the business, it presents some challenges in terms of content, security, privacy, and compliance. Although each project has unique elements based on its context, there are 10 fundamental steps that are applicable to every kind of SAP implementation project. These steps are based on five parameters — system, solutions, data, process, and people (roles) – that hold the key for empowering the SAP project’s end users.

For every software project the end user is a crucial stakeholder, including SAP projects. Not only is the end user the subject-matter expert (SME), the end user is the very reason for the project’s existence. Empowering the end user in SAP projects is more than having a decentralized environment. Empowerment also includes ways, solutions, processes, data, organization structure, and systems that must complement each other for optimal productivity.

Numerous research studies about project management software show that involving the end users early, frequently, and through all phases of a project is vital to the ultimate success of any project.

1. Align the Project Work Breakdown Structure (WBS) with the Current Organization Structure

Managing projects successfully requires detailed planning and a significant component of this planning is creating an organized structure at the outset. Before you begin any project, you have to identify and define the project tasks and determine who is responsible for completing each task. Therefore, it is crucial that as a first step you ensure that the project WBS aligns with the current organizational structure (e.g., the organization breakdown structure [OBS]). The WBS is focused on the final, deliverable scope of the project — the result — while the OBS is a hierarchical breakdown of the responsibilities of each project team member or department.

To align the WBS and the OBS, the lowest WBS level (the control account) should be mapped to a position in the organization as shown in Figure 1.

Figure 1

Alignment of the project WBS and OBS

Aligning every control account in the WBS to every position in the OBS enables the project to get a clear understanding of the as-is process from the users of the application. For instance, in an SAP ERP Central Component (ECC) logistics project, the control account on one of the deliverables can be Purchase Order Approval, which is mapped to the Purchasing Manager. The person in this position (who is the end user after go-live) not only provides requirements but also signs off on the software requirements specifications (SRS) document, tests the application, and approves it for deployment. Not mapping the WBS control account element to the position in the current organization structure creates ambiguity and uncertainty as the requirements and downstream deliverables might not be relevant for the user.  

2. Have the Right End User as Your Product Champion

Once every WBS control account is mapped to the right position in the OBS, the appropriate person in that position should be identified as the product champion. The product champion is the owner of the product or application and manages the entire life cycle of the application from its conception, through design and development, to deployment and support. An ideal product champion acts in the best interests of the end users, the organization, and the product or application, thereby keeping the project on track as well as evaluating and balancing the competing needs of the project.

Unfortunately, however, in most projects real end users are not assigned to work on projects and those assigned as product champions ultimately end up as proxies. Even if the real end users are assigned to work on a project, more often than not the time they are allocated to work on the project is insufficient to the task. An ideal product champion not only has the vision and the knowledge of the business processes, but also has the networking skills to bring the right resources to the project as well as the time to do their job well. Generally, businesses have other vital, current issues to address that take priority over future initiatives. This means that the product champion’s time may be split between dealing with current, real concerns and working on future, probable issues. Clearly defining the product champion’s role and responsibilities at the beginning is important to the project’s ultimate success. It is also essential to have the right super user or product champion representing the end user population, in actuality as well as in spirit.

3. Get Complete Requirements from the Business Context

Receiving complete requirements from the business can be challenging. The need to understand the capabilities of the SAP system and to identify gaps makes a commercial off-the-shelf (COTS) application like SAP more challenging. Creating a clear statement of requirements is number three on the list of the top 10 critical factors that makes software projects successful, according the Standish Group’s 2009 “Chaos Report.” With this in mind, here are three challenges to getting complete, fully realized project requirements:

1. End users, including the product champion, have only a vague idea of what they need.
2. Requirements change during the course of the project as users see problems more clearly.
3. The users and the project team fail to communicate clearly because they come from different backgrounds and experience.  

Each project’s unique requirements make each SAP project context sensitive. Hence, the business analyst, who typically has the responsibility of building the software requirements specification (SRS), should work to transform this amorphous need into a concrete software requirements specification, taking into consideration the user’s business context and constraints. In most software projects, getting concrete requirements from the product champion (and their team) is the same thing as getting functional requirements. Functional requirements that capture the intended behavior of the system should be based on use cases that illustrate the interactions between end users and the system. Thus, use cases capture who (the actor or user) does what (the interaction) with the system, and for what purpose (the goal), without dealing with system intricacies. A complete set of use cases specifies all the different ways the system is used, and therefore defines all the behaviors required of the system. 

While functional requirements with use cases are absolutely essential, non-functional requirements also are key to empowering the end user. So, for example, the SRS document should be based on the functionality, usability, reliability, performance, and security (FURPS) model (Table 1) for encompassing both functional and non-functional requirements.

Table 1

Mapping of FURPS model to data and roles

4. Map the Requirements to Data and System Roles

Many of the challenges of SAP projects are related to data. Generally once the application is developed or configured, based on the SRS, the SAP system remains is relatively stable. However, the underlying state of the data is constantly changing. Business problems creep into the application via the data as the data structure and the dependency of the data with other data elements constantly change. Therefore, it is critical to get the right data into the system at the beginning to minimize the effort required later to maintain a clean data set. In addition, data consumed by users depends on the system role assigned to them, which is, in turn, based on their privileges and responsibilities. Deployments must ensure that the right users have the right access not only to the desired features but also to the data and roles to which they need access to perform their jobs. To minimize the data and role maintenance efforts, each of the five elements of the FURPS model should be associated with the data model and the system role as shown in Table 1.

Data and system roles are multipliers of the SAP solution efforts in the projects. For instance, in an SAP banking system application, the requirements could be that the override (functional requirement) to the manager (system role) for waiving the draft fee of over $1,000 value (security requirement; data model) should be triggered by the teller (system role). If not acted on within two minutes (performance requirement; data model), the workflow item should move to the next level of the approval process (functional requirement).

5. Map the Requirements Breakdown Structure (RBS) at the Control Level (along with WBS and OBS)

Once the SRS has been completed, create the RBS. End users typically see only the small picture and the SRS is generally written in an abstract language. The RBS brings more detail, structure, and context to the SRS. Building the RBS helps not only the end users but also the entire project team to understand exactly what features will be included in the product. The RBS typically is a four-level structure. The first level is the project, the second level is the model, the functions come at the third level, and finally features come at the fourth level. The feature at the lowest level in the RBS has to be mapped to the control account. Figure 2 displays the structure of these levels, including the following information:

• The first level in the RBS describes the goal or the scope of the project. For example, a project goal could be “implement SAP portal for the tellers.”
• The second level is the module, which is a self-contained independent component. For the portal project, a module could be the mortgage application.
• The next level of decomposition is the function. For the mortgage module, typical functions could include mortgage approval, mortgage disbursement, and mortgage closure.
• The final level of RBS is the feature, which is the distinguishable deliverable of the software application mapped to the control account. Within the mortgage approval function the features could be check down payment or check credit history.

Figure 2

Sample project RBS

6. Validate the Requirements with Different Perspectives at Different Timelines from Other End Users

To validate the requirements, involve the end users in all the phases of the software development life cycle (SDLC). At the same time, the project team also has to make the effort to get to know the as-is process and the current pain points, and to make site visits to understand the end user’s needs from different perspectives. This step not only consolidates the joint application design (JAD) session (see below) outcomes but also validates the requirements given by the proxy, super user, or product champion by a different set of end users. Also there could be a chance that the proxy, super user, or product champion might be biased — perhaps because of an over-association with a particular feature in the SRS, for example. Therefore, it is important for the project team to talk to multiple users at different points in the project to verify and validate the requirements.

7. Kick-Start the Development Process with a JAD Session

JAD is essentially a process for enhancing end-user participation, expediting development, and improving the quality of requirements in the project (McConnell, Steve, Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996). JAD is considered the most cost-effective method for improving overall project team performance and enhancing the relationship between the project team and end users. The concept of JAD is based on four key principles:

1. The users who do the job have the best understanding of that job.
2. The developers and configurators have the best understanding of how the SAP system works.
3. The business process and the SAP application work in the same basic way.
4. The best software comes out of a process in which all groups work as a team of equals with a single agreed-upon goal.

With these guidelines in mind, the JAD process should be carried out before starting the development or IMG customization, by gathering the product champion, the developer, the business analyst, and the project manager together in a structured workshop setting to assess and clarify all open items in the SRS.

8. Deliver the Software in Iterations and Increments

One of the inherent characteristics of software is that it is invisible. A 100-page SRS cannot supplement the working software, even if it is approved. Moreover, testing is the most crucial phase of the project. It is where the rubber meets the road, so to speak, and if significant defects are identified testing can derail the project schedule. To minimize this potential project catastrophe, deliver the software in increments with multiple iterations. Regularly demonstrate the applications to the end users and involve them in incremental testing as well. In this way, the project implementation team can develop better and more concrete requirements and get better feedback, thereby allowing the team to deliver software that meets the end users’ expectations. Also, ensure that data issues are being addressed in the solution as user empowerment is synonymous with data availability.

9. Facilitate Real End-User Testing

During the testing phase, especially in user acceptance testing (UAT), ensure that the testing is done by real end users and not by the proxy, super user, or product champion who gave approval to or signed off on the requirements. As the bridge between development activities and production status, UAT is the acid test for the project. UAT is the confirmation that the project will deliver to the user the functionality as specified in the SRS. Positive UAT results give end users confidence in how well the system will actually perform in production. In addition, UAT is typically the final checkpoint for quality, and forms the basis for the end users’ ultimate approval of the project.

10. Integrate Traditional Change Management with Technology Adoption

Unless users embrace the deployed SAP technology, the project ultimately will fail. All the efforts that went into delivering the project are futile if end users are not engaged during deployment and sustainment. Traditional change management techniques that are based on role-driven end-user training only help to get the system to go-live, they don’t help the end users to use the SAP system effectively. Effective user adoption happens in phases, which are determined by the number of features the users eventually use. For more information, see “Progressive User Adoption” by Mike Hughes at UXmatters. Hence the support and maintenance of the SAP application should not just be an afterthought because a majority of the SAP application’s life cycle is spent in maintenance. It is the responsibility of the project team to not only ensure that end users are trained in how to use the SAP system application, but they also should ensure that the sustainment team is regularly in touch with the end users and understand the motivations and needs of the end-user community.