THE GOOD, THE BAD AND THE UGLY – PART 2: DOCUMENTATION

Welcome back to those who took the time to read my first blog post. I hope you enjoyed it.

In this second installment, I am going to try and touch on the main issues regarding documentation and use my own experiences to try and help provide ways that these can be improved.

Let’s set the scene. Customers who have been tasked with delivering the project in conjunction with the IFS project team are generally a little unsure as to what is exactly required from them. The team tend to be introduced to the functionality of the system through IFS fundamentals (a high-level training course to introduce the IFS Application). After completing this, the workshops kick off and we are right in the thick of seeing the IFS modules relating to each area of the business. Exciting times but also daunting as to what to expect.

Most of the time during workshops I see customers watching, asking questions and attempting to make design decisions to help facilitate the businesses processes. The common mistakes I see are that customers do not take notes and the notes they decide to take down during these workshops are for high-level decisions or information they need to give the consultant.

During this blog I am hopefully going to address some of the common documentation used by an IFS project, as well as offering some key suggestions to help you get the most out of your implementation, and more importantly time.

Disclaimer: Just as last time! I cannot guarantee this, but I will make a strong statement that this will generally improve your processes and when revisiting topics to ensure you know why it was decided.

Documentation Overview

The standard documentation to expect from an IFS Project tends to be Contact Reports, the Book of Rules, Scope Tracker, Actions, Decision, CRIM Logs, Test Scripts and Step by Step guides.

I will address each of these in turn and how we can ensure we get the best results out of all of these.

Contact Reports are used by the consultant to track the agenda topics, attendees, actions, decisions and any other useful information from the workshops. Do not be alarmed to see this additional information it is just making note to absences, length of breaks and risks. It must be documented in order to highlight to the project team why agenda items were not covered, or that the team does not have enough time due to other responsibilities to adhere to the timings etc. In Projects this is highly useful as it allows the team to see where we are and why we may need an additional workshop etc. However, it is also a two-way document. Once it is sent out, I advise you to read, digest and make any points that you think are missing known and it can be updated.

The Book of Rules is a way of capturing high-level decisions made to configure IFS to handle the business processes. To get the best out of this document is to ensure it ties up with the others as you go through, such as the decision log, actions and potentially step by step guides. This may seem like a lot of work but if it is to be done from the start you will end up with a much more useful document than trying to recall decisions you made as a team in the 1st workshop. The consultant will normally take the lead of this document and in the first 3 to 4 workshops will fill this in with the team to ensure that you are prepared to take over the population of this document.

The Scope Tracker is an overview of all the processes that during the scoping days and sales meetings the business believes it will need. During the workshops this will be refined to remove the processes which are not required being set as ‘out of scope’. This will mainly be managed by the consultant but as team you may want to log this decision in the Book of Rules so in 6 months’ time, when the question comes ‘why are we not using X, Y and Z?’, it can be answered without hesitation or more importantly after referring to the documentation.

Actions, Decisions and CRIM logs are used to monitor the number of items that need to be performed outside of workshops, or maybe before a certain workshop topic can be covered. Actions refers to the homework which could be assigned to the team or maybe the consultant. Decisions will be the important items which the team cannot make without approval from senior management or potentially an acceptance committee etc. CRIMs refer to Custom Objects, Reports, Integrations and Modifications. These are there to handle the exceptions that IFS cannot handle as standard. It is important to get these started as soon as you are aware to ensure they will be ready for testing.

Test Scripts and Step by Steps I will include as one. This is due to these needing customer input for business examples. Every project I have been on so far have asked for standard Test Scripts and training material. The issue is there isn’t a set standard because each project has different time scales and targets. Project A may be happy to test processes with dummy data following a specific step by step guide to prove that it can handle the process as they see it, whereas, Project B will want to test the processes with a real business example and ensure that everything matches up with the current results and any discrepancies can be explained. I give these two examples to show how the standards cannot be set as each business is different even though they all have a finance, procurement, sales, HR, IT team etc… The way they handle tasks within this can vary hugely.

THE GOOD

Documentation at the start of a project is met with a strange air of excitement by teams, as it is an opportunity to start tangibly showing progress of the IFS Implementation.

The Book of Rules, Scope Tool and Actions, Decisions and CRIM log tend to be reviewed and updated at the start and finish of each workshop. With each person responsible having positive responses, such as “complete” or “working in progress will be done by Monday”, etc…

Contact Reports are sent the following day, reviewed by customers and any comments mentioned. Some customers even take the contact report and expand the brief outlines to generate a more detailed version of events, explanations etc to save in the same place.

Agendas also seem to be a focus by customers wanting to know the topics in order to prepare any information that could be useful for the workshops. This allows for the consultant to use this information while demonstrating which can improve the quality of the workshops.

