This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Got Issues? - 30 Oct 2009

Improve Communications, Streamline Development with an
Issue Management System

By Auri Rahimzadeh

Whether you re a small business or a single, independent
contractor, one big problem with modern development is the lack of centralized
communication. Wading through e-mails with different specs, filing those away,
and communicating with all your client contacts is a time-consuming task. You can
often end up in the I don t remember you saying that conversation, putting your
relationship with the client at risk.

I ve been in that situation all too often, with no easy
way to see a history on tasks and the mound of piling issues that must be
resolved. My once omnipotent memory faded as the number of clients and my
business and development team grew. What I needed was a solution to make sure
my client was on the same page as me, and vice versa.

Enter Issue Management Systems

An Issue Management System s (IMS) sole purpose is to make
sure all the issues are on the table, everyone communicates and discusses
issues in one centralized location, and the process goes through a set process
flow. (Issue Management Systems are also known as Bug Tracking Software, Defect
Management Systems, and even Help Desk Software.) No more e-mail tag. The
process is simple:

1) The
client enters an issue in the IMS, with supporting documents and details.

2) The
IMS forces the issue to follow a set process flow.

3) All
discussions and decisions are made in the IMS.

4) The
issue gets resolved.

The process flow is likely what you ve heard explained
as a best practice, but is something that never can be implemented effectively
via e-mail:

3) The
development manager determines whether to defer back to the client or assign the
issue to a developer.

4) If
an issue gets past deferment (usually because clients are lazy and give you
one-sentence issues, which aren t good enough for solving the issue), the issue
is assigned to a developer.

5) The
developer marks the issue as In Development when they start it.

6) If
there are any questions, the developer, the development manager, or the client
can start or contribute to a discussion on the issue. No e-mails! WARNING: If
you re a development manager working with a team of developers, my general rule
of thumb is to never let your client talk directly to your developers unless
absolutely necessary. Instruct your developers to send all e-mailed requests
from clients directly to you, without any other action being taken. Of course,
there are shades of gray to this rule (especially with small shops or
independent contractors, where this rule may not apply).

7) When
changes have been completed, the developer sets the issue to Fixed and the IMS
automatically assigns the issue back to the development manager.

8) The
development manager assigns the issue to the client s or your team s own QA manager.

9) The
QA manager marks the issue as Tested, and the IMS automatically assigns the
issue back to the development manager.

10) Once
the product or fix is released in the code, the development manager marks the
issue as either Released or Closed, and archives the issue.

Figure 1: Entering an issue in
Bugzilla. Look at all those details! Priorities, who s involved with this
issue, status, to whom to assign the issue everything you need to make sure
you stay on top of the project. Imagine all the e-mails you must piece together
to get this information, if you ever get it at all.

Of course, your process flow may vary. Maybe you have project
managers involved, or the issue isn t one that was to be released in code, such
as a research task assigned to you after a status meeting. However, you as
the client contact can now run reports to see what s been fixed, by whom, when
you get the most bugs reported and by whom, and even weigh the development time
and productivity. As you really get rolling with the IMS, you can see how you re
effectively managing your projects and your team. It s also useful for your
client if they have underlings and you need to show their team isn t responding
to your team s requests. There s no way you can do that via e-mail e-mail
conversations are private and unaccountable.

FAQ #1: I m a
Single Consultant, Why Do I Need This?

Improving client communication is a must. The deluge of
insignificant e-mails I used to get from clients before the IMS was
overwhelming. This was especially true with their underlings. And they were all
little things, since e-mails are so easy to write. If the client has to log in
and put the issue out there, and their boss is going to see all the little
nit-picky things, they ll likely think twice about it. It s not that you don t
want to help, but you need to spend your time getting things done not getting
refinements to an issue five times per day via e-mail because the client
changed his or her mind. It s transparent accountability everyone knows
what s up, and that helps both you and your client get things done.

As for being a single consultant, if you grow your
business and I hope you do the IMS will scale with you.

FAQ #2: I m Not a
Contractor, I Manage Internal Projects!

