Implementing an Issue Management Platform for Software Development and Beyond by Curtis Brenneman

Planning an Enterprise-wide Issue Management Platform

Implementing an Enterprise-wide Issue Management Platform Implementation advice for rolling out an enterprise-wide issue management platform supporting diverse teams and external participants.

Harvey Kandola http://twitter.com/HarveyKandola

Page 1

Planning an Enterprise-wide Issue Management Platform

contents

Page 1

l Introduction

l Understanding Projects and Participants

3-4

l Select Business Processes to Manage

l Data Requirements Affect Business Processes

l Data Requirements Affect Users

l Plan for External Participants

l Adopt Relevant Terminology

l Tune and Adapt

l About Countersoft

Planning an Enterprise-wide Issue Management Platform

An enterprise-wide issue management platform should typically facilitate capture and tracking of defects, tasks, quality checks, support tickets, change and feature requests from multiple locations, departments and even multiple organizations. Implementing such a platform goes well beyond the traditional Software Development team. Clients, vendors and other organizational departments also require project participation. During the implementation many organizations seek guidance around project structures, user access rights, metadata, and workflows.The rationale is that investing some time upfront to structure the implementation saves the “refactoring pain” that typically follows once the platform is in active use. Problems

are

compounded

when

multiple

applications and project repositories are deployed thus resulting in “multiple versions of the truth”. A single platform for all users will yield a “single

We could summarise the necessary steps as follows: l Understand potential users, project types and the relationship between projects “are we managing both Support and Development projects?” l Identify business processes to be managed “are we tracking Defects and Change Requests?” l Determine data requirements for different business processes “what data fields does the user fill in when logging Defects and when raising Change Requests?” l Plan for external participants requiring project participation “which external entities need access to the platform to view, update and close tasks?” l Adopt readily understood and consistent terminology “should the platform state “Modules” or “Components” when describing elements of the application in question?” l Design and implement now, tune later “focus on rolling out the platform and optimize it later for additional benefits.”

version of the truth” – no room for confusion is left if all users adopt the same project platform.

The result of following this approach is an optimized issue management platform that is aligned to the way that projects should be managed.

Page 2

Planning an Enterprise-wide Issue Management Platform

Understanding Projects and Participants If projects and users are considered the lifeblood

Consider how support staff need to interact on a daily basis with the issue management platform

of a project management platform, then some time

and the people/organizations they support. Key questions you should ask are:

spent understanding the types of projects, the

l Should there be separate projects for each external entity (e.g. client, vendor)?

types of user, and how different projects relate to one another, will help to build a solid foundation. Managing both Support and Development projects

l Should all external entities share a common “Help Desk” project? l Is there a “Help Desk” project per external entity?

on the same platform will simplify the transfer

Minimising the number of “Help Desk” projects for external organizations will reduce the

of information from one to the other. The key is

support maintenance overhead. A single project with correctly configured access and visibility

knowing how to map the information from Support

permissions will ensure that each external organization can only view their own tickets.

to Development projects. The danger is that Support Tickets will just be pushed into the Development projects without validation. This will typically result in Development projects being flooded with issues that eventually come to be regarded as “noise”. Figure 1 Controlled interactions between Support and Development projects

Filter and validate Support Tickets before creating corresponding Issues in Development projects to ensure relevant and vetted data is pushed to Development and Testing teams.

Page 3

Planning an Enterprise-wide Issue Management Platform

Understanding Projects and Participants The final piece of the jigsaw is to group projects together using a meaningful grouping identifier making navigation and filtering more logical. Consider grouping by functional areas such as “Support, Development”, or by line-of-business such as “Clients, Product A, Service B”.

Figure 2 Identifying logical project groupings

What you need to do is to:

l List projects (current and future) that can be included. l List user groups that might require project participation With the project groups defined, each project belongs to one of these groups and you will know which user groups can participate on which projects.

Page 4

(e.g. Testers, Developers, Support Team, Clients, Vendors).

l Map out logical project groupings and link them to user groups.

Planning an Enterprise-wide Issue Management Platform

Select Business Processes to Manage Business processes are there to add value for the customer whilst ensuring unnecessary activities are excluded. Customers can be stakeholders or end users of a system and can be external to the organization. If a defect in a product poses a problem for users then managing that defect through an issue management platform should ultimately bring value to the customer. The bug is logged, tracked and eventually resolved, thereby giving value back to the customer by shipping better software or providing a better service. This is also true for Change Requests, Feature Requests and Enhancements thus ensuring customer satisfaction.

