Information Technology Reference
In-Depth Information
Stand-Ins
It is a common situation where access to one of the important stakeholders
— the end user — is denied. The stakeholders, whom the analyst gets
to talk to, are stand-ins for the “real” users. This often happens when a
business or product department, which deals with the end users (the
external customers), refuses or minimizes access to the end users. The
business office assures the analysts that the product office understands
the real users' requirements, that they have all the information required
for the design and development of the application, and that they will sign
off on the requirements and accept the deliverable. This reluctance to
allow access to end users is not always a territorial thing. It sometimes
arises from a genuine concern that technical teams lack the level of
communication and customer-handling skills that the business office pos-
sesses, thereby forcing the business office to minimize such direct inter-
actions and encouraging them to step in as middlemen in the process.
From an application design point of view, not getting access to end
users increases the risk of failure. There have been many situations where
the end user sees the application only after it has been completely built,
and is surprised at what is delivered. Operating in a stand-in mode can
lead to an increased level of risk that the requirements are incorrect. This
could happen because business offices may have little experience with
formal analysis and often struggle with their own issues about understand-
ing the end users. One must recognize such situations and attempt to
observe some risk reduction tactics. Some of these are:
Insist on access to the end user. This may require some escalation
on both the delivery and customer sides. If there is concern about
communication skills, address those.
Have detailed questionnaires, asking for supporting documents for
all key answers. This may require that the end users get involved
in answering questions considered important from their point of
view.
Arrange demos of partially complete work during development,
and try to get the relevant users invited. Observe the discussions
between the business office and the end users during the demo
for signs of confidence about how well the business office is
reflecting end-user needs.
Start a pilot with the end users early. Plan for an early release of
partial functionality as a pilot. Pilots, if implemented properly, can
sort out many end-user issues, including those of look and feel,
that impact requirements.
Search WWH ::




Custom Search