So, for those of you who have worked with me before, you will know that I hate paperwork. For me it is the boring bit of what I do. It’s way more fun to design solutions and solve customer problems but that’s just me! Our lovely project manager Gabbie loves the stuff but that’s why she is the queen of projects and I am the one that fights the good fight and argues over the need for every piece of documentation. So you know that every single piece of documentation that I recommend is essential. Not just “nice to have” but “absolutely shouldn’t even be considering implementing without it” essential. And I haven’t just been on a course or pulled it out of a project management book, this is years of continuous improvement of our software implementation process – and to be fair we are still constantly looking for ways to make it better.
So in this blog we are going to explain and analyse the key pieces of ERP documentation you need to have to make your project a success. Now I am definitely not saying this is everything you might have, but it is the absolute minimum you should be working with, whether you are a one man chemical distribution company or project manager in a massive corporation. Though to be fair if you are working in a massive corporation, you probably need to reduce the amount of paperwork required and not add to it! ERP
So lets look at the critical elements:
No, that is not me misspelling the name of an animal. PID stands for project initiation document. The Project Initiation Document provides a reference point throughout the project for all those involved – in our case both you as the Customer and our itas team. It defines all major aspects of a project and forms the basis for its management and the assessment of overall success – it is the “what, why, and who” part of the project. It is the document that goes before the decision maker for sign- off to commence a project
This should include:
- Overall objectives
- I.e. To reduce month end accounts processing time to 4 days
- Be SMART
- What is included in this project
- And WAY more importantly what isn’t
- Any assumptions
- Assumptions makes an a** out of you and me…now I don’t believe this entirely. But I do believe that NOT STATING your assumptions will make an a** out of your entire project team, so make sure you talk this through thoroughly
- Not tasks but the overall phase deadlines you are aiming to hit
- Project Team
- Be clear on who is in your project team and their role on both sides of the equation i.e. with both you software supplier and your internal team
ERP – The Project Plan
This is not a paragraph summary of what you are trying to achieve, nor in my opinion does it need to be the size of an encyclopedia and used to sit on when you are finished trying to make head nor tail of it. My ideal project plan contains the following:
- List of tasks with
- Summary of task
- Person responsible for completing the task
- Due Date
- Time allocated
- A gantt chart
Now I bet you weren’t expecting this one! The reality is that in most implementations you will be using external consultants and let’s be honest here, the good ones aren’t cheap! So you need to make the most out of every single moment you get with them. In my experience, training is one of the most under utilised areas of implementation so make sure you know:
- Exactly what areas they are going to cover
- Who needs to be in on that session
- Estimated amount of time you are going to drag people away for so they can be prepared
This should all be agreed in advance so that you and your team can make the most of it. But this principle applies to consultancy days as well, be really clear on what you are looking to have achieved by the end of it, but be realistic. Don’t be expecting to walk out a software expert after one day of training, it just isn’t going to happen!!
Nope, I am not clearing my throat! For those of you that know me well, this is my particular bug bear. I can talk about the importance of testing forever….or at least a really long time but given that this project is about documentation, I am going to stress how important it is to create testing sheets.
These sheets should be given to every individual using the system, and should be used to document the processes and areas that have been tested by that individual. Now ideally everyone would create their own testing sheets with the different scenarios but at the very least, you should have a team testing sheets that everyone takes a copy of to work through.
At a MINIMUM, these should contain:
- List of process elements to test
- Use cases / different scenarios to test
- Space to put notes or any identified issues
- Signature / date area for the tester to sign, its amazing what the requirement to sign a document can do for the thoroughness of the testing!
For those of you looking to implement sage 200, here are some example sage 200 testing sheets to play with!
Read all about it!
OK, so your software implementation project isn’t newsworthy but it is definitely something that your project team should be reading about regularly. So set a communication schedule and stick to it.
Your project updates should include
- Updates on completed/uncompleted tasks
- Whats happening between now and the next update
- Reminder of your milestones / key dates and deadlines
GO live document
Again this is one of those unknown or rarely used documents that we find invaluable. It outlines the process for the move from testing to live and the individual tasks and steps that need to be followed to get you there.
A go live document should include as a minimum:
- Contact details and emergency/out of hours contact details for all those that may need to be involved in the move. Don’t forget your external contacts too, i.e. IT contacts
- Milestones and their dates
- Tasks that need to be completed, by whom, when by and in what order
So that’s it! The minimalists guide to a great ERP Implementation! We hope you found it useful and we would love to hear your feedback! Leave us a comment or tweet us @itassolutions
Until next time!