Not all projects will manage the same process types. For example, a Support project will manage “Investigations, Bug Reports and Feature Request” processes. A Development project will manage “Defects, Tasks, Enhancements, New Features and Change Requests” processes.

What you need to do is to:

Understanding the process groupings and the associations with projects is required to correctly align the right processes to the right projects.

l Map grouped business processes to

be managed.

l List projects to be managed. l Logically group business processes.

projects.

Figure 3 Identifying and grouping business processes (issue types) and associated projects

You need to ask yourself: What are the internal business processes (e.g. Change requests, defect tracking). What are the external-facing business processes (e.g. Support ticket, installation). Determine if and when an external-facing process transfers to internal process (e.g. Support ticket can transfer to Bug or New Feature processes).

Page 5

l List internal and external processes to

Business processes are grouped into Issue Type groups.

Planning an Enterprise-wide Issue Management Platform

Data Requirements Affect Business Processes Different projects and issue types (business processes) may require varying amounts of data to be captured and updated.Not all of this data can be considered as ‘core’ data, which would be things like the USERID of the person who raised an issue, the date it was logged etc. What the organization must do is analyze and determine what additional data elements need to be captured, where, and for what purpose. A “Defect” may require that users provide such information as “Operating System”, “Browser Version”, etc. This data may not be relevant to an “Enhancement”, which might instead require a budget approver for the cost or a target release date. These additional data fields will probably vary per issue type. For example, a “Change Request” might ask that users provide “Rationale” to explain why the change request is being logged.

At this point we need to ask:

l Which data fields are provided out-of-the-box by the issue management platform

(e.g. Title, Affected Version, Start Date, Status).

l Which custom data fields need to be added to the platform (e.g. “Client Name”)? l Which data fields (provided and bespoke) are deemed mandatory? l What business processes requires which data fields? Experience tells us that data fields will need to vary by business process in order to ensure relevant and quick data capture during issue creation. You need to minimize the number of mandatory fields and data inputs whilst ensuring that you capture enough actionable data in each case. What you need to do is to:

l List internal and external processes to be managed. l List both out-of-the-box and custom data fields. l Determine which data fields are required per process. l Identify mandatory data fields Page 6

Figure 4 Identifying data fields required per issue type

Each issue type has clearly defined input data fields

Planning an Enterprise-wide Issue Management Platform

Data Requirements Affect Users Determining what users can “see and touch” will enable you to provide a relevant user experience and ensure better data quality. Avoiding unnecessary or irrelevant on-screen prompts during the logging of a “Defect” is an indication of a correctly configured issue management platform.

Take time to correctly align on-screen prompts to the different “touch” points. You will see less resistance, quicker platform adoption and more relevant data entry.

Ask yourself:

l Is too much information presented on

Figure 5 Requesting the right data at the right touch point, per process

screen during issue logging?

l Which data fields do users need to see on

screen (e.g. creating an issue)?

l Do the on screen data fields vary for

different stages (e.g. different views when creating and editing issues)?

l Do we need to ask for different data input

for different issue types (e.g. “Defects” and “New Features” have slightly amended data input screens)?

l Which custom data fields need to be added

to the platform (e.g. “Client Name”, “Internal Build Number”)?

Page 7

What you need to do is to:

l List internal and external processes to be managed. l Consider the difference between data entry when Creating and Editing an issue. l Determine which data fields are required per stage (e.g. Create, Edit). Each issue type has defined input data fields per capture stage

Planning an Enterprise-wide Issue Management Platform

Plan for External Participants For external users a controlled help desk experience facilitates clear communication and escalation channels. Furthermore, help desk integration within the issue management platform ensures all requests, tasks and issues are tracked and visible on a single, unified platform. External team members may work on projects alongside internal users. They can be assigned tasks, complete work and generally participate in the process. Such team members can span multiple organizations with potentially conflicting interests, personalities and agendas. Some key questions that will help organizations plan accordingly:

l How many outside organizations need to

be involved?

The main issue with external participants is information visibility: what information should they see and how can internal users protect sensitive information when everyone is using the same platform? When creating issues or comments, consider who else can view the issue and whether the

support?

l Do we have external team members who

work on project deliverables?

l What data visibility considerations do we

need to consider across organizations?

otherwise marked as sensitive. Any issue management platform that supports external team member participation must support the ability for users to mark either issues or comments as sensitive thereby restricting visibility.

l What organizational sensitive issues need

to be considered?

Page 8

l List external organizations. l Determine if external participants require

help desk or project team member status.

