Document, Document, and Document Again

May 17, 2018

Are you one of those people that just loves to document everything? If so, my hats off to you. Most of us have to push ourselves to fully document in detail. Perhaps you’ve experienced the Nightmares of following others who didn’t document well.

 

In a recent major Maximo implementation, the Project Team agreed at the outset to over document throughout the project. With so many moving pieces and involved parties, it’s imperative that everyone agrees on critical (and even not so critical) decisions. During the project, well over 40 workshops were completed. In addition, there were hundreds of phone conversations and e-mail exchanges. With all those conversations, what’s the likelihood that something will be misinterpreted? Itt’s almost a certainty. Let’s look at few specifics to demonstrate the point.

 

1)   Project Plan (Charter)

How extensive was your project plan on your last major project? Did it make clear all the phases of the project (or even capture all the phases) and, in detail, the steps involved in each phase? Did it fairly accurately detail the hours involved to complete each step? Clearly, the project plan is a major part of project documentation. It can lead to smooth sailing for months and years to come while implementing a Major ERP (like Maximo Asset Management). Or, it can immediately detract from the project and even undermine it.

 

2)   Functional Requirements

On the previously mentioned project, teammates encouraged and supported each other throughout the implementation to document the Maximo Functional Requirements in detail. This was vital. Every team member relied on that document to generate a Technical Design, to guide data collection efforts, build workflows, create numerous integrations, and much more. The client’s Maximo Project team members likewise constantly referred to that document going forward when disputes arose or clarifications were needed. Four separate Requirements documents were created and signed off by all interested parties. You’ll be thankful shortly before Go Live with a major release to have all that documentation.

 

3)   Supporting Documents

There will be lots and lots of Supporting documents created by many different team members if your involved in a large scale implementation. This is where Standards apply. Do establish documentation standards ahead of time with all team members. These standards should address the form of documentation as well as the extensiveness of documents. This is also another area on which all interested parties must agree. Thinking back to your experiences, were all documents consistent and fully detailed? These may be documents related to Interfaces, business process designs, workshop outcomes, and much more.

 

4)   The Dreaded Re-work

It is not uncommon to come across the dreaded ‘change request’ when designs don’t quite meet the needs of an organization. In some cases, an entire project had to be reworked. This is not a place you want to find yourself whether you are an implementer or an organization’s Maximo team member. Again, strong documentation and agreement helps all involved parties. After all, the goal is to have a project completed on or under budget and within established time frames.

 

5)   File Sharing

The last point on documentation is to encourage the use of a file sharing system accessible by both the consultants and the organization where the system is being implemented, even if the implementation is performed fully by internal staff members. All project documentations, test results, agreed upon fixes, and more should be posted here. This greatly facilitates information sharing in a bi-directional way.

There are so many more types of documents (strong project management documents, training documents, etc.). However, we’ll conclude here. We truly look forward to  hearing other’s experiences and approaches to documentation. Have you joined a project ‘after the fact’ and had almost no documentation to follow? It’s both expensive and time consuming with little to no documentation to interpret why a previous consultant may have designed a system a certain way.

We look forward to your comments.

Post A Comment:

Your email address will not be published. Required fields are marked *