The SAP implementation process is made up out of four main phases, i.e. the project preparation where a vision of the future-state of the SAP solution is being created, a sizing and blueprinting phase where the solution stack is created and training is being performed, a functional development phase and finally a final preparation phase, when the last tests are being performed before the actual go live. For each phase, the vital activities are addressed and the deliverables/products are explained.
In Figure 2 an example from practice is illustrated. The example is taken from the requirements capturing workflow in UML-based Web Engineering. The main activity, user & domain modeling, consists of three activities that need to be carried out in a predefined order.
In some specific cases an activity exists of sequential and unordered activities. The solution to this modeling issue is to divide the main activity in different parts. In Figure 4 an example is illustrated, which clarifies the necessity to be able to model unordered activities. The example is taken from the requirements analysis workflow of the Unified Process. The main activity, “describe candidate requirements”, is divided into two parts. The first part is a sequential activity. The second part consists of four activities that do not need any sequence in order to be carried out correctly.
In Figure 6, a fragment of a requirements capturing process is depicted. Two activities, defining the actors and defining the use cases, are carried out concurrently. The reason for carrying out these activities concurrently is that defining the actors and the use cases influences each other to a high extend.
In Figure 8 an example from practice is illustrated. A requirements analysis starts with studying the material. Based on this study, the decision is taken whether to do an extensive requirements elicitation session or not. The condition for not carrying out this requirements session is represented at the left of the branch, namely [requirements clear]. If this condition is not met, [else], the other arrow is followed.
In Table 1 a generic table is presented with the description of activities, sub-activities and their relations to the concepts. In section 5 examples are given of both process-data diagram and activity table.
|Activity 2||Sub-activity 4||Sub-activity 4 results in a STANDARD CONCEPT|
Notable is the use of open and closed concepts. Since project management is actually not within the scope of this research, the concept CONTROL MANAGEMENT has not been expanded. However, in a complex project is RISK MANAGEMENT of great importance. Therefore, the choice is made to expand the RISK MANAGEMENT concept.
In Table 2 the activities and sub-activities, and relation to the concepts are described.
|Describe Project||Describing the project is done in terms of participants, targets, products, scope and assumptions. This information is derived from the proposal, but with more emphasis on the project management issues. The activity end in a project DESCRIPTION.|
|Construct planning||Describe project phases||The PLANNING is divided into five PROJECT PHASES, which should be shortly described.|
|Construct planning||Describe activities||The project ACTIVITIES are described and grouped into PROJECT PHASES.|
|Construct planning||Describe deliverables||The DELIVERABLES that result from the project ACTIVITIES are described.|
|Construct planning||Set up schedule||For every DELIVERABLE a DATE is set and for each ACTIVITY a TIME SLOT is estimated.|
|Control project||Controlling the project results in a CONTROL MANAGEMENT artifact. This artifact is not further explained here, since it concerns regular project management issues, like communication management, progress management, change management and problem management that lie outside the scope of this research.|
|Control risk||Identify risks||Identifying risks can be done by using standard checklists or organizing risk workshops. The RISKS are included in the PROJECT PLAN.|
|Control risk||Evaluate risks||Every RISK is provided with an EVALUATION; a description and estimation about the complexity or uncertainty of a project is given.|
|Control risk||Analyze impact||Analyzing the impact of a risk handles about the IMPACT, a risk has on the success of a project. The evaluation and risk values are indicated by selecting a value: low, moderate or high.|
|Control risk||Prioritize risks||Prioritizing the risks is done by combining IMPACT and EVALUATION in a table. High priority is then given to RISKS with the highest scores.|
|Define actions for risk strategy||Risk strategy actions can be obtained from experience or from relevant literature. The project manager adapts the actions to the project in the ACTION LIST FOR RISK STRATEGY. RISKS with the highest priority are on top of the list and need to be handled first.|