If you're an employed manager, you'll find them in your job description or contract and I'm sure your boss will concentrate on them at your next performance review. Outcomes are what you're paid to achieve.

Many business owners and managers allow themselves to be distracted and diverted from their outcomes. They get involved in all sorts of situations that take their "eye off ball."

I regularly run a workshop for managers called - "Managing Your Priorities." At start of workshop I ask managers to draw a map on a large sheet of flip chart paper of all things they do in their job. They almost inevitably fill that page with all sorts of tasks and activities. More often than not they surprise themselves with what's on page.

I then ask them to identify and mark with a large cross, their real priorities, and outcomes that they're ultimately judged on. Out of all tasks and activities on page they usually cross only five or six priorities and sometimes less. (You might want to try this exercise yourself sometime).

What we do find however is that priorities that they cross are not allocated time they deserve on a day to day basis. The managers will often blame their senior manager for many of tasks which divert them from their priorities, which is perfectly fair. However there are many tasks that a manager takes on because:

1.They don't like to say "no" or - 2.They don't trust anyone else to do it or - 3.They just 'like' to do it themselves.

I then spend time in workshop showing managers how to communicate with their senior manager and their other colleagues in order to minimise number of tasks that don't contribute to their outcomes.

Many managers fall into trap of believing that their manager will understand why they haven't hit their target or quota. They seem to think that because senior manager has handed out all sorts of other tasks, then they'll accept your failure to achieve your target.

Well let me tell you now - they won't!

Some business owners believe that their bank manager or investors will understand all reasons why they haven't achieved their business outcomes. However, as I'm sure you know, bank managers and investors only want to hear that you've achieved what you said you'd do.

The successful business owner or manager keeps very focussed on outcomes and doesn't allow anyone or anything to divert them without good reason.

An issue is an incident, circumstance, problem or inquiry that affects or potentially affects timely delivery of project, product or service, it may also impact quality of deliverables and cost of production.

Some projects are ongoing and definition of an issue is a little different. A help desk defines an issue as a request for help that requires a response. A service department keeps track of service requests as issues. A software maintenance group tracks reports of software bugs and enhancement requests as issues.

Because of impact issues have on a project, product development or ongoing service, issue management is an important aspect in any management methodology. This issue management methodology promises to make handling of issues a seamless part of your larger scoped methodologies rather than a process separate from them.

It is usually not hard for team members to identify issues, but it is still worth having a working definition of an issue. Remember that more ambitious your project more issues will arise.

Action item: The project team must be made aware of what issues are, provide some examples, and ask other team members to provide some examples.

2. Requirements

A central repository of issue information easily accessible to all team members, because it is good for team morale and productivity to know that their issues are being addressed. An automated central repository like Issue Tracker[http://Issue-Tracker.GLM2.com/] is desirable because it make issue management and reporting much easier.

Action item: Choose a central repository for your issues.

An issue manager is person chosen to oversee all issues. It can be project manager, team leader or another person in a responsible leadership position. The issue manager is responsible for making sure that there is consistent, disciplined and continuous progress made on all issues. The issue manager is accountable to upper management for progress made on all issues. The issue manager communicates issue progress to team, upper management and all stakeholders.

Action item: Appoint an Issue Manager and notify issue manager of their role and responsibilities.

This issue management methodology represents best practice for managing issues. However, goal is to have a successful project, product development or service, goal is not to follow a methodology fanatically.

Action item: Adapt methodology so your project's success is maximized.

3. Steps

3.1 Discovery

Issues can arise at any time. When an issue is discovered it is recorded in central repository.

It is important to allow issues to be recorded by a broad group of people including team members, upper management, users, customers, stakeholders, vendors and contractors. It is important because if there are barriers to reporting an issue then there is an increased chance that issue will go unrecorded. You cannot address issues that you do not know about. It is not necessary that everyone has access to central repository, but more you can allow better.

Action item: Set up access to central repository for those people that need it.

3.2 Recording

Training people to identify issues is often unnecessary, however getting people to record issue in central repository will take some training and encouragement. For example, a team member may mention an unrecorded issue to project manager during a coffee break or other informal occasion, this team member needs some encouragement to record such issues in central repository.

For all kinds of issues, prevention is better than correction. Also, issues tend to be less severe if they are addressed earlier rather than later. This means that every effort should be made to report issues as soon as they are discovered, instead of waiting for issue to become "serious enough" before recording it. Do not be afraid of duplicating an issue or overlapping with existing issues, it is better than missing an issue.

A complete description of cause of issue should be recorded in central repository. Resist temptation to describe issue in terms of a solution. Any implication of issue should be recorded. Attach any supporting documentation, screenshots, report output, faxes, error messages and other media that describes issue.

The person who is recording issue can make a recommendation for a solution, if they have one. This person should also assign issue if possible, even if it is only assigned to issue manager for re-assignment.

When an issue is initially recorded it should be recorded in central repository with a status code that reflects fact that it is new issue and has not been reviewed. An attempt should also be made to categorize and rank severity of issue.

The date and who created issue should be recorded in central repository. This is done automatically for you in systems like Issue Tracker[http://Issue-Tracker.GLM2.com/].

Many teams describe issues in terms of desired solution, leaving others to deduce actual issue. This is not best practice since it limits scope of possible creative solutions. As an example a badly worded issue: "We need more people." There is no indication in this example of what issue actually is, so finding alternative solutions is impossible. If example issue had been worded as "The shipping department has swamped us with product, there is a possibility of spoilage if we cannot get product delivered." With issue worded this way perhaps shipping department can become aware of how there actions are causing issues down line and adapt their actions.

3.3 Initial Review

The initial review is a triage of new issues. It is usually performed by issue manager or deputies who are familiar with scope and priorities of project. If team is small entire team can meet for review. For each new issue status, category and severity are reviewed and issue assigned to someone for action and optionally an owner is identified as follows.