Without doubt, probably the most powerful word in any project environment. You cannot be overly prepared. If you have the time, resources and budget then you will be in a position to be able to undertake this task adequately. If you don't have the required time, resources and budget then you are likely to be under-prepared at Go Live and no one wants to be in that position.
Remember that a risk has been raised because of its likelihood of occurring and its significance on the outcome of the project. Concentrate on the ones that are likely to occur and which will have a major impact on the success of the project. Make sure you have a plan to minimise the likelihood of these risks becoming issues on the project. Once a risk becomes an issue you have to deal with it. So make sure that you minimise the chance of it becoming an issue through careful planning and management activities.
Capture both the likelihood of the risk becoming an issue and its impact on the project. You can now start looking at these individually.
Having said that, only include risks that are possible and have a chance of occurring. Don't include external risks which are inconsequential in terms of the project's outcome. Once you start including these sorts of risks you detract from the real risks that are likely to affect the project.
Remember that you will never really fail by having too much detail. The converse is true in that many projects have had too little detail and failed. Having more detail is far better. Project team members can see what is required and know exactly what has to be done
One of the most important lessons that have been learned from previous projects, is that where projects have failed, one of the key issues has been the lack of communication. Granted, there will be other issues as well, but it is highly probable that these would not have surfaced soon enough, due to the poor communication channels or lack thereof.
The project needs total endorsement from your organisation to ensure that it takes precedence over other business as usual activities. With strong project sponsorship your project has a much greater chance of success. If you have a project sponsor who is high up within the organisation and who is quite influential, then you have a better chance of success. They can influence activities in the organisation to either suit or minimise the disruption to the project
The building of prototypes is a vital step in any project environment. This is especially important whenever a bespoke solution is being built. The prototype allows the users to see, at an early stage, what the solution could look like. There is nothing worse than seeing the look on a user's face at the time of testing and knowing that the solution which has been built is not going to be well liked or easily used by the users. This brings on change management issues which could have been avoided. Remember that the consultants will design the best solution based on a technical view. Many consultants will not view the solution from a users perspective.
See the relevant worksheet in the Excel sample file
This role is crucial for the project. It is important that the project sponsor is not changed on a frequent basis. Having just one project sponsor is ideal. We have been involved in projects where the project sponsor was changed 3 times. This is far from ideal as you lose the continuity of the project sponsorship.
Don't let people tell you that this is about the training of users on SAP. Training is part of the change programme, but for all intents and purposes, Change Management is exactly what it says. It is about managing the change which users go through in the transition from their current system to SAP. This is probably the most under rated item on a project list and is often either left till last in terms of the order of priorities or left out entirely.
Training cannot be under estimated for any SAP users in the organisation. Remember that there will be different training requirements for different types of users. You may require project training for the super users involved in the project. You will require training for the testers involved in User Acceptance Training (UAT). In addition you may require to carry out train-the-trainer training and/or end user training.
Don't underestimate the number of resources you require for a project. Remember to allow some contingency in your planning of resources. There will be tasks and activities which you may have omitted from the project plan or forgotten entirely. If these activities are required and you don't have any spare resources, they will have to be done by existing project team members. This will place additional pressure on your existing resources, which is not a great scenario. They will already be under pressure. Remember that project team resources will in all probability not have gone through a project lifecycle before. In addition, as happens on most of our projects, they will be required to complete their "normal" daily activities. This is often done late in the afternoon or evening and will put them under pressure, even without having to undertake any additional, unplanned project activities
Unit testing - this is testing done on a single piece (unit) of configuration and is done by the consultant
System testing - this is the testing done by the consultant in the test environment, before any user acceptance testing (UAT) is done.
Integration testing - this is the testing which covers, as the name suggests, the integration points. The integration points are those which exist between different sub-modules and modules of SAP. Examples would be as follows: transferring an applicant from recruitment to personnel administration, posting results from payroll to FI, transferring qualifications from Training and Events to Personnel Administration.
User Acceptance Testing (UAT) - this as the name suggests should be carried out by the users. This should never be carried out by the consultants who did the configuration. This is a key part of the testing and is useful for a number of reasons. It gives the end users a chance to see and use the system. It also gives relatively new users a chance to see whether they can find any faults with the system build - whether this is due to configuration, data or lack of knowledge in how to use the new system.
Regression Testing - this testing takes place whenever the new configuration is to be introduced to existing functionality. This testing determines the impact of the new functionality and modules on the existing system build. This testing is important for SAP, which is a tightly integrated system.
Stress testing - this is usually done at the end of the testing cycle. Remember that this is not to test the stress levels of the project team members. It is to test whether the new hardware can cope with the transaction volumes expected as a result of the new functionality being introduced.