For those of you who aren’t aware, PRINCE2 is a framework which you can use to run projects with – or, structured project management method. PRINCE2 can be used for any sort of project, not just SAP projects.
Of course PRINCE2 describes the whole organisation of the project, and even if the project or project manager you are working with is not using a methodology, there are still some useful things you can take away from PRINCE2. Of course ideally the whole project would be run with PRINCE2, or another methodology, but this is not always practiced. You can’t just make a project ‘a PRINCE2 project’, just by cherry picking the parts you like and skipping other vital parts.
This blog, however, is about cherry picking some of the easier parts to implement in your own projects – so keep this in mind: it won’t make your whole project PRINCE2. Keep this in mind as you read – there are a lot of good things to take away from PRINCE2, even if your project doesn’t follow the methodology fully.
Below are some of the practices from PRINCE2 which are so easy to do, but so often skipped/forgotten about in projects.
Top 5 principles to apply to your SAP projects
1. Prepare
PRINCE2 has 7, of what they call, ‘processes’, which you can think of as flow diagrams to help progress your project smoothly. 5 of these 7 processes are used before you’ve even started the ‘work’, or ‘meat’ of the project – this time is used for preparation! This shows how important it is to successfully prepare and plan a project.
2. Learn from experience
It seems so obvious, but how much time have you actually spent looking for previous lessons learned before starting work on a project? Have you actually been round all the relevant sources within your organisation? Have you looked outside your organisation for similar things attempted by other organisations? Effective research here can pay dividends later on.
 3. Continued business justification
In order to justify a project, initially you will need a good business case. I had a lecturer, who would repeatedly ask, in the same way an irksome child does, ‘why’ in reply to things – there was a good reason behind this though, and he explained that you should always know why you are doing something, and have a good reason for it. Your SAP project should be the same. You should know why you are commencing the project – i.e. the business case for it. You should continually review how the project is going against the business case as you go along as well. Does the project still represent value for money?
Keep in mind, even if your project loses the original reason it was commissioned, it may still worth continuing in order to obtain other benefits.
4. Measuring benefits
This relates to the business case. In the business case you will have outlined the benefits you expect to achieve by completing the project. PRINCE2 splits the ‘effects’ of projects into three categories:  Outputs, outcomes, and benefits. Output and the products crated from the projects, outcomes are the results of the changes realised by these products – these may not always be tangible, and benefits are the measurable positive improvements obtained.
Most of the actual benefits are usually only realised after the project has finished, though some will be available during. For the benefits released after the project, you should have a plan for measuring these, and compare these to the benefits anticipated when the project started. This will not only give a gauge on whether the project was actually successful, but on whether any further work may need to be carried out to fully achieve what was expected. If you are not in a position to carry this out, you should make sure the plan for assessing this is passed on.
5. Risks
Every SAP project has risks. For your projects, are these properly identified and tracked? A good project manager will do this anyway, and be asking about new risks as the project continues. It is a good idea to have a formal ‘Risk log’ or ‘Risk register’. In this you should at least identify: a description for the risk, the probability of the risk occurring, status, the risk owner, and risk actionee. The last two items separate that the ‘owner’ of the risk (i.e. the person responsible if the risk occurs, or becomes a certainly) may not be the person who is assigned to perform actions to mitigate the risk.
Another interesting thing to add while we are talking about risk, is that risks are not always bad: PRINCE2 divides risks into threats and opportunities. Opportunities are uncertain events which would have a positive impact of the project. When was the last time you saw this tracked? Would it not be useful information?
This list is but a tiny fraction of the useful framework PRINCE2 provides. Hopefully you will find these things beneficial to keep in mind for the next SAP project you work on, if you are aren’t following the PRINCE2, or another, methodology.
For more information about the topics covered in our blog, contact Absoft today via: info@absoft.co.uk or T: +44 1224 707088 to speak with our SAP consultants.