However, with all this excitement expectations can become very hard to meet very quickly. Preparing information for a workshop a week in advance to send to the consultant to read, digest and use in the following workshop may be harder than you think. Consultants tend to work on 2 or 3 projects a week meaning that if you send it during the week of the workshop you may not get it.

Key Suggestions:

  • Use One Note (Not many people are familiar with this but to capture screenshots, decisions and rough notes during workshops it is a fantastic tool)
  • Ensure to have a screen grabbing tool (My recommendation is Lightshot a free tool)
  • Don’t Neglect Documentation to get the most out of your implementation, ensure you capture as much as you can.
  • Introduce team responsibilities e. who will be responsible for each document or plan how to capture information efficiently i.e. templates or a shared One Notes.

THE BAD

As with everything if we start off with too much too soon then it becomes difficult to maintain this (I assume everyone can relate to this if I mention New Years Resolutions and especially Diets).

Therefore, I will point out the Bad habits which start to happen. One which is never factored in during projects is staff leaving. The more you write down and know where things are, the easier it is to take over this documentation with a simple handover. If it is neglected, then the documentation becomes outdated and leads to it having to be updated retrospectively.

Another item is reviewing the documentation. Make sure that if you are making decisions and writing guides that you ask a colleague to review and test. This is to ensure that you have captured it correctly. Otherwise, if it is written down incorrectly or rushed it can be misinterpreted and re-open a decision which is not necessarily needed to be re-opened (warning decisions regardless of how simple can take a while to close out).

But one that really does seem to happen in everyone project is assuming that someone else has done something or putting it off ‘til tomorrow (most likely – tomorrow never comes). Therefore, if you need to update it, do it there and then. Even if it is during a workshop, just say to everyone can we have a 5-minute break and update the documents.

Key Suggestions:

  • Plan for the worst-case scenarios. You are a team. So never leave one person to cover everything. Try and ensure that two of you understand the context of the document to reduce the effects of natural wastage.
  • Reduce administration time. Make use of workshops and breaks to fill in documents where you can and potentially make a bullet point to update at the of the workshop.
  • Plan time to update. If it cannot be updated in the workshops, make an appointment in your calendar for an hour week to update them.

 

THE UGLY

Here come the honest truths of the project. Never assume that because you are performing a standard implementation that there will be standard documents for each task.

Common misunderstandings are that customers will be ‘spoon fed’. What I mean about this is that the consultant will tell you everything you need to do and, in some cases, will provide an example of what they did earlier. Consultants will knowledge share, guide and show you how to get the best out of your implementation workshops. What they won’t do, is do it for you! (they might if you ask nicely but approach with caution).

The examples I am thinking of is step by step guides, test scripts and potentially processes. Just because IFS has been implemented in your sector for a competitor, does not mean that this information will be generated from a standard set of items.

Step by Step guides take time. This is because of the nature of the beast being implemented. IFS is an ERP tool and therefore can handle everything in a rather standard way. Translating to the system is most likely going to need to be configured to meet your business needs such as adding reporting fields, automation, new reports etc. Therefore, it means that the guides become unique to your business as the same screen will look entirely different, as during the project you will hide redundant fields, tabs and right mouse buttons.

Test Scripts will mean that the processes will be written to ensure that this configured solution meets your businesses needs and wants from the required processes.

The ugly side of this is that it often gets neglected until it is too late and then the consultant is trying to help give standard examples for a customer to test. My recommendation is to capture these scenarios and processes during the workshops. Then add in business context as you practice ensuring a decision works. Once you get to the Test Script scenario you will have a Test Script and Step by Step Guide that anybody can follow to test the proposed solution. The benefit is that anybody can ask how something is handled. If they have an IFS log in you can send the document and ask them to flow through on their own and if they have any questions, they can let you know. This will help highlight any items which may have been overlooked during the design or while designing in the workshop. Let’s face it we are all only human and we will miss something or dismiss it as it is a very rare occurrence, but your colleague may be the one who must deal with it and therefore wants a resolution.

Key Suggestions:

  • Align documentation to the project plan. Make sure that all documentation is being considered and is not neglected.
  • Work smart not slow. Use the documentation as an opportunity to future proof the design and meet the other targets of the project.
  • Documentation is Key! This is the businesses proof and the opportunity to validate the design. Therefore, do not neglect it.

MY SUMMARY

 The benefits of adopting some or all these suggestions are:

  • The project team and business will understand the context behind each decision.
  • Future proofing the design. The business will be able to see why items were not used during the implementation and make it much easier to re-integrate these if needed in the future.
  • Decisions will be captured! Meaning that the process decisions can be explained.
  • Time and Cost will be reduced. By performing the documentation update in parallel you will ensure to have one version of the truth. Key to reduce the effects of change.
  • Workshops will become more effective. This is because the consultant can spend the time presenting the solution and less time chasing documentation.

But don’t take my word for it. Give it a go and approach it positively 😊.