A BASIC ISSUES TRACKING SOLUTION Project Management (PM) is faced with the challenge of managing the Technology projects for the Investment Management Group. The challenge is made more difficult due to the legacy environment where the Information Technology (IT) staff very loosely managed projects, while the end users provided only rudimentary specifications of system requirements. Quality assurance methodology is similarly absent, with testing conducted often without a detailed plan or record of results. Accountability for deliverables has been difficult to find in this type of environment. PM has made some progress in addressing these shortcomings. Written specification documents and test plans are being introduced, and the user group is receptive to the changes. In this paper I will introduce a framework for Managing Issues that could be useful to PM, offering the ability to capture information, report on the status of issues, and allocate resources among the various concurrent projects. Identification of Issues Issues can be anything from needs for procedural improvements to requests for major system implementation. Typical issues are needs for reports or improvements to existing systems. Issues are usually identified by end users, but can be revealed by PM or IT while researching other issues or developing solutions. The act of recording issues should be centralized within PM. Issues Tracking An Issues Tracking System (ITS) will provide the ability to record, track, communicate, and archive the status of any issue throughout the issue's lifecycle. The ability to report on groups of issues, perform aging analysis, etc., can be built into the system as well. The specific profile information that is recorded for each issue can vary, depending on the needs of the group employing it. Typically, ITS will require information about the origin of the Issue, nature of the Issue, status of the Issue, and resolution of the Issue. I have attached a sample ITS data collection form for a simple system under consideration for use in PM (Appendix). Origin information for the sample includes Date Opened, Originator, and Originator Phone. Nature information includes Issue Description and Potential Impacts. Status information is Received By, Received Date, Assigned To, and Assigned Date. Resolution information recorded is Resolution, Resolved Date, Approved By, and Approved Date. Issues will be identified on a frequent and regular basis. By recording them, we ensure that the issue is captured for prioritization, analysis, and resolution. How to Classify Issues Priority In order to assure that proper attention is paid to issues, they need to be prioritized as they are recorded. Prioritization is generally the responsibility of the end user, except in cases where a technical problem needs technical resources to assess the risk. A simple Priority field would allow valid values such as High, Medium, & Low. Effort Proper estimation of the general effort level needed to resolve an issue helps to allocate resources. General effort estimates can be provided by PM, but will not substitute for more detailed time/cost estimates that may be required for more complex issues. A simple Effort field would allow valid values such as High, Medium, & Low. Which Issues to Resolve Regular, periodic meetings need to be held involving Client, PM, and IT management. At these meetings the open, unassigned issues will be discussed, and the client will be asked to determine the priority order of the outstanding High, Medium, and Low effort issues, among others in the same effort class. IT will then commence preparation of cost & time estimates for the issues, in priority order. Cost & time estimates can be prepared between meetings, for issues that need immediate attention. Some issues may not need IT estimates, as the effort may be all PM, e.g. Business Process Reengineering or desktop computing solutions. The treatment of these items will be determined. Project Responsibility Assignment PM will meet to discuss issues that have been prioritized for resolution. Issues will be assigned to Project Managers, Senior Business Analysts and Business Analysts based on existing workload, Project size, and individual skills and background. Teams can be formed for larger projects. Low effort projects can often be resolved as quick hits, avoiding the need to formally assign responsibility, and reducing the backlog of unresolved issues. Management of Projects Specification A specification document should be produced for each issue being resolved. It is the responsibility of the Manager or Analyst assigned to the project to arrange a meeting with the requesting client, in order to discuss and record the requirements of the project in the specification document. For complex deliverables, it may be necessary to have IT representation at the meeting as well, to ensure the proper detail information has been captured for IT to use this as a basis for a Technical Specification Document. The document may contain text and prototype reports as needed to communicate the requirements. The final Specification document is to be reviewed and signed off by the Client to verify that it meets their requirements. Handoff to IT The completed specification document is handed off to IT. It is expected that the solution will be delivered as per the Time Estimate. Regular communication should occur to monitor and facilitate the timely progress of the programming solution. Periodic review of the deliverable can reveal program flaws before they are too difficult to repair. Quality Assurance (QA) Testing of the solution can and should be prepared while IT is developing. The high-level test plan, test scripts, and expected results, as appropriate, should be ready to execute when the technical solution is delivered. The actual testing will be a collaborative effort, involving PM resources and Client resources. This takes advantage of the Clients familiarity with the business issue being addressed, as well as the QA team's experience testing application software. (To Consider: Will QA be a unique entity within PM, drawing on experienced testers working with end users to design & execute test plans, or will QA be responsibility of the Manager or Analyst assigned to the project working with end users to design & execute test plans?) Pass/Fail The requesting client will review the QA test results. If approved for implementation, client will sign off, and IT will schedule installation. If not approved for implementation, client and Manager or Analyst assigned to the project will document why, sign off, and return to IT for further development. Implementation The release of new software needs to be a coordinated effort. A final meeting between the Manager or Analyst assigned to the project, the requesting client, and IT resources should be held. This meeting will ensure that all parties are aware of the implementation date, no processes will be adversely affected, no other projects will be negatively impacted, proper backups are being taken, and any other issues impacting the project are addressed. Adherence to the proposed development plan should facilitate a smooth implementation. In order to measure the effectiveness of the Issues Management process, a post implementation review or survey could be circulated to client. It would assess the quality of the process and the deliverable, and help to record any issues or problems that were encountered. The Client's Role Issue Identification Most issues will be identified by the end user. Issues can be anything from needs for procedural improvements to requests for major system implementation. Often they are revealed during the course of normal processing. Typical issues are needs for revised or new reports or improvements to existing systems. After identifying an issue it needs to be documented. Documenting an Issue After identifying an issue, the client will fill out an Issue Tracking Form (See Appendix). The following fields need to be entered: Date Opened: Originator: Who is raising the issue? Phone: Extension of Originator Issue Description: In as much detail as is practical, describe the issue and suggest the resolution that you expect. Attach any system screen prints, emails, report output or other hard copy that clarifies the issue. Potential Impacts: If the issue remains unresolved, what are the potential impacts? The remainder of the form will be filled out by PM Participate in Resolution PM will prepare a Functional Specification Document, with assistance from the client. The client will sign off that the Functional Specification Document describes a solution that will satisfy the business issue described in the Issue Tracking Form. PM will prepare a Quality Assurance Test Plan, with assistance from the client. After testing, the client will sign off that the Quality Assurance Test verified that the IT solution meets the business requirements described in the Functional Specification Document, and can be moved to production. Client Feedback In order to measure the effectiveness of the Issues Management process, a post implementation review or survey could be circulated to client. It would assess the quality of the process and the deliverable, and help to record any issues or problems that were encountered. APPENDIX Issue Tracking Form Issue Tracking # ____________ - Assigned by PM Date Opened: ____/____/____ Originator:___________________________________ Phone:_____________________ Issue Description: (Attach screen-prints as needed) Potential Impacts: Received By:________________________________ Received Date: ____/____/____ Assigned To:________________________________ Assigned Date: ____/____/____ Resolved Date: ____/____/____ Resolution: Approved By:________________________________ Approved Date: ____/____/____