Jira’s an issue tracking application, but its core flexibility and strengths mean it can become much more than a tool limited to a development group. Jira’s incredibly adept at helping teams track and accomplish tasks. Jira also has a masterful ability to manage life cycles - and it’s found great success in numerous use cases.

Use Cases

The following use case guides are meant to explain a bit of the details related to using Jira for a specific use case. The info you’ll find in here highlights much of what we’ve learned from working with clients in a variety of different industries, as well as our internal expertise and use of Jira.

For each of these use cases, we’ll attempt to highlight:

• Particular Jira functionality specific to the use
• Related plugins we’re aware of
• Customization and tweaks
• …and sometimes a sample file to help get you started

Agile Software Development

• Agile Development Solution Tour
• Using Jira for Agile Development

Project Management

• Using Jira for Project Management
• Jira for Project Management sample file

HelpDesk / Support / Trouble Ticketing

• How to setup Jira for support
• Use case and sample file: Jira for Helpdesk/Support Sample File

Test Case Management

This can be done by using either of the following approaches:

• Use case and sample file: Integrate Jira With A Test Case Management Tool

Requirements Management

• Use case: Using Jira for Requirements Management

Change Management

• Use case: Using Jira for Change Management

The Agile school of software development’s currently one of the most accepted methodologies for improving productivity. Targeted mainly towards IT managers and CIOs, Agile methods promote an interactive approach which have the ability to help flatten your organization’s cost of change curve.

The Manifesto for Agile Software Development was first introduced in 2001, and outlines the foundation of Agile in twelve principles:

1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Working software is the principal measure of progress
5. Sustainable development, able to maintain a constant pace
6. Close, daily co-operation between business people and developers
7. Face-to-face conversation is the best form of communication (co-location)
8. Projects are built around motivated individuals, who should be trusted
9. Continuous attention to technical excellence and good design
10. Simplicity- the art of maximizing the amount of work not done- is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstances

Cost of Change Curve

First introduced by Barry Bohem in 1981, the cost of change curve represents the exponential increase in cost as it relates to making a change during the normal development phase of a product. This means that as your product moves farther down the developmental pipeline it becomes more costly to make changes and remedy errors.

That’s a good argument for Agile since it ensures you leave the current production phase with a product that’s as close to perfect as you can make it – particularly because Agile methodology calls for testing and up-front integration which translates to rapid production and minimal initial design. Since the test code’s written before functional code and automated test suites are built around the evolving code, developers are allowed to make rapid and aggressive changes.

The ability to make these changes is one of Agile’s key features and the result is a reduction in the amount of product errors late in the development phase, reducing the cost of change. Even if your organization enjoys a rather flat cost of change curve, Agile ideals can be applied to reduce the cost of change throughout the software life cycle.

Scrum

Scrum’s another widely accepted approach to implementing the Agile philosophy, which includes both managerial and development processes. This approach relies on a self-organizing, cross-functional team supported by a scrummaster and a product owner. Scrum makes your organization Agile by ensuring quick progress, continuously creating value, and by keeping projects on track. The most important concepts of Scrum are:

• Product backlog - A complete list of requirements that are not currently in the product release. Typical backlog items include bugs and usability/performance improvements.
• CI - Also known as continuous integration; allows for scrum teams to continuously integrate their work. This will often happen on a daily basis.
• User story – Describes problems that should be solved by the system being built.
• Scrummaster - The manager of the Scrum project.
• Burndown chart - The amount of work remaining within a sprint, i’s updated daily, and also tracks progress.
• Sprint backlog - A list of backlog items assigned to a sprint, but not yet completed

Kanban

Kanban means visual board – and that’s just what it is, a development process that revolves around a board to manage works in progress (WIP). A Kanban board includes “lanes,” each denoting different phases a project might take. It moves WIPs across the board and deploys them into production when they reach the done column. Since Kanban development practice revolves around WIP management each state of progress is limited to a set number of projects. Organizations able to leverage this high frequency of delivery typically enjoy a large financial benefit.  The most important concepts of Kanban are:

