Your BPM project is ready to “Go-Live” and you are excited about finally reaching this point. You are thinking about your creation and all the countless hours spent discussing requirements, revisiting and changing them, creating robust processes, designing and executing flawless architecture, and following best practices while writing code. But no creation can sustain for long without a plan for maintenance. No matter how bulletproof the code is and how many testing iterations you have gone through, there will be changes requested or defects discovered in production. A BPM project, be it waterfall or agile methodology, will evolve as the company’s business evolves and a sound maintenance plan is instrumental in responding to that evolution. Below are the keys to having a successful BPM maintenance plan.
Procedure to Report and Monitor Defects and Enhancements
In the maintenance phase of the project, the best way to report end-user defects and requested enhancements is to use a bug-tracking system. A bug-tracking system can monitor progress of defects in a structured and organized manner. Defects and enhancements can be organized on many levels, one of them being the severity of the defect. Often times, end-users/business group’s idea of a defect being severe (affected functionality) is different than that of the development team (complexity of the fix), but defect severity should always be decided by the end-users/business group. Ideally, one person from the end-user/business group should have the responsibility to enter defects in order to avoid duplicate defects from being entered and eliminate confusion. Assigning of the defects to developers, should be the responsibility of one individual on the development team to avoid assigning similar defects to separate individuals.
Procedures to Deliver Solutions
Most BPM projects have multiple production phases which leads to having a maintenance plan that should work in parallel with continual development for the next phase. This calls for a structured and disciplined plan of attack. A different change management plan needs to be laid out for different levels of production deployments. For example, an emergency fix, an enhancement, and a pre-planned phase deployment all call for a different change management plans.
One piece of change management is the use of a code repository like SVN. All code repositories come with standards that should be followed. Concepts within a code repository like trunks, branches, and tags should be implemented to deliver solutions for defects that do not hamper or stop continual development for the next phase. Another important piece of change management is documentation, specifically release notes. Release notes detail the changes or enhancements made to specific features and help set end-user expectations. We will get back to the topic of documentation later in the blog.
The Right Personnel Resources
One of the keys to having a successful maintenance plan is to hold on to the personnel resources, specifically developers and BAs, who were involved in the day to day BPM project development cycle, before the first production release. Quite often, such resources move onto the next project soon after a successful production deployment. These resources hold a ton of knowledge and expertise about the project, sometimes not found in even the best of project documentation . In situations where resources are not consistent, new resources should to be lined up as soon as possible and an interactive project knowledge transfer needs to occur between the departing and incoming resources. The transition can be made easier with the inclusion of good technical and end-user documentation which leads me to my next point.
Comprehensive Documentation
Often times, in the midst of slinging code and reaching project deadlines, the importance of writing, assimilating, and sharing documentation is forgotten. As time consuming as it sounds, writing comprehensive technical documentation is equally or more important than drawing processes, writing code, and delivering a production ready BPM project. Alongside technical documentation, having end-user documentation is also important. Technical documentation should progress and be hand-in-glove during the normal project life-cycle along with the changing code and architecture and not be an after-thought during production release. End-user documentation should follow the same continual progression pattern with active involvement of some end-users for constant feedback and improvement. There are plenty of automated tools available, including some code repositories and bug-tracking systems, that can help generate end-user release notes and help keep technical documents updated.
Good technical documentation comes very handy and improves the knowledge transfer experience between departing and incoming personnel resources. During maintenance, good documentation helps affirm whether a reported defect is a bug, a requested enhancement, or working as designed. End-user documentation also helps in this regard as end users understand whether user interface functionality or a path taken by the process is per design or a defect. The documentation also helps make the communication cycles between end-users and the development team efficient. Both technical and end-user documentation facilitate debugging defects and help reduce turnaround time in taking the correct action on defects and thus add value to the plan of maintenance.