If you are the one who implements BPPM for your organization or for your client, do you take your time to write accurate and detailed documents for every project? If you are the one who manages BPPM implementation for your organization, do you require your employees or consultants to deliver accurate and detailed documents? Most importantly, do you budget enough time for your employees or consultants to write documents?
Documentation is one of the most overlooked part in BPPM implementation especially when you are under the pressure to meet an aggressive deadline. I have been to several 'rescue' missions when things just fell apart after the person who did the implementation left the organization. With very little documentation, I had to rely on reverse engineering process by going through the entire source code, configuration files, trace files, and running my own test cases just to understand how things were implemented. After that, I would write those missing documents based on my understanding.
Would it be worth taking a few days writing accurate and detailed documents to avoid weeks and months of headache and reverse engineering work?
So what documents do we need in each BPPM project?
1) Architecture Diagrams: If this is a new BPPM implementation or upgrade, you need to draw or redraw architecture diagrams showing BPPM components located on each server. You only need to redraw architecture diagrams if you made architecture changes in your project.
2) Release Notes: No matter how small or how big your project is, you always need to write a release notes. A release notes should include why (business requirements) and what (features added/enhanced/deleted) about this project. You can also include high-level how to help the readers to understand the features involved. Include assumptions, limitations, and supported environments if applicable. Release notes is usually short between one and three pages.
3) Deployment Guide: Another mandatory document is deployment guide. How can another person deploy the new features you just added to a new system even when you are not around? Where are all your files located? What are the prerequisites? What are the verification steps to tell the deployment is successful? Be precise on the order of deployment steps. Be as detailed as possible. I personally like to include screen shots and provide examples. Some of my deployment guides are as long as 250 pages. A deployment guide ensures all deployments will be repeatable.
4) Design Specification: If your project involves development such as custom PATROL knowledge modules or BPPM cell rules/policies, it is a good idea to include a design specification. You don't need to go down to pseudo code level but do include clear comments in your code. Highlights on important formula and communication between different components can make code maintenance by another person a lot easier.
5) Operations Guide: If you expect operations or administration staff to perform certain tasks that are not available in BPPM documents from BMC, you would need to document how to perform those tasks in operations guide. For example, how to re-assign integration service for each PATROL agent to re-balance the load? How to re-sync mcdb between primary and secondary cells if they are out of sync? Operations Guide can also include troubleshooting procedures and frequently asked questions.
Need a deployment Guide
ReplyDelete