• Swim lanes - The horizontal lanes of a Kanban board represent the different states in which a WIP or task can exist.
• Backlog - A list of backlog items awaiting deployment, but not yet completed.
• Stories – A particular user need assigned to a development team.
  
  

Atlassian Jira's a remarkably flexible tool. For most who hear “Jira,” things like issue tracking, project management, and software development come to mind. Very rarely do people think of ITIL in relation to Jira. But then again, many don’t know what ITIL is.

If you’re a developer or in IT and don’t know what ITIL is, you should. It’s a set of processes for managing lifecycles with relationships to one another. It’s the most widely-accepted approach to IT service management in the world – a set of best practices drawn from public and private sectors around the world. ITIL doesn’t just apply to IT service management (ITSM), though – it’s a reliable methodology for managing any type of complex technological process.

Jira’s an Atlassian tool that’s phenomenal at lifecycle management (workflows, custom fields, etc). It’s designed to be issue-centric, built around managing issues or bugs that pop up within a product or service’s lifecycle. This functionality extends far and wide when you expand how you define an “issue.” On the surface, an issue is more like a problem – but considering an issue’s attributes, it can easily qualify as a task or milestone. With that in mind, Jira can facilitate far more than simple issue tracking. It can support complex process lifecycles.

Every process is a web of highly dependent relationships between regular and conditional tasks – including ITIL processes like Incident Management and Problem Management. The huge breakthrough here is making Jira projects and workflows represent (and support) ITIL processes. Let’s take an incident for example. An incident goes through several states:

(1) detection and recording
(2) classification and initial support
(3) investigation and diagnosis
(4) incident closure

A good Incident Management process within a good technology helps reduce meantime to recovery – i.e. recover from an incident. We all know how well Jira facilitates transitions and workflow. Let’s take it a step further…in ITIL-based Incident Management, we are supposed to designate incident ownership, actively monitor, track and communicate. BINGO! This what Jira does.

Let’s take this another step further. Problem Management is a process used to identify root cause to reduce the number of incidents – thereby increasing the meantime between failures. Using Jira, we can manage root cause analysis and associate the individual incidents (manifestations) back to the Problem Management record we’re analyzing. This ability to link records and collaborate makes Jira a great Problem Management solution. Add Confluence to the mix and the effectiveness is improved further.

Going another step further – having ITIL-based ITSM processes running in Jira alongside your organizations SDLC further helps IT align its capabilities to deliver the highest, best quality software and service delivery.

We’ve helped clients implement Jira to manage Incident Management, Change Management, Problem Management, Asset Management, Software Development, Testing… we love the Altassian products and so do our clients.

We’re having a blast at Chattanooga’s SmartGrid Roadshow this week. The show’s been a host to hundreds of industry-changing intelligence that will lead electric utilities into the next generation of energy. We’re here collaborating with other energy market technology leaders about how utilities can re-engineer their business processes to support grid digitization and more customer empowerment.

A key part of this is the role of open source in SmartGrid technology – and questions about how it will be leveraged within new industry standards for application development, infrastructure, platforms, etc (check out TVA’s code library, an open source project for Phasor Data Concentrators (PDC), for a taste).

In a world where climate change is already active (yes, it is), SmartGrid technology – which is already the direction of the energy industry – will shepherd us into an era of change. We’re excited to help utilities prepare to evolve. Thanks again to the folks who put together the Roadshow as a summit for new ideas.

If you’re a large enterprise, you may be using different applications and processes to support local, national, and global initiatives. On those different levels, separate applications may be needed to manage unique sales, marketing, or IT processes.

The difference in processes, methodologies, and application tools may lead to inefficiencies in management, such as:

1. Higher cost of managing multiple applications
2. Lack of consistent governing structure
3. Inconsistent or incomplete performance measurements

