Like many consultants, from project managers to the worker bees, documentation always is the elephant in the room. No one wants to do it and sometimes it feels like a burden versus beneficial. I have always struggled from project to project on how much documentation is enough. This ranges from all aspects of BI configuration and custom development.
Obviously, there are specific deliverables that you must provide as the system integrator but sometimes these are loosely dictated. As a manager, this requires you to determine what framework is and what the correct amount of documentation is. Even after this, you must receive buy-in from your team because if you don’t, it doesn’t matter how much of a dictator you are as it may lead to the following:
- Poor documentation
- Incomplete documentation
You also don’t want to create documentation that becomes obsolete once it has been delivered. What I mean by that is once you have documented too much and once something changes it becomes too difficult to reversion. At this point, you might as well not have done anything because you just created documentation to create it and it really didn’t provide the value that you expected it to.
I think some of the the main guidelines that should be followed for documentation are the following (we will use BW as an example):
- SAP alignment – The custom development should be categorized and/or grouped together as similar development. This will allow you to pinpoint the document(s) that need to be updated more easily. This will mirror how SAP is organized from a functional side and a technical side. Now, I am not saying there should be 1 document for Sales and Distribution (as an example) but there may be multiple documents that are categorized within SD.
- Simplify – If you can’t simplify the documentation, it has already become obsolete. It should carry a specific point which needs to be identified during the project prep phase. It should be easy to update and identify the areas that need to be updated. I don’t want to document every InfoCube, MultiProvider to the InfoObject because I know this information exists in the Metadata and will be meaningless to the client.
- Longevity – Documentation should be able to stand the test of time. It should hold value from the 1st day that you create it to the end of the life for the customization, if it ever becomes sunset. Even during the sunset phase, it should provide enough value to support the new product development life cycle
- Team census – I think this is one of the most important aspects to all pieces to a project. As a project manager, you want your team to have influence on what they will be documenting, just like they have influence on what they are developing. Whenever someone can make an impact, they will accept responsibility. Seeing the coin from both sides, I can understand this probably better than others.
- Transition sensitive – During the transition time, everyone is tasked with ‘please come up with a transition plan’ and documentation so your development can be supported by resource X moving forward. If documentation is done correctly the first time, a lot of this information should already be available to the new consultant/resource.
- Explanations – You may be like, what do you mean by explanations! Everyone has landed a new project and joined a new team. They may have been that person that the transition should have occurred to but that consultant is no longer available or around. We all know how much BI content is available and sometimes Z objects are created for specific reasons. By documenting a cross walk table, stating assumptions, issue resolution and comments you hope you can provide enough information that the next consultant doesn’t reinvent the wheel and it displays a snapshot of your thought process. I know I have joined a new project and had to scratch my head for hours trying to understand why the previous consultant developed some functionality that may have easily been leveraged from business content. This doesn’t mean the consultant did it incorrectly.
I think these are the biggest benefits for documentation. If you can master all or some of these, not only have you done an amazing job but the client will be able to better off with your document than without it.We all have to remember that documentation takes time, it is boring and mostly unsatisfying but many of us forget that it is part of our job. Without it you can’t help the next person find their way….
How would you improve this outline? How can I improve my thought process...please input!