You may not be external-client facing, but likely you must
report to someone inside your company. Even if it s yourself, you need to keep
tabs on what those people who work for you are doing, but without incessantly e-mailing
them for status reports. The IMS keeps everything on the table; no more I must
have missed that e-mail. Developers will see a dashboard of their issues,
with priorities, and will be forced to follow a good process flow. Figure 2
shows NetResults Tracker s Dashboard.

Figure 2: NetResults Tracker s
Dashboard feature. This shows what the QA manager would see upon log-in.
Developers would log in and see only their own tasks, plus any other reports
they need, such as tasks they created.

One big benefit to internal projects is that your
development team doesn t get hounded by you. You can see what people are
working on without sending them constant, annoying pings. You can see what s
assigned to who and the status of bugs, new features, and more all without
having to interrupt your development or QA team s Chi with annoying e-mails and
read receipts. This frees up a lot of time, so you can get your tasks done by
streamlining tremendous amounts of team management tasks.

Features You Need

Many of the available systems offer similar features, but
there are certain items you are going to need to make yourself, your team, and
your client more productive.

User Dashboard.
This is the first thing your developers and clients should see every day when
they log in to your IMS. It should be clear and concise, showing what issues
are assigned to them, and the status of all items they ve assigned to others.
It should be obvious if an item requires their attention. If you take a look at
Figure 2, you can see NetResults shows the user what s assigned to them and
what s being tested. NetResults also has a nice feature, not shown in the
figure, that shows when an item has new discussion thread messages.

E-mail Alerts.
When an item is assigned or status changes on an issue, the appropriate people
should be notified via e-mail. Your developers are going to spend most of their
time coding, not looking at their IMS dashboard. The same applies to your
clients they re off doing other things, not staring at their screens. E-mails
that say something s going on, and to go to the IMS to find out what after a
teaser subject, are a great way to keep them involved without deluging them with
details.

Great Details and
History. Every issue screen should display awesome amounts of detail about
the issue. This includes access to all related attachments, discussion thread
access, priority, status, who assigned it and their contact information, and
more. It should also show the history of the issue from inception, so you can
get a feel for whether this issue has been going back and forth between QA for
some time, or if it was just directly assigned to you by your development manager
without any client involvement. As you tour the various systems, you ll get a
feel for how much detail can be provided.

Different User
Levels. You should be able to assign users to different roles. Developer,
QA, development manager, QA manager, big boss, you name it. Having the various
roles lets you assign privileges in the IMS accordingly, as well as ensure that
you can communicate with the right groups instead of confusing people unrelated
to a particular task.