A typical enterprise cannot usually leverage one application for sales, marketing, and IT purposes. Using multiple applications to manage different internal and customer-related processes is in most cases necessary to ensure efficiency and quality customer service. The problem, therefore, is not that the enterprise has too many applications to manage – but that the enterprise cannot effectively manage all of them without some sort of centralized documentation of each application’s attributes and processes.

Without a central location for application-based data, data gets stored at seemingly random locations throughout the enterprise’s storage and resource structure. While process and metric information about an enterprise’s European sales resides on one server, information about their European customer support system may reside somewhere else. This stratification and distance between processes can cause a number of problems in terms of efficiency:

• Difficult to apply Change Management to all enterprise applications
• Difficult to access application information at any given point
• Difficult to measure the efficiency of each application to ensure quality performance
• Difficult to identify and diagnose problems in a timely manner
• Difficult to understand how different business processes affect one another

This explains the need for a Centralized Process Repository. As we noted in our previous post, a Centralized Process Repository (CPR) is critical to the success of the enterprise’s process strategy. It stores the following information about each of the enterprise’s applications at the process level:

1. Resources required (software, equipment, personnel)
2. Cost (direct and indirect)
3. Owners and stakeholders
4. Applications enabled by the process
5. Separate processes effected or supported by the process
6. Data points that measure the process’ value to the organization
7. Frequency of execution
8. Details regarding how the processes is carried out

The enterprise may not be able to consolidate their applications into one larger application. They may also be unable to devote time to improving each one individually. Adopting a CPR, however, establishes a consistent framework for governing each application by consolidating all process data into one accessible location – requiring any change to a process to be documented by a governing entity. This ensures the accurate measurement of process performance, since performance data points and change updates are stored in one reliable location.

The CPR improves an enterprise’s process performance by maintaining the information needed to measure, improve, and control business processes. We emphasize this to our clients to ensure their success as an efficient enterprise. In addition, the CPR promotes an understanding of the cross-functional nature of the enterprise’s processes – encouraging cross-departmental collaboration by focusing on the relationships between internal processes, end-to-end.

Thirsty for more? Contact us here.

Image courtesy of Patrick Lane Photography.

In order to remain competitive, a firm’s IT environment must be aligned with the firm’s business strategy – meaning IT should share responsibility in delivering value to the customer.

This is why Change Management is so important: changes to the IT environment must not disrupt the value delivered to the customer. IT must maintain stability even during change. ITIL’s Change Management methodology provides a clear framework (with defined roles, responsibilities, and processes) that can facilitate success.

Change Management should be considered a major undertaking. Determining where your firm stands in terms of ITIL maturity and developing a realistic project plan will improve your ITIL effectiveness.

Here are 5 Change Management tips to consider:

1. What’s a change, exactly?
Reality check: changes happen all the time. Nearly everything in IT involves some sort of frequent change. That being said, it’s important to figure out just what you consider to be a change. You can then determine when to apply ITIL Change Management principles.

Every change (even small installations and deletions) should be handled in terms of Change Management. The smallest of changes could cause major disruptions if no one knows about them.

2. What, specifically, will Change Management accomplish for my organization?
It’s no surprise that some firms have trouble defining ITIL in general. Since ITIL methodology isn’t something you can learn on a coffee break, most IT and non-IT folks alike don’t have the time to study ITIL for days.

Even if someone understands ITIL, they may not understand how it applies to efficiency. Someone might think implementing Change Management will fix issues related to Release or Incident Management. Pinpointing what Change Management will accomplish for your organization is therefore vital to understanding what it’s actually doing – managing the oversight and approval aspects of the change process in a unique organization-specific environment.

3. Articulate the benefits of Change Management to each level of the organization.
This goes right along with our last tip. Once you pinpoint the applicative benefits Change Management will have for your organization, advertise them. Getting buy-in at every level of the organization is critical to the success of your ITIL implementation.

There are multiple stakeholder groups within every organization – that is, folks personally and organizationally affected by the change. They’ll want to know “what’s in it for me?” in order to judge whether they’re on board with the change. Presenting accurate change information tailored for each stakeholder fosters better accountability from stakeholder groups – and improves buy-in.

