Implementing an Issue Management Platform for Software Development and Beyond

Planning an Enterprise-wide Issue Management Platform

Page 1

© 2010 COUNTERSOFT LIMITED, ALL RIGHTS RESERVED.

www.countersoft.com

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

Harvey Kandolahttp://twitter.com/HarveyKandola


Page 1


www.countersoft.com

l Introduction 2

l Understanding Projects and Participants 3-4

l Select Business Processes to Manage 5

l Data Requirements Affect Business Processes 6

l Data Requirements Affect Users 7

l Plan for External Participants 8

l Adopt Relevant Terminology 9

l Tune and Adapt 10

l About Countersoft 11

contents



www.countersoft.com Page 2

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

version of the truth” – no room for confusion is left if

all users adopt the same project platform.

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.”

The result of following this approach is an optimized issue management platform

that is aligned to the way that projects should be managed.




Understanding Projects and Participants

If projects and users are considered the lifeblood of a project management platform, then some time spent understanding the types of projects, the types of user, and how different projects relate to one another, will help to build a solid foundation.

Managing both Support and Development projects on the same platform will simplify the transfer of information from one to the other. The key is knowing how to map the information from Support 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”.

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

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

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

l Should all external entities share a common “Help Desk” project?

l Is there a “Help Desk” project per external entity?

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

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

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

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.

Figure 1 Controlled interactions between Support and Development projects




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”.

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.

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 (e.g. Testers, Developers, Support Team, Clients, Vendors).

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




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.

Business processes are grouped into Issue Type groups.

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

What you need to do is to:

l List internal and external processes to be managed.

l List projects to be managed.

l Logically group business processes.

l Map grouped business processes to projects.

Select Business Processes to Manage

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).

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.

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




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.

Each issue type has clearly defined input data fields

Figure 4 Identifying data fields required per issue type

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?

Data Requirements Affect Business Processes

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




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.

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

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).

Data Requirements Affect Users

Ask yourself:

l Is too much information presented on 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”)?

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.

Each issue type has defined input data fields per capture stage




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.

Some key questions that will help organizations plan accordingly:l How many outside organizations need to be involved?l Do external users require just help desk 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?l What organizational sensitive issues need to be considered?

Plan for External Participants

What you need to do is:

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.

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

content requires different tone, language or

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.

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.

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




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 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?

Adopt Relevant Terminology

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.

Platform is configured with readily understood terminology

What you need to do is:

l List the terms currently used.

l Tweak terms list with non-technical users.

Further reference: Configuring Project Taxonomy




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.

Tune and Adapt

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).

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.

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.

Figure 6 – “Defect” Workflow Figure 7–”Change Request” Workflow

Figure 8 –Determine issue lifecycle status flow




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.

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

Tune and Adapt

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.

The key item is to ensure issues flow logically

through a lifecycle that can be readily understood

by all users, internal or external.

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

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


www.countersoft.com


Page 12

About Countersoft

Further information links:

- Project Management Platform

- Scrum Project Management

- Bug Tracking

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.

Gemini won The Code Project Readers Choice Awards in 2009 and 2010 for Best Software Project Management product.

Discounts for Government, Educational and Not-for-Profit organizations and Gemini is free for Open Source Projects. Everyone is entitled to a free 3 user license to get them going.

Countersoft is all about enabling the collective capability that exists within all teams and projects



www.countersoft.com Page 13 © 2010 COUNTERSOFT LIMITED, ALL RIGHTS RESERVED.

www.geminiplatform.com Versatile Project Management Software

www.countersoft.com Enabling Collective Capability

www.atlasanswer.com The Product Support Ecosystem

www.projectpatterns.org Sharing Best Practice Project Templates

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

Documents

Implementing an Issue Management Platform for Software Development and Beyond