Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Charting the Approach
Now that you know what you need to do, it's time to get started.
Restate the Problem Set
Given the importance of the problem statement, which serves as the "anchor point" of the entire project, it's necessary for the team not only to understand it but to be able to restate it in terms that don't easily allow for multiple interpretations. This is necessary for two main reasons:
It's crucial that the members of the team share a common understanding of the problem they're trying to address. Restating the problem provides a vehicle through which common understanding can be accomplished. It forces team leveling through interactive discussion of each member's view of the problem.
Restating the problem provides a detailed view in simple, straightforward terms, allowing for easy communication and little room for misunderstanding.
Let's review the earlier 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 up-time is at 90%, 9% below agreed-to level of service
Portfolio of services are limited and undocumented
Service delivery is inconsistent
Response 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.
Define the Scope
As with the problem statement, it's necessary to be clear about what's in and out of scope; therefore, using the scope and the boundaries defined in the job ticket as the guide, it's necessary to provide a very descriptive scope list. When defining the scope, keep in mind any necessary time-dependent requirements. For example, a third-party contract may expire within a year, or you might have a project that will be implemented in 18 months; therefore, you need to prioritize related requirements accordingly.
Depending on these types of time-related dependencies, along with depth and breadth of the job ticket, it may be necessary to phase your deliverables. This is where management's expectations are determined, so you make sure that your scope is not so broad that it's unachievable. Conversely, avoid making it so narrow that you don't derive value from what you deliver. Remember, the whole reason for your team's existence is to deliver results, so keep the scope manageable.
Define Your Work Process - Review and Feedback Loop
When we refer to work process, we're really discussing how the team will operate internally and how it will operate with the support and decision teams. Some teams get into trouble because they don't set up review and feedback sessions early enough. Frequent review and feedback are 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 being on a cross-country trip and waiting 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.
Gain Buy-in Early
Gaining buy-in early is simple to accomplish, and its importance cannot be stressed enough. The actual sign-off on the proposal should be a mere formality, relatively speaking, if you've gained early buy-in. The real key is to involve the support and decision teams throughout the entire lifecycle of the project.
When people think of involvement, they usually think of email. They feel that if they create a distribution list and mail their latest documents out to the world, then they have done their job of keeping everyone involved. But true involvement requires "bringing in," solicitation of feedback, and communication. It's 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 on the various teams' experiences and expertise; after all, they've 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.
Finally, don't be afraid to overcommunicate. We don't mean inundating people with email and voice mail, but rather scheduling regular and frequent reviews of the team's progress and outputs. This will ensure that you're on track from the support team's and decision team's perspectives and will prevent you from wasting a lot of time heading down the wrong path.
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, communicate, and have fun!