2.3 Charting the Approach

2.3.1 Restate the Problem Set

Given the importance of the problem statement, which serves as the "anchor point" of the entire project, it is necessary for the team to not only understand it but to be able to restate it in terms that do not easily allow for multiple interpretations. This is necessary for two main reasons. First, it is critically important that each member of the team share a common understanding of the problem they are trying to address, and by working through the exercise of restating it, it provides a vehicle through which this can be accomplished. It forces team leveling through an interactive discussion of each member's view of the problem. Second, restating the problem provides a detailed view of the problem in simple, straightforward terms, allowing for easy communication and little room for misunderstanding.

Let's use our problem statement from above as an example of restating the problem statement:

The current infrastructure supporting our globally distributed environment is experiencing trends of sagging service levels and rapidly increasing costs, both resulting in customer satisfaction woes.

Restated, the problem set may look like this:

Support personnel turnover is at 100%
Server uptime is at 82%, 17% below agreed to level of service
Network uptime is at 90%, 9% below agreed to level of service
Portfolio of services limited and undocumented
Service delivery inconsistent
Ability to respond to new or changing requirements is not timely
Workstation costs have increased 28% over the last three years
Labor costs have increased 20% over the last two years
Customer satisfaction surveys reflect a 68% satisfaction level, down 21% over the past three years

You can see that there is little room for interpretation as to what the "problems" are and where to focus.

2.3.2 Define the Scope

As with the problem statement, it is necessary to be clear about what is defined to be in and out of scope; therefore, using the scope and the boundaries defined in the "job ticket" as the guide, it is necessary to provide a very descriptive list. When defining the scope, you must also keep in mind any necessary time-dependent requirements you may be under. For example, a third-party contract may expire within a year, or you have a project that will be implemented in 18 months; therefore, you want to prioritize related requirements accordingly .

Depending on these types of "time-related" dependencies, along with depth and breadth of the job ticket, it might be necessary to phase your deliverables. This is where management's expectation gets set, so you want to make sure that your scope is not too broad that it is unachievable. Conversely, you want to ensure that it is not too narrow that you do not derive value from what you deliver. Remember the whole reason for your team's existence is to deliver results, so keep the scope manageable.

2.3.3 Define Your Work Process/Review and Feedback Loop

When we refer to the work process we are really referring to how the team will operate within itself and how it will operate with the support and decision teams. Where some teams of this nature get into trouble is that they do not set up enough review and feedback sessions early enough. Frequent review and feedback will become the team's critical factors for success. Metaphorically speaking, each review and feedback session allows the team an opportunity to "right" or "steer" the ship to its final destination. Can you imagine if you were on a cross-country trip and you waited until you were only a mile away from your final destination before you asked for directions or consulted your map? Use the support and decision teams as part of your tool set, not as a gate or a milestone you must pass.

2.3.4 Gain Buy-In Early

Gaining buy-in early is something that is simple to accomplish and whose importance cannot be stressed enough. The actual sign-off on the proposal should be, relatively speaking, a mere formality if you have successfully gained early buy-in. The real key is to involve the support and decision teams throughout the entire life cycle of the project.

When people think of involvement they usually think of e-mail. They feel that if they create a distribution list (DL) and mail their latest documents out to the world then they have done their job of keeping everyone "involved." This is by no means the involvement referred to in this chapter. When we talk of "involvement" we refer to "bringing in," "solicitation of feedback," and "overcommunication." It is the team's responsibility to physically "bring in" the support teams and the decision team. Call meetings, review facts and findings, and most importantly, "solicit feedback." Draw upon the various team's experiences and expertise; after all, they have been put in place for this reason. Find ways to incorporate feedback into the team's output. There is no better way to gain buy-in than to use someone's input in the final output.

Lastly, do not be afraid to "overcommunicate." When referring to "overcommunication," it does not mean to inundate people with e-mail and voice mail. What it does refer to, however, is to schedule regular and frequent reviews of the team's progress and outputs. This will ensure that you are on track from the support team's and decision team's perspectives and will prevent you from potentially wasting a lot of time heading down the wrong path .

2.3.5 Have Fun!

Some of the most fulfilling project experiences occur on small, dedicated, "task force type" teams operating within a well-defined scope. Therefore, work hard, stay focused, "bring in," "solicit feedback," "overcommunicate," and HAVE FUN!