Process Flow.
The IMS must force the issue to go through a set process flow. This is
incredibly important. This must be as automatic as possible. For example, a development
manager should have the ability to assign to a developer or a QA manager, but
the developer should only have rights to assign an issue back to the development
manager. Indeed, you should make sure a developer should only be able to mark a
task as Fixed, while the client should only be allowed to assign tasks to a development
manager, not a developer directly to a developer. If you follow my flow from
earlier, you ll see how this works out. I m biased, because we use NetResults
Tracker, but I really like the way their system implements this functionality
(take the tour at http://www.nrtracker.com).

Customizable
Fields. The forms you fill out for creating issues may be just fine, but,
then again, you may need some that aren t included. The IMS you choose should
be customizable enough that you can modify it to suit your needs. Make sure you
feel around a lot, even get your team involved, and maybe even get your client
involved although I would hesitate a bit on that last one. An issue we encountered
was a client who wanted a field for Requested Completion Date. Yeah, I know
that s generally bad, but sometimes it s unavoidable. So I told them I can put
it in, but not as a required field, and that it may not be honored. They were
fine with that approach. They hardly use it, but they are happy we could modify
the IMS to do it and your clients will probably have similar requests.

Reporting.
After you use the IMS for a few months, you ll have built up quite a database
of issues. After a certain amount of time, you should start running reports to
see how many issues you have in a month, and how long it usually takes you to
solve issues. This can be skewed, of course, because some issues seem easy at
first, then take weeks to solve. However, you can get a good feel for how your
team is doing, and how your product is progressing, quality-wise, if you keep
tabs on the historical data. Knowing how your team is performing on different
projects, and overall, will help you tweak it. Even if it s just you, you can
see where you may need improvement, or possibly if you need additional help.

Easy for Client to
Understand. Last, but definitely not least, make sure your client can
understand the system. If you don t understand it, your client likely won t,
either. Make sure everything isn t too technical-looking, and that
functionality is obvious. Remember, as you get in to larger projects, you ll
involve non-technical project managers, marketing teams, and others. As your
client uses your IMS to communicate amongst themselves, issues may be created
that don t even involve you. This is a good thing, but it s hard to make it all
happen if you need to know Visual Basic or HTML or archaic technical details to
use the system.

Free or Pay?

As with any solution these days, there are both commercial
and free solutions out there. Each has their benefits and detriments. I ll
mention a few, but my list, and my comments, will in no way be all-encompassing.

You must decide how you want to host your system. Most
commercial services have a per-month fee for hosting the IMS for you, which can
save you money in the short term, but cost more over the long haul. Of course,
not having to purchase and maintain a server is a benefit in itself. For a
small business or independent contractor, your best bet is to get something you
don t have to host yourself. It s simply cheaper to maintain something for
which you don t have to buy a server. Plus, they re responsible if anything
goes wrong.

The one we use at TAG
is NetResults Tracker, http://www.nrtracker.com.
I chose it because it supports configurable process flows, it s easy to use and
manage, and they can host the site with a custom log-in screen bearing our logo
and charge us on a per-user basis. I ve generally had great feedback from my
clients using this system, and their prices are reasonable for the money I save
keeping my clients needs organized.

One I haven t used much, but looks really great, is
FogBugz (http://www.fogbugz.com), from
industry veteran Joel Spolsky s company, Fog Creek Software. Their interface is
much sleeker than NetResults, and knowing Joel s blog, http://joelonsoftware.com, and his
excellent book Joel on Software, it
looks both developer- and client-focused.

One popular free solution is Bugzilla, http://www.bugzilla.org, from your friends
at the Mozilla Foundation. Bugzilla has been used to manage the development
process for popular products like Firefox and Thunderbird, and more. The
product has definitely been put through its paces and has been incrementally
improved, as necessary.

I ve left off my list more expensive solutions because
this article targets independent contractors and small businesses and their
budgets. I ve also found the less-expensive software from smaller companies is
generally more bug-free and robust. This isn t true of all software, of course,
but it appears true in this class of software.

Do I Bill Them?

Determining whether to bill your client for IMS use can be
tricky. When you need to create accounts for your client, which is obviously
necessary, pass through that cost if possible. If not, the IMS will save you so
much time and energy that it may be a cost you simply write off.

Gently Force Your Customer s Hand

Your customer may be a bit resistant to using the IMS.
After all, they re probably accustomed to simply e-mailing you to get things
done. Explain to your client that you ve put an IMS in place to streamline
communication and make sure things are getting done more quickly and
efficiently. Make sure you re familiar with the system first, then give a
tutorial to your client yourself. It is incredibly important that you
understand your IMS and how it works before you introduce it to your client!
Use your IMS internally, get used to it, then you ll be ready to explain its
use and benefits to your clients.

After your client has been switched to the IMS, you must
take the tack that if it s not in the IMS, it won t get done. If your client
has minions, their big cheese may love this idea. It takes a few weeks for the
client to get used to this, but they ll see the benefits as they get to be part
of the development process instead of simply trusting the black box labeled
Development House.

Moving Forward

Introducing an IMS into your development process can reap
many benefits and streamline your communication and improve your relationship
with your client. Do a lot of window shopping, but also go in and explore these
systems for yourself. Force yourself into the process-oriented way of handling
issues and you ll find your performance and quality will increase.

Auri
Rahimzadeh is President and Senior Engineer at TAG
(The Auri Group, LLC, http://www.aurigroup.com),
a Microsoft Gold Certified Partner based in Indianapolis,
IN. Rahimzadeh has authored three books, including Hacking the PSP and Geek My Ride.
He has been technical editor on Wrox and Wiley titles, and has written a number
of technical articles ranging from .NET
development to consumer electronics. Auri started his technology career working
for Steve Wozniak, co-founder of Apple Computer, and enjoys writing and
teaching others about all sorts of technology.