How to make the most of MotioCI in supporting proven practices

MotioCI has integrated plugins for Cognos Analytics report authoring. You lock the report that you’re working on. Then, when you’re done with your editing session, you check it in and include a comment to record what you did. You can include in the comment a reference to a ticket in an external defect-tracking or change-request system.

You can find additional details about how to set up the connection between MotioCI and your third-party ticketing system in the MotioCI Administrator’s Guide under Using MotioCI with third-party ticketing systems. A keyword (fixes, close) with the ticket number will close the ticket. Or, using a keyword like references plus the ticket number will write the check-in comment to the ticketing system and leave the ticket open.

The use of a ticketing system – like Atlassian® JIRA, Microsoft Windows™ Trac, or many others – aids project management by tracking specific tasks, issues and their resolution. Tickets provide a means of communication between authors or report developers and end-users, the testing team and other stakeholders. A ticketing system also provides a method of tracking defects and ensuring that they are addressed before promoting a report to production.

Typical Workflow for Report Development

To be clear, the integration of MotioCI with a ticketing system is not the only way that your team will interact with the ticketing system. Typically, as illustrated in the accompanying workflow diagram, the process of report development in a Cognos Analytics environment with MotioCI might be something like this:

1. Backlog. A new ticket is created. A Business Analyst documents the business requirements for a new report and enters it directly into the ticketing system by creating a ticket. He places the ticket in the backlog state.
2. Development. The backlog tickets can be prioritized in a number of different ways, but ultimately the ticket will be assigned to a report developer and tagged with her name. The state of the ticket may be changed to in_dev. She will create a new report. As she develops the report in Cognos Analytics, she will will check in her changes and reference the ticket in the check-in comment, like “Created new report; initial version; added prompt page and supporting queries, refs #592”. Or, “Added fact query and crosstab; filters and formatting, refs #592.” (In MotioCI, the hashtag number becomes a hyperlink directly to the ticket.) She may check out the report, make changes and check it back in with the ticket reference multiple times over a period of days.
3. Development completed. After the Report Developer has completed the report and bench tested it, she notes in the ticket in the ticketing system that it is ready to be tested by QA and changes state from in_Dev to ready_for_QA. This state is a flag for the MotioCI Administrator, or role responsible for promoting Cognos reports, that the report is ready to migrate to the QA environment for testing.
4. Promotion to QA. The administrator promotes the report and changes to the state to in_QA. This state lets the QA team know that the report is ready to be tested.
5. Testing. The QA team tests the report against the business requirements. The report either passes or fails the tests. If the report fails QA testing, the ticket is tagged with the in Dev state, returning to the report developer for fixes.
6. Testing successful. If the report passes, the QA team tells the administrator that it is ready to promote to production by labeling it ready for Prod state.
7. Promotion to Production. Once the report is ready for production, final approvals can be obtained and release scheduled, perhaps bundling with other completed reports. The administrator promotes the report to the Cognos Production environment. He places the ticket in Done state indicating that development and testing are completed and it has been moved to production. This closes the ticket.

Management of the Report Development Process

This ticket management process implies and proven practices dictate that:

• Every new report should have a ticket with the business requirements to design the report to.
• Every defect should have a ticket to record any bugs or issues with a report.
• Every time a report is edited, the MotioCI check-in comment should include the ticket number which was addressed.
• Every report that is promoted from Dev to QA should have an associated ticket that an administrator can confirm that development has been completed and it is ready to be moved to the QA environment.
• Every report that is promoted from QA to Production should have a ticket that has a history showing that development is complete, it has passed QA, it has received all required management approvals and has been promoted.
• Every report in the Production environment should have a digital paper trail from conception to testing to fixing to resolution to approval and promotion.

This last point is a favorite of auditors to validate. She might ask, “can you show me how you confirm that all reports in the Production environment have adhered to your documented process of ticketing and approval?” One way to respond to the auditor might be to provide a list of all the reports that have been migrated and have her wade through the tickets to look for one that does not conform to your process.

Alternatively, and more ideally, you can provide a list of reports that do not adhere to the development and ticketing process which you have defined. That’s where this report will be useful: “Reports Promoted with no Tickets”. It’s an exception report of a list of reports which have not adhered to the best practices of having every report change tied to a ticket. This is one of the few reports you want to be empty. It will have no records if all reports which have been promoted have a ticket associated with it. In other words, a report will only appear on the list if it is in the Production environment and the report that was promoted did not reference a ticket number in the comment.

Process with Benefits

What are the benefits of the process, or why should you do this in your organization?

• Improved team collaboration: The ticketing system may actually bring together individuals in roles who may not normally communicate. Report authors and end users, or project manager and the QA team, for example. The ticket trail provides a common place to communicate about a shared resource, the report under development.
• Reduced costs:
  • Defects caught and fixed sooner are much less expensive than if they escape into production.
  • Improved efficiency – report authors are always working from a ticket which is a well-defined statement of work.
  • Reduced time through automation of manual processes
• Improved documentation: This process becomes a self-documenting knowledgebase of defects and how they were resolved.
• Improved forecasting and analytics: You can now track key performance indicators and compare them to service level agreements. Most ticketing systems provide these types of analytics.
• Improved internal support: Your support team, other report developers (and, even, your future self!) can look up how similar defects were addressed in the past. This shared knowledge base can lead to rapid resolution of defects.
• Improved end-user satisfaction: With direct access to developers through the ticketing system, users can expect rapid resolution of defects as well as monitor the progress of a requested report through the system..

Conclusion

This is one example of rich payoffs to following proven practices and the value of following well-defined processes. Further, the new MotioCI report, “Reports Promoted with no Tickets” can be a huge help in addressing questions from an auditor, or simply internal monitoring for adherence to corporate standards.