4. Don’t Buy a Tool Until You’ve Determined What You Need.
While it may make sense to buy software to guide your Change Management implementation, doing so before laying out your process framework is counter-productive.

A more productive approach includes determining your needs before adopting a tool, so you can better evaluate which tools fit your needs instead of adjusting your needs to your tool.

5. Use Change Management Success to Promote Other ITIL Initiatives.
Folks are usually familiar with the Change Management component of ITIL – and oblivious of its other processes. If you track your Change Management successes and gather supportive data from Key Performance Indicators (KPIs), you can use success stories to promote the benefits of other ITIL processes like Release Management, Incident Management, etc.

One final tip: It’s worth noting the incredible value and need for leadership/executive support in the Change Management process. It’s important for company leadership to sell and support the change despite resistance in the company to organizational and cultural change. Often times, Change Management implementations are resisted since they uncover underlying issues that some within the company don’t want to uncover. Ultimately, though, Change Management helps make everyone proactive and out of the reactive, fire-fighting mode.

Thirsty for more? Contact us here.

Image courtesy of Patrick Lane Photography.

According to Forrester’s latest research, IT spending is expected to grow 6.6 percent in 2010 to $568 billion. In order to realize the value of these investments, organizations may adopt industry-consistent frameworks like ITIL to improve IT process and establish reliable data points to measure success.

Here are 5 useful ITIL implementation tips:

1. ITIL is an IT-Wide Strategy
Any ITIL process implementation has IT-wide impacts. Because of this, the implementation must be aligned with other IT initiatives within the organization, focusing on accomplishing ITIL success while preserving the overall benefit to the organization. ITIL should guide all strategic initiatives.

2. Consider Post-ITIL Organization Before Jumping Into Implementation
Introducing ITIL processes creates new tasks and roles that could impact an organization’s current IT service management structure. Foreseeing this possibility helps guide management toward supporting a new IT organization.

3. Prioritize Process Selection
Implementing every ITIL process at the same time isn’t necessary. ITIL processes should be selected based on areas where the organization needs improvement, and areas that will drive the most business value/greatest ROI.

4. Set Your Baseline Early; Have Realistic Expectations
The acceptance of change, of course, takes time. ITIL’s implementation is a significant change to an organization’s IT environment, and its processes will have to mature before subsequent ROIs are recognized. The delay of ROI-producing data points will delay the qualified legitimacy of the ITIL venture—making the change harder for employees to swallow.

Establishing an early baseline of key performance indicators (KPIs) from which to monitor ITIL success helps employees be more open to and engaged with the change. Chosen KPIs should be business-focused and clearly understood, so employees don’t waste time measuring unnecessary data points.

5. Communicate, Communicate, Communicate Success
Let’s face it: implementing ITIL isn’t a quick job. The longer a project takes, the harder it is for employees to see its worth.

This is why communicating success to everyone involved in the implementation is essential—so employees are reminded they’re working toward something that will make them more efficient and profitable, and prepared for change. Success not only boosts morale. It qualifies and legitimizes the project. Failure to communicate success may double employee resistance to change over time.

Thirsty for more? Contact us here.

Image courtesy of Patrick Lane Photography.

ITIL’s Release Management process bears a striking resemblance to ITIL Change Management—in fact, one could fairly consider Release Management to be a directly supportive process to Change Management. Release Management focuses on the practical need for organized coordination in the change process. It’s meant to ensure that changes are implemented in accordance to business needs and concurrent IT Service Management processes.

Release Management more specifically applies to changes to a “live” environment—that is, a working software or hardware environment (a word processor, email interface, software application, etc) that’s active, being used internally or externally. Release management protects these live environments by regulating the release of new configuration items; it uses the ITIL framework to control and monitor the flow of upgrades into live environments, where each upgrade is considered a “release.”

To more clearly illustrate this concept, consider these three levels of releases to a live environment—using the fictional email service “Mockingbird Version 1.0″ as an example:

