|
|
|
ASPonline.com >
ASP Forum
|
ASP Forum
Bug Fix Promises?
A member asks: "My support team would like to give customers a firm date
when a new bug will be fixed. However, our developers say they can't make
promises and may decide that some bugs just aren't worth fixing. How can
we persuade them to be more responsive?"
—Ethel from Elmira
Dear Ethel,
Several people offered advice on this question:
"At its core, this is a management problem. As hard as the customer
service (front-line) personnel and supervisors try to establish
"relationships" with development, this only occurs on an individual
basis. What is required is an over-arching management process that
ensures consistency in delivering service to the customer.
"The first thing that needs to occur is for senior management of
Operations/Service and Engineering/Development to agree that it is
important to be able to set customer expectations relative to bug
fixes. Once this agreement has been established then they need to
co-sponsor a project to create a process for managing bug fixes.
The co-sponsors need to elect a change agent/project leader, and a
team made up of as few people as possible that are subject-matter-experts
from Operations and Development.
"The scope of this project would include, but not necessarily be
limited to:
- How bugs are logged by the service organization
(what information is
required, where is it logged, etc.)
- How the priority/severity is set by the service
organization (based on
customer/revenue impact)
- How bugs are "handed off" to the development
organization (depends
on severity/priority of bug)
- Establishing service level agreements as to how
promptly development
will provide a "commit date" (again, based on
severity/priority)
- Defining management reporting to track the
performance of the
development organization at fixing bugs
"Finally, it must be realized by the service organization that:
- Where there is software there are bugs. Customers
understand this too.
They simply want bugs to occur infrequently and
when bugs do occur they
want to have their expectations set and met,
and the assurance that the
software provider is continuously improving
its practices to minimize the
occurrences of bugs.
- Not all bugs will be fixed. Each bug requires some
level of investment. To
the extent that the service organization
demonstrates customer/revenue
impact the more likely that the bug
will be fixed.
"The above process can be defined and put in place within 30-45 days,
"if" the senior managers of the organization are committed to resolving
this SERIOUS customer satisfaction and retention issue."
—Craig Bailey craigbailey@adelphia.net
Customer Centricity www.customercentricity.biz
603/491-7948
"This problem is common to us all. It is always a struggle. All I can tell
you is that for most problems in this area, you must have an open line of
communications going both ways between the Developers and the Support
group. This begins with a thorough understanding of the delivery systems
used to provide the bug fixes and the timeline of the current development
cycle. Also of importance is that the Developers must understand the
importance of the fix to the Support group and client. Part of this is the
role of the support person to fight for the client. It is their job to make
the developers aware of the importance.
"In our organization we have found that if the support team understands how
a bug fix is generated (depending upon deliver systems, giving a patch or
a .dll file) and gets an appreciation for the time and cost involved in
fixing a bug, they can relate better to the developer and the client. The
support team also must be aware of where the development cycle is at that
moment. It may be impractical to fix a bug, 2 weeks from the release date
of the next version. It may be expensive to fix a bug during a major
design initiative. The support person can then either buffer expectations
of the client or commit to a time frame depending upon the seriousness of
the bug.
"The inability of a developer to commit to a time frame is a fallacy. Yes
there are costs and issues associated with correcting bugs. But I am
assuming you are committed, like we are here, to deliver value to our
customers. This means you must have the process in place to rank and/or
characterize the severity of a bug. Also, that you are prepared to correct
problems in a reasonable time frame. This may mean next version, next
release, next month or next week. The developer knows the release schedule
and can estimate the time required to fix a bug. So, the developer has an
idea of the time frame, your support person can establish the severity, so
you can give the client a reasonable time frame to resolve the problem.
"Lastly, I agree in general with the statement that there may be bugs that
are not worth fixing, especially when you are changing/improving things in
the next version. Not worth fixing to who? This bug may mean the difference
in a big sale; the non-renewal of the maintenance contract; the correctness
of a result. Even an annoying little bug can mean the non-acceptance of the
product over a corporation. Not worth fixing? There are times when the
developer should give that a long thought.
"In the end it is all about balance, the balance between the business's
needs and the client's needs. With good communication and commitment, you
can balance the business reality with the customer expectations and still
deliver value to your clients."
—Tom Cutherbertson tom.cuthbertson@geosoft.com
Geosoft www.geosoft.com
416/369-0111
"I would recommend that support organizations find opportunities to
become more closely integrated with development and with the product
release cycle. While it is true that pinning down a date for a bug fix
can be difficult, if the support organization and developers have close
communication on customer needs, "persuasion" becomes less of an issue.
"It is important for Support representatives to participate in ongoing
development meetings where bugs, new features, and new releases are
being discussed. This allows them to contribute to prioritization of
issues and also give pertinent customer feedback on key issues. They
gradually become part process vs being an outsider needing to do a lot
of persuading. Proactively providing trend reports and customer data to
development would also help in their participation in the process.
"The initiative of dev-to-TS integration may require buy-in and support
from senior managers in development if that is warranted given the
current dynamic between the support organization and development.
Additionally, it may go through a process of evolving over time.
Ultimately, tech support has to be seen as a key component in the
product development process for customer needs to be adequately
addressed.
"This should probably be less of a debate about what date the fix can be
delivered and more of a discussion on how best to address customer
needs, given the trends observed by Technical Support. If TS and
development are on the same side, chances are they would successfully
work toward delivering the best solution to the customer in as short a
time as possible."
—Allison Babb babb@mathworks.com
MathWorks www.mathworks.com
508/647-7302
"The support center that I am currently in charge of had the same issue you
are inquiring about. In fact, you'll find that most support centers deal
with or have dealt with such an issue.
"What I did to minimize this issue and build a better relationship with
development was to implement a Service Level Agreement between support and
development. The SLA outlines the process for reporting bugs, prioritizing
bugs, and the service levels that development would adhere to. While the
time commitments were not specific dates they are timeframes that
development would work to achieve. An example: if a bug receives a priority
2 rating then the fix should be available within 30 days. That does not
guarantee the bug will be fixed and available in 30 days but it does mean
that on average priority 2 bugs are completed within 30 days. That at least
gives you something to go back to the customer with.
"Who assigns the priority you might ask. Well, we hold regular "quality"
meetings that include representation from support, development, quality
assurance, and professional services. In this meeting we discuss all new
bugs since the last meeting and review progress on existing, open bugs. If
critical, priority 1 bugs occur that cannot wait until the next quality
meeting an email outlining the issue is circulated to all quality team
members for rating confirmation. The bug can then be assigned in development
without waiting for the next meeting. A master list of bugs discussed in the
quality meetings is circulated to the support personnel so that they can
respond to inquiries from clients.
"As you know there are issues that come up where the support team cannot
figure out the problem and cannot determine that the issue is, in fact, a bug.
Those "elusive issues" are discussed during the quality meeting and a plan of
attack put together. Sometimes it is just a bit of feedback from development
to take the next step and other times it is a commitment of resources from
development to help find the problem. In either case, there is a spirit of
cooperation and commitment to resolution.
"You also mentioned "bugs that aren't worth fixing". During the quality
meeting you and the other team members may vote a bug is not worth fixing. You
can then go back to the customer with the confidence of knowing that there is
an internal consensus on the rating.
"I have found that the relationship between support and development has improved
dramatically since the SLA was put in place. Both departments better understand
each other and the challenges that each face. We also see better cooperation
and respect between the groups. I hope that this information helps you."
—Michael A. Kennedy mike.kennedy@hotelinfosys.com
Hotel Information Systems www.hotelinfosys.com
949/598-6251
[Any other advice? Send an email to membership director Jane Farber at
jfarber@asponline.com,
and we'll post your feedback.]
|
|
|
