If you woke up today and decided that you have been working hard and need (deserve?) a vacation, would you just throw some things in a bag, jump in the car, and drive south? Well, I suppose some of the more spontaneous readers might, but in general, most people would ask themselves a few questions first, such as the following:
The first step in a successful solution, whether it be a one-week vacation or a two-year, $100-million Web application, is to create a vision statement and a solution scope. The actionable steps and deliverables are reviewed in the following sections. Define the ProblemYour first step is to define the problem to be solved by your solution. Answer the questions posed in the next several questions, and you are on your way to doing just that. What Is the Problem You Are Trying to Solve?The first deliverable you need to provide is a clear problem statement that all parties agree on. Too often, significant money and resources are committed to a problem that is misstated or misunderstood. If the business team sets out to accomplish an unstated goal of reducing the number of field people, but the IT staff sets out to solve the problem of replacing a legacy system because vendor support is soon to expire, someone will likely not be satisfied with the resulting solution. Conversely, if structured properly, solving more than one problem with a single solution is possible. As long as the problem being addressed is clear to all parties, the goal of having a clear problem statement has been met. Problem statements need not be lengthy. Typically, they should fit on a single-page document. Take a look at a couple of examples of poorly worded problem statements.
This is not a problem in itself. You should be asking what is specifically wrong with the old system?
This would make a great vision statement, but it is a poor problem statement. Now look at an example of a properly worded problem statement:
Agree on a problem statement and include it as part of your deliverables for the Envisioning Phase. Get the problem statement signed off on before proceeding. An effective problem statement is one that the stakeholders agree addresses their reason for going forward with a new solution. What Are the Business Goals?Determining the business goal is often just the reverse of the problem statement. The business goal is the benefit of carrying out the solution. If the problem is that the response time to customer inquiries is too long, the goal is "Decrease time required to respond to customer inquiries," or, even more specifically, "Be able to respond to all customer inquires within two hours." The goal addresses the "What's in it for me?" question often asked by the person in the organization who has to approve spending. Benefits are just the flip side of the problem, looked at from the perspective of "What will it look like when I don't have the problem anymore?" At this point, working with business sponsors to prioritize the list of goals is a good idea. In this way, all goals do not carry the same weight. Prioritizing will be handy later on when you discover that you cannot meet every goal in the time allotted. A goal to have 99.4% uptime might not be as important as a goal for ad hoc reporting capabilities, for example. A sample goal list might look like the following:
Ask the business sponsors of the solution to supply a prioritized list of their goals (and benefits) for the requested solution. Include it in the milestone documents for this phase. In addition to the prioritization effort, you might want to assess each item by level of difficulty. Sometimes, a medium- or low-priority item might get added to the solution if the difficulty level is very low. Conversely, a high-priority item might be dropped from a release if the difficulty level is extraordinarily high. Who Are the Users?And what of the user? You need to take the time to define who the users are and how they will interact with your solution. Although I take this topic up in more detail in Chapter 3, "Gathering and Analyzing User Requirements," you need to ask some basic questions up front. Are all users internal employees? Are there external customers entering through an Internet browser? Do you have both internal and external users? There are many questions you could ask. One approach currently in vogue is the use of personas, which are profiles of fictional users of your solution. You might go so far as to name this persona, even give it traits and quirks. Some solutions require only one or two personas to represent the user base; others might require many more. When you define a persona or profile, you should give it specific skills and characteristics. Here is an example:
Keep in mind that Chi is not an actual user, but a persona. That means you can endow the Chi persona with traits that are not necessarily found in any one person, but that might represent a challenge to your solution architecture. You can read more about personas in Alan Cooper's wonderful book, The Inmates Are Running the Asylum (Sams, 1999). Consider creating some user personas for your solution. This is an activity you can do with business stakeholders to facilitate a common understanding of the application's purpose. Propose a SolutionThe solution, at this point in the process, is nothing more than a high-level explanation of the scope and vision. Its purpose is to make clear to all parties what goals you are moving toward. Going back to the vacation example, if the goal is to get to Austin, Texas as fast as possible, the scope of the "proposed" solution might be to purchase airline tickets at whatever cost necessary. The vision statement becomes the following:
All actions become focused on achieving this goal. It might include frantic phone calls to a travel agent, checking the Internet for fares and availability, packing just the essentials so that you can pass security checkpoints with minimal hassle, and so on. Conversely, if the goal is to spend the least amount of money possible, with time not even a factor, all your actions and decisions would be different. You might decide to drive, packing sleeping bags and a cooler with sandwiches and drinks. Imagine for a moment that you were traveling with someone who had a different vision. How confusing and time-wasting would the preparations be if you didn't share a common vision? It seems silly when applied to a vacation plan, but it happens all too often in IT projects around the world and decreases the chance of success before you even begin. What Is Success?As a short aside, I'll define what I mean by "success" when applied to an IT project. In the most commonly used definition, a project satisfies three criteria:
Figure 1.1 shows where you start the negotiation process with stakeholders. In an ideal world, I should be able to specify the project's budget, deadlines, and functionality. However, in real life, the stakeholder gets to choose only two of these dimensions. The development team needs to control the third. In other words, if I say that features are most important to me and the deadline is second, the development team is going to request control over the budget variable. Just as in algebra, you can solve for the unknown, but you can't assign random values to all variables and come up with a valid equation. Figure 1.1. The dimensions of a project's success. (From Microsoft's TechNet Library: IT Solutions > Teams and Processes > Innovative Solutions > MSF Resource Library > "MSF Process Model v. 3.1".)Actually, a fourth dimension is often used that you might want to consider adding to the other three:
Even if you achieve the first three criteria, if you deliver a poorly performing application or one that crashes regularly, it still might not be considered successful. Think of that the next time you fly on an airplane that was built against a deadline, had a budget, and had defined features. Vision and ScopeVision is slightly different from scope. Usually, a vision statement is broader and more motivational. The scope of a project might be the following:
In contrast, a vision might look like this:
Draft a proposal that lays out the solution's scope and vision. Write it down and have all parties sign off. Remember that at this point in the process, a solution is very broad and high level.
Another Way to Look at VisionOne technique often used to define both the current and desired state is the "as is" and "to be" analysis (see Figure 1.2). Figure 1.2. "As is" and "To be."The format is simple. Just create two lists: one that shows how things are before you implement your solution and one that shows how things will look when your solution is implemented as you planned it out. Another term for this technique is "gap analysis." Create an "as is" and "to be" section in your Envisioning Phase deliverable, and share it with the stakeholders for validation.
My Kingdom for a MetaphorAnother strategy that can aid communication is to come up with a metaphor or an analogy that fits the solution. Briefly, a metaphor is actually treating one thing as though it were another, bestowing the traits of one on the other. For example, using the software term "back door" to refer to bypassing an application's security is a metaphor, treating an application like a house. An analogy is using similarities between two disparate things to aid communication. An analogy that almost all developers are familiar with is the comparison between building software and building a house:
As an example, you might design a workflow solution that uses a physical folder containing documents as a metaphor. Users work on the contents of the folder and then pass the results on to the next person. A decision-support application might use an inverted pyramid as a metaphor. Although metaphors work well to describe an entire solution, analogies are often best at communicating more specific concepts. I might be guilty of overuse, but hardly a week goes by that I don't use an analogy to communicate a complicated idea. Why, you could almost say that a good analogy is like a flashlight in a dark basement. If it seems appropriate, select a metaphor for the solution that makes communication with the stakeholders, the development team, and the users more effective. |