Implementations – UAT Phase – Some tips to quickly act upon daily feedback items

User acceptance testing phase is one of the most important phases in a project implementation life cycle.   Ideally, prior to getting into the UAT, one of the main entry criteria that any client team will try to comply to is a standard issue tracking system, preferably an automated tracking mechanism like Quick Test Professional or JIRA.  If this is already in place, it makes it easy for all the stakeholders of this phase to align to a standard issue reporting, progress tracking and closure mechanism.  But, we may observe that there are quite a lot of implementations where client does not have such a streamlined approach for UAT tracking.  Of course, by the time we go-live with our implementation, we would for sure get aligned to a standard issue tracking tool like the ones I mentioned above.  This being the case, it becomes an added responsibility of the implementation manager to define an offline feedback tracking mechanism to smoothly sail through the user acceptance testing phase.

In this article, I will be giving an overview of the techniques & tools, practices that can help track issues in a streamlined manner during the UAT, and will also touch upon the high level benefits we shall reap out of it.

Need for a feedback tracker

In the absence of an automated issue tracking tool, we have an absolute need to define a standard issue / feedback tracker that can be used throughout the UAT.   The tracker shall need to focus towards capturing daily test feedbacks, define their severity, prioritize them, plan the related next steps (be it clarifying questions, building new functions for the implementation, fixing issues or ever supporting data clean-up activity), and bring them to closure.

Fundamental attributes needed for a basic tracker

A basic feedback tracker may need the following key placeholders to capture and track issues:

Requested Date - Date on which issue was raised

Module / Function - A hierarchy as needed of the module / screen / functionality to which the issue belongs to

Issue Description - A brief description of the issue (which can also refer to external documents / screenshots, etc)

Issue Type – Can be a well defined standard list of values like – Data Set-up, Clarification Request, Bug, Data Migration Request, Data Clean-up Request, Change Request, New Feature, and so on.

Priority – Can be as simple as High / Medium / Low

Issue Status – Can be a list of well defined statuses that can help consolidate issues under buckets relevant to each stakeholder group.  For example, the statuses New, Dev-WIP can fall into the Development team’s bucket, the statuses Dev-Completed, QA-WIP can fall into the internal test team’s bucket, the statuses Pending Client Clarification, In-UAT can fall in the Client’s bucket and the statuses of Pending Internal Clarification can fall in the Onsite implementation team’s bucket.  The issue can be pushed to Closed status when it formally attains closure through approval from the right stakeholders.

Requestor and Assigned To – A couple of columns to track the requestor and the person who may own the solution for the issue will be of critical need.

Expected Delivery / Closure Date – Finally, it is very important to track the expected resolution date which can be decided based on the type of the issue, severity of the issue and its priority amongst the list of issues in hand.

Manual Issue Tracking Process:

With a standard template defined for an issue / feedback tracker, it is of utmost importance to define a proven process to capture and track the feedbacks. With issues and feedbacks falling from all directions (End users in the test group, Client IT team, teams handling external systems interfacing with our product, Client side Infra team and so on), a disciplined approach to capture the feedbacks quickly and transmitting it to the relevant stakeholders in a timely manner without losing the streamlined mechanism of issue tracking is quite a big challenge that the implementation lead will have in his/her hands.

Publishing issues each End-Of-Day is highly critical.

The implementation leads should feel free to approach internal project management fraternity to support them in maintaining the tracker.  This is because as implementation leads liaising with the customer, they may need to give increased focus on quick turn-around in trouble shooting, decision making and test support.  Meanwhile, an internal counterpart can very well help in expediting the progress of issues to closure by coordinating with the various internal stakeholders like development team, internal infra team, internal QA team, technical writing team, etc.  This way of leveraging the skills and efforts of internal managerial counterparts is very beneficial especially when the client location and the development center’s location are in entirely different time zones.

A short daily internal stand-up in which all the internal teams and the implementation lead shall be attending prior to status calls with clients for sure will help get updates on most critical feedback points from the various internal teams.  Such stand-ups should not consume more than 30 minutes for the benefit of all stakeholders.

Publishing a feedback dashboard in a regular basis, ideally every day during the UAT, with summary of issue counts categorized as Issue Type Vs Issue Status, Issue Type Vs Issue Aging, Feedback Closure Trends and so on helps a lot in easily finding out bottlenecks proactively and nip operational problems in the bud.

As I had initially mentioned, since the manual tracking of feedbacks and issues is just a workaround for the absence of an automated issue tracking tool, the implementation managers should always liaise closely with the client to expedite the next steps to start tracking issues through an automated tool which can even be an in-house tool supplied by the company implementing the product or the client’s own in-house issue tracking tool.

Benefits that can be reaped out of formal issue tracking:

• Getting a good handle of client sourced issues
• Transparency of severity of issues
• Categorization and Prioritization of issues helps expedite closure of right issues at the right time
• Issue categorization also helps in follow-ups to be done with the client base at the right time
• Daily Stand-ups help in bringing in issues slipping through the cracks
• Daily Stand-ups also help in showcasing quick turn-around times by the implementation team
• Bringing in right visibility of issues being tracked through dashboards, helps build good rapport and increased confidence level of customer base
• Dashboards also help in client side decision making on UAT schedule and sign-off timelines

Summary

 In summary, I have just elaborated on:

• The need for a manual issue tracking mechanism in the absence of a standard automated test tracking collaboration tool
• The various fundamental attributes needed to define a basic manual issue tracker
• A suggested proven model of issue tracking activity while executing UAT
• Key benefits that can be derived by means of following a formal issue tracking process

Feel free to share your feedback on the elaboration and points discussed.