Skip navigation

Got Issues? - 30 Oct 2009

Improve Communications, Streamline Development with an Issue Management System

Consultant s Corner

 

Got Issues?

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:

1)     The client creates an issue (see Figure 1, entering an issue in Bugzilla).

2)     The issue gets assigned to a development manager.

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.

 

If you have any questions, please feel free to contact me at [email protected]!

 

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.

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish