use cases
Quality
Control
Clear
Objectives
Global
Product Management
Under Performing Product
Consumer Expectations
clear objectives
scenario
On a number of occasions we have worked
in companies where the
enhancement request for a product didn't match the final delivery.
Sometimes it only addressed elements of the requirement; at times it
was a sledge hammer to kill an ant; and other times it bore no
resemblance to the initial request. In most of these situations the
product manager was in the firing line but this was, more often than
not, misplaced blame (except that they should have investigated the
chain of events more thoroughly).
As one can can imagine the customers were puzzled and
concerned by the poor attention to detail.
tasks
We first identified a number of examples where the delivery had not match the customer's requirement. We then checked
actions
Requirement request process
We set-up a new process to capture requirements. This identified the request owner, a customer representative, greater details on the request, why it had arisen and when it was needed by. In addition there were opportunities for other stakeholders to add comments to the request (e.g. the scope of delivery, if other customers had requested it, whether it was already available or due in a future release, etc.). Key to this process was making sure that the request owner signed-off the product specification and were shown working examples of the functionality prior to it being passed to QA. Where appropriate the customer was also involved in the sign off.
Change Orders
We discovered that while there was a
formal change request process this
did not cover enhancement requests, only minor bug fixes. This was
because the major enhancements often came through sales, professional
services or senior management and not customer support. We also found
that this would occasionally result in the requests being lost in the
system. Where we could trace an enhancement request, the detail was
usually less than two sentences long and no owner could be found. So
immediately the job of the product development manager became that of a
mind reader.
Specification adherence
A number of other issue were uncovered
primarily during
the architecture and development processes where:
It was important to work closely with the development team to get them to approach the design stage a little more conscientiously. First we agreed that elements of the product specification should be copied to the technical specification, so that they could clearly be seen to have been addressed. Further down the line this assisted developers in understanding the original request. Many of the developers commented that these changes were welcomed, as they now felt they had a better understanding of how customers were using the applications and they felt less like machines on a production line.
The QA team were instructed to
devise test plans
primarily from the product specification. These changes had the backing
of both the head of development and senior management.
result
The regular bemused look on the faces of our customers, as they
received functionality that was unrelated to their request,
subsided completely. This helped eradicate the feeling that delivery
was both ad-hoc and sloppy and there was better visibility to the
delivery process. From the companies perspective this helped our
customers understand that new functionality was not an overnight
process and subsequently delivery deadlines became more realistic.
A by-product was that request owner felt more empowered. They could
see a through line from idea to delivery and how they could best
influence
the output.
© Visjung 2009