• Major Releases introduce completely new functions to a service, drastically improving the service’s capabilities. Major Releases advance the version number by a full numerical increment—for example, Mockingbird Version 1.0 advances to Mockingbird Version 2.0.
• Minor Releases introduce fixes for known problems into the baseline technology of a service. Such changes would reflect themselves numerically by advancing the version number of a service by the first decimal place—for example, Mockingbird Version 2.0 advances to Mockingbird Version 2.1.
• Emergency Releases introduce quick (and at least temporary) fixes to repair unexpected problems that interrupt critical services. These changes advance a version number by the second decimal place—for example, Mockingbird Version 2.1 advances to Mockingbird Version 2.1.1.

It’s best to consider each release as a separately-deployed part of the service, the progression of which should look like this:

• Planning
• Building
• Testing
• Deploying

ITIL clearly describes two “levels” of Release Management in its book:

• Service Design (higher level)
• Release and Deployment Management (lower level)

The Service Design level should handle the framing and building of the release solution, while ITIL suggests the release project stages listed above should be handled by the lower level and should involve a project team, scope, design, and plan of its own. The Release and Deployment Management level literally drives the solution’s release, but only because of the sound development and planning by the higher level—meaning it is almost impossible to achieve lower level success without a solid understanding of the higher level.

We hope this blog provides you with a basic overview of Release Management. It’s sometimes difficult to explain ITIL concepts without using laymen’s terms– from our experience consulting companies on their use of ITIL, a basic overview is an essential foundation for understanding the application of ITIL principles into your business.

Would you like more from us? Contact us here.

As with any aspect of business, great processes and infrastructure do not always stay great—new technologies and customer needs arise all the time, and usually require changes to business procedures. The same is true in the context of IT Service Management, as new IT needs and technologies inevitably arise as time goes by—creating the need for the ITIL discipline of “Change Management.”

ITIL defines the goal of Change Management in the context of IT Service Management as “to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.” If the ITIL language sounds a bit daunting to you, the definition more basically means Change Management is meant to ensure standardized methods and processes are used to implement all changes in a timely manner, and to achieve and maintain a healthy balance between the need for change and the potential impacts changes might have on the business processes they affect—ie predictability. Every change to IT infrastructure must of course be managed and controlled systematically, minimizing the impact of IT services delivered to the customer.

The need to change IT infrastructure may result from problems observed in a business process or from external legislation—or merely from the desire to make a business process more efficient and productive. Once a need is identified and proven, a change may be developed. ITIL’s discipline becomes valuable at this point as a change becomes drafted, documented, and implemented.

ITIL V3 prescribes these seven questions to ask when proposing the implementation of a change—titled the Seven “R’s:”

• Who raised the change?
• What is the reason for the change?
• What is the return required from the change?
• What are the risks involved in the change?
• What resources are required to deliver the change?
• Who is responsible for the build, test and implementation of the change?
• What is the relationship between this change and other changes?

Other relevant questions to ask when proposing a change may be:

• What is the cost of the change?
• What is the timeline for implementing the change?

The leadership team at Praecipio Consulting consists of experts whose job is to implement change for companies based on ITIL. We have helped our clients implement valuable changes to their IT infrastructure, and have a great deal of familiarity with defining good and bad processes by leveraging ITIL best practices. Change Management provides a way of managing and controlling the way changes are initiated, assessed, planned for, scheduled and implemented—Praecipio Consulting offers you the intelligence and support you need to not only guide you through implementing IT Service Management Changes, but also to provide you with a proven model and valuable business direction for a future of changes.

Would you like more from us? Contact us here.

It is awe-inspiring to consider the vast number of software applications that attempt to make business organization simple and efficient. In issue tracking and business process management, organizational, process-driven technology is crucial to successfully processing information and facilitating progress. Atlassian, an Australian-headquartered software company specializing in collaboration software, has produced a widely-used software that makes the issue tracking process work more simply than ever before.

