Establishing a Proposed Solution

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:

  • Where do I want to go?

  • Should I drive, fly, take a bus, or take a train?

  • Do I want the others in my family to come along? If so, shouldn't I share this "vision" with them before I commit? What if Mary's goal is to spend as little money as possible and mine is to get there as fast as possible?

  • Do I have all the resources I need? Money? A car? A suitcase? A passport?

  • Is it practical to go today when I have an important meeting coming up tomorrow?

  • What are the risks? Do I have enough insurance? Have I checked all the fluid levels in my car? Who checks their fluid levels before a trip anyway?

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 Problem

Your 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.

Replace the old legacy system with new software.

This is not a problem in itself. You should be asking what is specifically wrong with the old system?

Create an awe-inspiring Web site that is graphically eye-catching, provides value (with a Tip of the Day), and motivates people to buy our product.

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:

Recent growth has caused our Web application response times to be unacceptable. Some customers are complaining of wait times that exceed 20 seconds; others just "go elsewhere." We have also been told that the software our application is built with will be unsupported 12 months from now.

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:

Hi Provide 24/7 access with 99.4% uptime.

Hi Protect corporate data from outside attacks.

Hi Offer online purchasing with major credit cards.

Med Offer the capability to print articles in "printer-friendly" format.

Med Support wireless browsers.

Lo Provide the Ask Pat interactive knowledge base for user support.

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:

Chi is a power user of our solution. Chi is able to use English menus and button captions, but needs to be able to enter text in both Traditional and Simplified Chinese. Chi is allowed access to all the ad hoc query features of the screen, but cannot access payroll information. Chi is a keyboard-centric user. Chi travels often and needs to access his e-mail from various locations around the world.

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 Solution

The 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:

We are going to do whatever is necessary to get from Chicago to Austin by tonight.

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:

  • The project is completed on or under budget.

  • The project is completed on or before the scheduled due date.

  • The project encompasses the agreed-on functionality.

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".)

graphics/01fig01.gif


Actually, a fourth dimension is often used that you might want to consider adding to the other three:

  • The project conforms to an acceptable level of quality.

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 Scope

Vision is slightly different from scope. Usually, a vision statement is broader and more motivational. The scope of a project might be the following:

  • Replace the current application.

  • Use the corporate intranet.

  • Avoid lengthy user training to get up to speed.

In contrast, a vision might look like this:

Create a world-class Web application, written in .NET, that is so intuitive that anyone can use it with zero training. The application should be responsive and secure and should increase users' efficiency so that they get more done in less time and with greater accuracy.

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.

graphics/note_icon.gif

Another strategy I often use, although it likely won't be on the exam, is to have a section in the document specifically on what is not in scope. Sometimes this strategy flushes out misunderstandings that were overlooked when agreeing to the scope.


Another Way to Look at Vision

One 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."

graphics/01fig02.gif


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.

graphics/alert_icon.gif

The technique of creating an "as is" and "to be" list is useful when taking the exam. As you read the case study, jot down some notes when you see key phrases such as "We currently have …" or "We want the new system to …."


My Kingdom for a Metaphor

Another 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:

The memory management in our latest component is like a leaky pipe. Eventually, we flood the machine (basement) and the user has to reboot.

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.



Analyzing Requirements and Defining. Net Solution Architectures (Exam 70-300)
MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300: Analyzing Requirements and ... Exam 70-300 (Pro-Certification)
ISBN: 0735618941
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net