Activity:
Develop Vision
One of the simplest ways to gain agreement on the definition of the problem, is to
write it down and see if everyone agrees.
Ask the group: What is the problem?
- It is very common to rush headlong into defining the solution, rather than taking time
to first understand the problem.Write down the problem, and see if you can get everyone to
agree on the definition.
Then ask the group again: What is the problem, really?
- Search for root causes, or the "problem behind the problem". The real problem
is often hiding behind what is perceived as a problem.
Dont accept the first statement of a problem. Continue to ask "why?" to
find out what the problem "really" is.
Sometimes the group can be so focused on an envisioned solution that it is hard to get
them to formulate what the underlying problem actually is. In such cases, it can be
beneficial to explore the benefits of the solution, and then try to find the problems
being solved by those benefits. You can then explore whether or not those problems are
"real" problems in the organization. Common techniques used to find the problem
behind the problem are fishbone diagrams and Pareto diagrams.
Depending on the domain expertise of the development team, identifying the stakeholders
may be a trivial or a nontrivial step. Often, this simply involves interviewing
decision-makers, potential users and other interested parties. The following questions are
helpful:
- Who are the users of the system?
- Who is the economic buyer for the system?
- Who else will be affected by the outputs that the system produces?
- Who will evaluate and bless the system when it is delivered and deployed?
- Are there any other internal or external users of the system whose needs must be
addressed?
- Who will maintain the new system?
- Is there anyone else?
- Okay, is there anyone else?
The system boundary defines the border between the solution and the
real world that surrounds the solution. In other words, the system boundary describes an
envelope in which the solution system is contained. Information, in the form of inputs and
outputs, is passed back and forth from the system to the users that live outside of the
system. All interactions with the system occur via interfaces between the system and the
external world.
In many cases, the boundaries of the system are obvious. For example,
the boundaries of a single user, shrink-wrap personal contact manager that runs on Windows
95® are relatively well defined. There is only one user and one platform.
The interfaces between the user and the application consist of the user interface dialogs
that the user accesses to enter information into the system, and any output reports and
communication paths that the system uses to document or transmit the resulting
information.
It is usually very effective to use actors to define and describe the
boundaries of the system. See Activity: Find Actors and Use Cases.
There are a variety of sources of constraints to be considered. Following is a list of
potential sources and questions to ask:
- Political: Are there internal or external political issues that affect potential
solutions? Interdepartmental?
- Economic: Which financial or budgetary constraints are applicable? Are there costs of
goods sold, or product pricing considerations? Are there any licensing issues?
- Environmental: Are there environmental or regulatory constraints? Legal? Other standards
we are restricted by?
- Technical: Are we restricted in our choice of technologies? Are we constrained to work
within existing platforms or technologies? Are we prohibited from any new technologies?
- Feasibility: Is the schedule defined? Are we restricted to existing resources? Can we
use outside labor? Can we expand resources? Temporary? Permanent?
- System: Is the solution to be built on our existing systems? Must we maintain
compatibility with existing solutions? Which operating systems and environments must be
supported?
With the whole group, work on easel charts and fill in the following template for each
problem you have identified:
The problem of <describe the problem>
affects <the stakeholders affected by the problem>.
The impact of which is <what is the impact of the problem>.
A successful solution would <list some key benefits of a successful solution>.
The purpose of this template is to help you distinguish solutions/answers from
problems/questions.
Example:
The problem of: untimely and improper resolution of customer
service issues
affects: our customers, customer support reps and service technicians.
The impact of which is: customer dissatisfaction, perceived lack of quality,
unhappy employees and loss of revenue.
A successful solution would: provide real-time access to a trouble-shooting database
by support reps and facilitate dispatch of service technicians, in a timely manner, only
to those locations which genuinely need their assistance.
Based on the benefits listed in your problems statements, develop a list of features
you want in the system. Describe them briefly, and give them attributes to help define
their general state and priority in the project (for more on attributes, see Activity: Manage Dependencies).
You should check the Vision at this stage to verify that your work is on track, but not
review it in detail. Consider the checkpoints for the Vision document in Activity: Review Requirements.
|