The software, Jira, currently serves over 12,000 customers in over 100 countries. An issue-tracking system (ITS), Jira allows enterprises to record and monitor every issue a user identifies until the issue is resolved—issues ranging from simple customer questions to detailed technical reports of errors or bugs.

We have acquired sound and valuable knowledge of Jira’s user and process benefits from our own experience amassed through client implementations of the product—highlighted here:

• Highly customizable to unique business processes
• Amazingly simple to use and easy to train employees
• Completely permission-based (people may view statuses of issues without the capability to change them)
• Completely web-based
• Java-based (runs in Tomcat, and is compatible with most Operating Systems)
• Flexible database (supports Oracle, Postgres, etc)
• Task change email notifications

These perks boil down to a centralized view of a business’ entire team. Jira makes it easy to view and track all tasks assigned to a person, group, or project with very few clicks—allowing non-technical users to benefit from it. Businesses can tailor Jira to make it useful for nearly every imaginable business process, from marketing tasks to help desk requests.

Adopting appropriate software for our clients’ business processes is what we do at Praecipio Consulting. Atlassian, our business partner, has developed and produced a magnificent product in Jira that we recommend highly for streamlining our clients’ BPM and ITIL implementations. Our implementations of Jira have a lasting, positive impact because of our focus on business processes.

Would you like more from us? Contact us here.

The Information Technology Infrastructure Library (ITIL) is currently the best (and only) comprehensive documentation of IT Service Management best practices.

The library is made up of a series of books which thoroughly explain (in really, really big laymen’s terms) what quality IT services should look like. The books describe how IT services should operate—as well as what base structure and functionality an organization needs to be able to effectively support IT.

Thousands of companies around the world have adopted an ITIL philosophy from the library, which clearly defines the organizational structure and skills requirements for an IT organization. ITIL theory works. The library’s standard operational management procedures and practices allow the organization to effectively manage an IT operation. The operational procedures and practices apply to all aspects within the IT Infrastructure.

The major disciplines (main focuses applicable to IT service providers) of ITIL are as follows:

• Service Desk (Help Desk)
• Incident Management
• Problem Management
• Change Management
• Release Management (Software Control and Distribution)
• Configuration Management
• Service Level Management
• Capacity Management
• Continuity Management (Contingency Planning)
• Availability Management
• Financial Management (Cost Management for IT Services)

While these terms are probably familiar to most ITIL personnel, the formal explanation ITIL gives these disciplines is typically far beyond the level of sophistication in the majority of IT organizations. Additionally, the specificities and separation of IT tasks within each of these ITIL support disciplines are considerably more defined than those which most companies have implemented in the past. The distinction between “incidents” and “problems,” for example, is something companies still do not usually recognize—whereas ITIL clearly defines the two terms as separate disciplines with their own unique set of processes.

An incident is active only until service is restored; a problem continues to be active until appropriate outputs/remedies are created and implemented. Incidents and problems are therefore not synonymous—instead incidents, problems, and changes have thorough relations with each other.

The “library” itself continues to evolve. ITILv3, the library’s third edition, was released in May 2007 and includes five distinct volumes: ITIL Service Strategy, ITIL Service Design, ITIL Service Transition, ITIL Service Operation, and ITIL Continual Service Improvement. The volumes can be purchased from their publisher, TSO Books.

ITIL is a framework. Praecipio Consulting has qualified ITIL-certified consultants with the experience, intelligence, and innovative ability to help your company implement ITIL confidently and effectively. Understanding ITIL can be difficult; if this is the first content you’re reading about it, you’ll probably agree. We wish to implement ITIL in a manner that makes the most sense for our clients’ business models. As the de facto standard and model for IT Service Management, ITIL not only enables businesses to run more efficiently and reliably—it also helps IT managers reduce incurred costs associated with IT Service Delivery.

If you’re curious, ITIL was originally created by the Central Computer and Telecommunications Agency (CCTA) with the sponsorship of the British government, and is a registered trademark of the UK Government’s Office of Government Commerce (usually known as the OGC).

Would you like more from us? Contact us here.