l Publish guidelines on when internal users

should leverage Issue and Comment visibility to suppress information from external users.

l Use Issue and Comment visibility to

conceal sensitive information from external participants.

content requires different tone, language or

l Do external users require just help desk

What you need to do is:

Internal users aware of external participants and know how to manage sensitive information

Planning an Enterprise-wide Issue Management Platform

Adopt Relevant Terminology An issue management platform that uses a lot of technical jargon or focuses too heavily on technical users will create adoption issues. The problem of terminology becomes more evident when the issue management platform is accessible by Customer Service operatives and external participants. Make the adoption less problematic by configuring your issue management platform to “speak” the same language that is already in use within the business.

l Is the term “Component” more widely

understood than “Module”?

l Is the term “Bug” more widely understood

Acquiring an issue management platform that provides localization support out-of-the-box is a bonus for organizations with different geographic locations, cultures and remote teams. What you need to do is:

l List the terms currently used. l Tweak terms list with non-technical users. Platform is configured with readily understood terminology Further reference:

Configuring Project Taxonomy

than “Defect”?

l Is the term “Sprint” or “Version” more

appropriate for the way we work?

l Have we considered external users and

their “project speak”?

l Does the platform need localized language

support?

Page 9

Planning an Enterprise-wide Issue Management Platform

Tune and Adapt Beyond the basics of issue management platform configured and adoption, use a common-sense fine tuning approach for enhancing the processes being managed by the platform.

Per Process Workflow - Above and beyond per project workflows, individual issue types may well require different workflows affecting how an issue moves through various stages. Figure 6 – “Defect” Workflow

Figure 7–”Change Request” Workflow

l Do we need to control workflow differently

per issue type (e.g. Do “Defects” flow differently from “Change Requests”)?

l Do we need to vary input data fields for

certain user types at certain stages (e.g. Testers can input additional data fields when editing “Defects”, but not during issue creation)?

l Do project team member roles constantly

vary per project leading to user permission management overhead (e.g. “Developers” change for most projects yet the required permissions remain the same)?

It is also advisable to avoid getting caught up in the trap of adopting the latest fashionable project management methodology without first considering organizational readiness and compatibility (as an example see suitability of Scrum).

Page 10

It is also beneficial to consider what types of users can change the status of an issue (e.g. only “Testers” may mark an issue as “Closed”). This does provide a further level of accountability as specific job roles are responsible for moving an issue through the lifecycle. Furthermore, consider the path that an issue may take as it moves through the lifecycle. www.countersoft.com © 2010 COUNTERSOFT LIMITED, ALL RIGHTS RESERVED.

Figure 8 –Determine issue lifecycle status flow

Planning an Enterprise-wide Issue Management Platform

Tune and Adapt It is often beneficial if a diagram of each workflow (e.g. Microsoft Visio) is agreed upon and then circulated to management/team leads to ensure everyone understands how work can progress through the platform.

Varying Data Field Capture By Role By Stage Consider the following diagram that was introduced earlier:

The key item is to ensure issues flow logically

Figure 9 Requesting the right data at the right touch point, per process

through a lifecycle that can be readily understood by all users, internal or external.

This model should be expanded upon to precisely control who can view/enter what information and when. For example, the following diagram clearly details the different on-screen prompts presented to the Developer and the Tester.

Page 11

Figure 10 Varying data inputs by job role, by touch point, per process

Planning an Enterprise-wide Issue Management Platform

About Countersoft Countersoft is all about enabling the collective capability that exists within all teams and projects Our products and services are used by start-ups, SMEs, Fortune 2000, government, educational bodies, not-for-profits and charities around the globe. From day one we have supported open source projects by donating product licenses to help them flourish. The award-winning Gemini is a leading .NET based project management platform that provides an effective browser-based project team experience regardless of roles, locations and project types. Key integrations with Microsoft Outlook, Microsoft Visual Studio, Subversion and other leading configuration management systems.

Page 12

Gemini won The Code Project Readers Choice Awards in 2009 and 2010 for Best Software Project Management product. Discounts for Government, Educational and Notfor-Profit organizations and Gemini is free for Open Source Projects. Everyone is entitled to a free 3 user license to get them going.

Further information links: - Project Management Platform - Scrum Project Management - Bug Tracking

Planning an Enterprise-wide Issue Management Platform

www.geminiplatform.com Versatile Project Management Software

www.collectivematters.com It’s about people and getting things done

www.atlasanswer.com The Product Support Ecosystem

www.projectpatterns.org Sharing Best Practice Project Templates