Opportunity Management

Introduction

Opportunity Management is becoming a growing issue for modern IT shops. Why? Increased scrutiny of IT project resource utilization, and the subsequent rise of the portfolio approach to project management.

• Many IT projects are fraught with perceived cost and time overruns. The days of "show me the money" and you get your project are coming to an end.
  
• Portfolio management's primary focus is to manage opportunities, projects, and systems. By engaging at the business level early, you can gain an appreciation for the business drivers and the proposed solution design constraints.
  

This paper will focus on the processes required to manage opportunities that come to or from the Information Technology (IT) group. Opportunity Management moves you away from the "order taker" role and toward the "trusted advisor" role. This move is becoming manifest with organizations challenging their technical teams to deliver business value, not just cost containment. In this scenario, IT doesn't drive the car – it supplies the car. IT is a service-enabler, and Opportunity Management supports the concept of IT being a service-enabler for the business rather than just being a cost center. A cost containment attitude equates to a "no can do" shop mentality, which is not good for your team and limits your ability to get funding for your much needed projects.

Adopting an Opportunity Management methodology is also a good mechanism to work more effectively with the business units, to gain buy-in, and to understand business processes from their perspectives. Respecting each business unit's core competencies, issues, concerns and viewpoint goes a long way toward making any opportunity successful. You may not always understand or even like a given business unit, but it is imperative that you respect them. Doing so will return respect to your area of technology expertise. It will also give them the chance to witness the potential of technology as it relates to enhancing their business processes.

The methodology explained in this paper supports both waterfall and Rapid Application Development (RAD), though this method is especially attuned to RAD. Adopt the mantra "start small, think big, scale fast." By using this approach, you will be able to respond quickly when the organization is ready to scale solutions beyond their original implementations.

This methodology can be used for both short- and long-term engagements. The stages may look onerous upon first glance, but you will find for smaller projects you only need to confirm details at a certain stages. It remains an excellent checklist to ensure you have covered all the bases, regardless of the size of the opportunity it is managing. As you perform more of these engagements, you will find that many of them take on a similar form and you can reuse patterns of not only previous designs, but also of documentation.

The graphic above demonstrates the flow of opportunity Management

Stage 0 – Opportunity Identification

IT is constantly inundated with requests for changes and the setting of priorities, so this step should look familiar to many in the IT field.

Identification

The main focus of this step is to give the opportunity a name and a shape. "What is the big idea?" is a phrase frequently used in this phase of the discussion. Typically, in larger projects and larger organizations, this opportunity may have been defined in the normal business planning process.

The "elevator speech" is all that is needed to identify the opportunity. An elevator speech is a description of an opportunity that can be explained to a potential sponsor in the time it takes to ride an elevator from the ground floor to the boss's floor. There is no need at this stage to get into final costing or even resource planning. A discussion of "What is the big idea?" and "Why is it being asked for?" is the focus. All too often, IT people start thinking about the "How?" and forget what is driving the "Why?" If the sponsor is clear on why this is important, then assembling the how is less likely to get bogged down, because the focus remains clear.

It is important to log every opportunity in a tracking system. The logging mechanism can be a spreadsheet, database, Web site, or even Notepad. It can be formal or informal, but it is critical that it is logged. For example, you could use your service desk to log all activities regardless if they are issues, changes, or projects. Such an approach makes life easier when resource planning and, once captured, it is guaranteed that all users and stakeholders can more readily follow successful processes.

Qualification

The qualification step focuses on placing the opportunity against the overall strategic business plan and moving priority projects forward, while at the same time redistributing other projects and priorities as required. This cannot be done in isolation; and it is not the role of IT to set priorities, but rather to act on business priorities. By providing trusted advice back to the organization, the IT group is enabling the organization to make better decisions with more and better information. And IT has to eliminate the "sell from the install". During a "sell" engagement everyone is positive and wants to make and opportunity work. This is not a bad thing; however, the qualification step is intended to bring the "install" piece into focus. Issues, such as cost, time, and scope have to be mentioned here to validate the opportunity.

Qualification commences once the sponsor has clearly identified the business drivers and a further investigation has become warranted. Determining the requirement for further investigation can be the tricky part. For the sponsor, an investigation is always warranted and he/she usually can't believe you are not jumping all over the identified opportunity. This is where you get to earn your money – this is your opportunity to work with the sponsor to explain the process, and help everyone understand where their opportunity fits within the context of other organizational initiatives. By working with the sponsor, you can help him/her articulate the opportunity using a pragmatic approach.

This process is meant to put all identified opportunities on the same footing and to align similar projects. It is always amazing how similar "different" departmental needs are when you look for common ground. Organizations that take a step back to align similar projects effectively have a better chance of stopping rogue projects and IT teams, and avoiding duplicated and wasted efforts. But by no means do you make this approach a "boiling of the ocean" exercise, because too much time focusing on strategic alignment prevents achieving valuable short-term gains that can move the organization forward and satisfy the legitimate desire users have to have their needs met.

Adopt a "make !T work" attitude (no, this is not a typo). The philosophy behind this is to make the IT components work for you, and to avoid those components becoming barriers to success. Your job is to align your IT services with opportunities realistically, so your organization can make an informed decision of the validity of the opportunity.

Priority Matrix

Using the priority matrix as defined in a previous post will ensure proper alignment and qualification.

Stage 0 Deliverables

• Entry of the opportunity into a tracking system.
  
• Identification of the opportunity's sponsors and business drivers.
  

Stage 0 Outcomes

• Opportunity identified and entered into tracking system.
  

Stage 0 Duration

• One or two engagements, which could mean as little as one e-mail or as much as two meetings.
  

Stage 1 – Positioning

This is the first formal stage in the opportunity management process. The goal of the Positioning stage is to clearly articulate the vision of the opportunity and its inherent execution requirements. This stage usually requires several workshops, especially for larger projects. As with most first steps, getting it right is vital. All other stages are based on the work of this stage. Without buy-in at this stage, the remaining steps becoming increasingly difficult to execute.

Vision Statement

The vision statement must answer the question, "Where you are going?" The vision statement encompasses the guiding statements of what the opportunity must accomplish. Many firms get hung up on this and create long, drawn out statements that obscure focus and lose value. The vision statement focuses on where you are going, not on how you plan on getting there.

An example of a simple but effective vision statement is, "The solution will provide Internet access to our customers, when they want it and how they want." The statement is clean, clear and is the rod against which the solution will have to be measured. If the solution proposed cannot be accessed off-hours, or cannot allow customer changes, then the opportunity cannot be successful. It also demonstrates a first cut at the solution scope. This proposed solution does not include detailed input from partners or other stakeholders, and must be flexible enough to envelop that input without becoming diffuse.

Mission Statement

The mission statement answers how you are planning on getting to your solution. It is a set of clear directions that are specific to the proposed solution. An example of a mission statement from the preceding vision statement would be, "The solution will use the existing resources to develop an in-house Web-based solution for customer self-service." The key is to keep the mission statement as focused as the vision statement.

Business Drivers

Business drivers become a further articulation of why you are proposing the opportunity. It represents the business you are in and why this opportunity is important. The business drivers can be such things as increased revenue, more access, reduction of costs, or response to competitive forces. Either way, you need to explain why this opportunity is an opportunity – if it isn't an opportunity, it may just be a good idea with no substance.

Key Performance Indicators

Too many projects get funding and have resources assigned when they have no measurable performance indicators. How can the project ever close if you do not know when you have arrived? The performance indicators can be such things as the completion of one month-end, a percent of usage measure, or a simple thing like turning down the old system. By stating a performance indicator you have a natural closing point and a positive approach to the project.

Stating measurable success criteria will allow further steps to contain scope. If the scope is for customers only, and a measure of success is to have 5% of your customers using the Web site within one year, when you have reached the 5% mark then the solution has completed a key performance indictor. The key is that these indicators must be measurable, or they fail the test as indicators of anything at all.

Another consideration is that IT projects are always plagued with perceived overruns and dragging-on of issues. By stating performance indicators up front you are engaging the business units to define, in their terms, what represents success. You must get the business units to sign off on this component, as this will ensure their buy-in as the opportunity turns into a solution and then into a production system. At all stages, the business unit, again in its native terminology, must understand that the IT team is working with it to solve its issues. By engaging them in this process early, it also makes it easier to get the business units to perform and commit to testing at the testing stage.

Governance

The dreaded governance component is like death and taxes – it is inevitable. The opportunity must be have an owner and a sponsor. Sometimes, in larger projects, the owner and sponsor are two different groups. Without clear ownership and sponsorship, a project risks being tagged as an IT project; and as soon as the IT group gets involved the tendency for most business units becomes to defer responsibility and accountability to the IT group. This allows units to spread the guilt if the opportunity isn't accepted, and it is the quickest way to achieve failure. We in the IT field have enough of our own projects – we don't need to get saddled with those from other business units.

The business units know their area and hopefully your team knows IT. They come up with the important "Why," and you have to supply the "How." The governance stage provides for an excellent matching of players between the IT team and the business units. This way both groups know their roles and the components for which they are responsible. It is also an excellent way to measure the level of commitment by the business unit. Are they warm, cold, or very hot toward this opportunity? When you start hearing, "I am not very technical, so shouldn't you lead this?" run for the hills – it is an indication of a lack of commitment from the business unit. You are there to provide trusted advice to the organization, not to be the business sponsor. Now is your time to shine and explain your role.

Stage 1 Deliverables

• Vision statement.
  
• Mission.
  
• Governance.
  
• Business drivers.
  
• Draft definitions for success.
  
• Input into the solution outline.
  

Stage 1 Outcomes

• Position paper that is no larger than 15 pages.
  

Stage 1 Duration

• One week.
  

Stage 2 – Validate Business Needs

This area focuses on further refining the business input, its operating procedures, and its opportunity assumptions. The existing and proposed business models must be defined for any proposed solution since the proposed solution must be able to support the activities of the business unit.

Traditionally, feasibility studies can cover up to and including this stage. All the work done here is to further define and clearly state what currently occurs and how the business unit would like proceed. By knowing these guidelines, the technical team can always check to ensure the solution does not deviate from stated objectives.

Core Business

The core business definition is used to validate the overall objectives of any opportunity. If the opportunity does not complement or satisfy the core business, then it may need to be reconsidered. The focus of these core statements is critical to maintaining the integrity of the solution since, should that focus change over time, the solution will be affected. This is recognition that the solution must be designed to be as dynamic and flexible as necessary to manage changes over time.

It never ceases to amaze the number of groups that cannot clearly articulate the business they are in. Many a time I have heard from the accounting department in a manufacturing company that their departmental business is making widgets. Yes, they are critical to the success of the making of widgets; however, what business is the accounting department in? When I hear phrases like, "we are in the business of collecting, collating and deciphering the business transactions for the organization," I am confident the process is going to have a successful outcome. Success is not always measured by the opportunity being realized; many times it is that the sponsors have accepted the opportunity, worked the process, and that they trust the IT department is giving unbiased support for all elements of the organization.

Programs

Programs are the major methods for delivery of the core business functions, and can either be formal or informal. Continuing the accounting example above, some programs offered by the accounting department could be Accounts Payables and Accounts Receivables.

Programs are how the business unit is broken down to functionally manage their services. Not having an articulation of the business and their programs will make any solution definition incomplete. Every step of the process must be able answer the questions: is it supporting the business and, by definition, is it helping in defined program areas? This is a good acid test to ensure the opportunity is being supported and sponsored by the correct group. Many an opportunity, when it gets into the hands of the IT department, turns into an IT project. This is because the opportunity team is not ensuring the core business and program areas are driving the project. Business solutions should not be lead by IT teams. Having said this, it is imperative that IT representation is present in order to ensure all elements of the organization are covered by any technical solution proposed.

Services

Services deliver value to members of a target group. Typically, this is where the program areas interact with other areas of the organization or customer base. Again, following the above example, the Accounts Payable program area may have a service provision for printing Vendor checks.

Typically, an opportunity is addressing key service areas. This exercise should clearly identify the services the proposed solution is addressing. The service areas, at times, may need to add, change, or delete service components. For example, automating approvals and check printing may have a direct impact on an existing check-printing service. This services definition is especially important in any outsourcing engagement opportunity. By not clearly articulating the as-is services, the new services may overlook key areas that cannot be performed by the new service, and adoption of a final solution will naturally fail under that oversight.

Client Profiles and Scenarios

Specific client areas that will benefit from the opportunity are defined. By breaking down the clients into groups, the business unit will be able to define common wants and needs. This client profiling is used to build scenarios.

Scenarios are structured walkthroughs of the proposed solution. Once the profiles and scenario are defined, a series of business unit engagements can be used to build the use cases. Use cases are nothing more than documents in clear business language to define the specific steps of any given user scenario. If you spend the time in the scenario definition, then the facilitation of the use cases is infinitely easier. (Do not allow the technical team to hijack these meetings. The goal of the scenario workshops is not to start coding, but to garner the spirit of the opportunity and its touch-points with the clients and, ultimately, the solution.

The use cases should focus on the actors, events, and triggers that happen. In simple terms, the actors are the internal or external users of the system; the events are the functions to be performed; and the trigger is what caused the function to commence. Do not get carried away with defining all the business rules, but focus instead on the interaction between actors, events, and business units.

Environmental Scan

Before you engage too far it is always best to get an assessment of what solutions already exist, so best practices and best-of-breed solutions should be researched. The usual magazines, trade papers, and technology Web sites are excellent resources. Today, it is becoming easier to find off-the-shelf products for many solutions.

Colleagues are also an excellent place to source ideas. Learn from the ones who have walked the path first. Look for lessons learned and comparative analysis. Don't forget to weigh your needs against the features and do not get lured into features you don't need and possibly will never use.

The key is to look at things from many perspectives, and weigh existing solutions against the maturity model of your organization. You may be able to find the best-of-breed solution from a given product domain, but is your organization able to understand it and use it? Beginning with a smaller solution to get the organization prepared for a more formal discipline is a good approach. Many of the steps described here are not wasted when putting in a smaller, less function-rich solution. Many purists may disagree with this, but too many large projects cannot get out of the starting gate because the organization cannot get its head wrapped around the larger, more complex system. But when this "start small" approach is taken, it is imperative that the organization realizes those solutions are transitional solutions and elements of the final solution. Not all of this interim solution may be used in the final solution, but nor is it a "throw-away" diversion.

Stage 2 Deliverables

• Definitions for core business, programs, and services.
  
• Validate the opportunity goals.
  
• Further define the business drivers.
  
• Define the governance model.
  
• Environmental scan.
  
• Input into the solution outline.
  

Stage 2 Outcomes

• Use cases profile definitions and for more traditional approaches the feasibility study.
  

Stage 2 Duration

• One to two weeks.
  

Stage 3 – High Level Scenarios

This is the first stage in which technology is introduced to demonstrate the opportunity. The mockups are a low risk approach to visually presenting the options. These mockups are not complete solutions and are not intended to be production ready.

This stage is often used to introduce new concepts. Consider the "7 times 7 different ways" theory, which states that to have people understand a new idea will take seven presentations using seven different approaches. In IT today, one of our many challenges is educating our user community on the realm of the possible. Today e-mail is pervasive and you don't have to explain its concepts. However, at one time we spent a great deal of time explaining e-mail as a generic idea. Some of the new challenges are Instant Messaging, document management, and Web portals. To be blunt, most users do not know what they do not know. In older, mature groups they need to a have common point of reference for new ideas. The mockup allows the IT department to show different approaches of tackling the opportunity as they understand the business needs and drivers.

The mockup can be a slide show presentation, skeleton application that demonstrates workflow, or vendor product demonstrations. This bidirectional dialogue between business sponsors and the IT team is invaluable for nailing down the scope and buy-in of the business unit. Most business units like to be involved in this stage and find this part of the process rewarding, so let them play in the sandbox, but make sure you let them know when recess is over. The goal is to get their input in a non-technical environment where they can see and touch elements of the opportunity.

Though mockups, the business unit also gets to see tangible proof that the IT team understood the previous steps and the business problem that generated the opportunity. Changes to the solution, scope and design are accomplished easily here and should be encouraged. Some IT professionals have a hard time with this step, because they want to deliver a more workable mockup. Be careful of this desire – it will waste valuable time and resources. The users are going to make changes, so get used to it, but do not forget to document the change requests. Welcome to the iterative world.

Stage 3 Deliverables

• Documented customer profiles.
  
• Documented use cases.
  
• Mockups.
  
• Input into the solution outline.
  

Stage 3 Outcomes

• Solution shortlist and/or workable prototype to be further developed.
  

Stage 3 Duration

• One to two weeks.
  

Stage 4 – Technology Alignment

After the mockups, the technology team retreats to their development area and designs a system. This is easier said than done, but if it was easy, someone else would have done it already. At each step of the design process, the IT project lead has to ensure the vision, business, program, and service area's goals and objectives are respected.

The design should include logical and physical architectures, and in a more formal organization you would get architecture sign off and guidance as well.

One area that is usually forgotten at this juncture is the support model. This area requires special care. Many systems are not evaluated thoroughly, and will come back to haunt you in the post-implementation stage.

Work with your user community and your service desk (if you have one) early to get a feel for the non-functional requirements of your proposed solution. Will it need "24x7" support, or is "business hours" support good enough?

Compare the solution to your existing infrastructure. Can you support this new solution? Do you have the capacity, skill and/or resources? This is the time to get those determinations documented and clarified.

Compare your solution to your technology blueprint. Are you duplicating functions you may already have? Is there opportunity to consolidate solutions at the technical layers? An example of this might be the sharing of a Web application server rather than implementing a secondary provider solution.

Once the deliverables are completed, a final workshop is provided for the business unit, so that the IT team can demonstrate the solution. Do yourself a favor and make sure you keep the technical language to a minimum. I have seen too many projects where the technical group is so enamored with their solution they can't help themselves, and drown the presentation in technicalities. All of sudden the client asks, "What about this or that?" and you can hear a pin drop for the sudden silence.

This is the final opportunity for the client group to get their message across as to what they need and how the solution must look, so be respectful of both the technical team and the business unit. Again, changes here are not serious because you are still refining the solutions.

Once the user area has signed off on the technical design, you can proceed to costing and a final proposed-solution design.

Stage 4 Deliverables

• Updated customer profiles.
  
• Updated use cases.
  
• Support model.
  
• Mockups.
  
• Non-functional requirements definitions.
  
• Logical architecture.
  
• Physical architecture.
  
• Input into the solution outline.
  

Stage 4 Outcomes

• Tangible, workable solution architectures.
  

Stage 4 Duration

• Two to four weeks.
  

Stage 5 – Proposed Solution and Costing

After stage 4, the final touches can be made to the proposed solution. By now the functional and non-functional requirements have been agreed and negotiations can commence for costing and component manifesting.

A high-level work plan is established to create milestones and costing containers. These costing containers may include such things as training, implementation, transition, cutover, and/or build costs. At this stage, the costs are used for budgetary purposes, and final negotiations should always bring your costs down at the purchase stage. Many groups get themselves into trouble by negotiating feverously at this stage only to loose leverage due to the time it will take to get final approval.

Work should also be done at this stage to tighten up the component elements of your solution. Tasks should be given to the IT team in respect to further definitions and clarity on development and/or interfacing costs. When trying to interface a new system into an existing infrastructure, make sure you have estimated the learning curve component for your team to acclimate to the new system's parameters and architectures. This is not the time to throw stones at the new kid, for we all live in the glass house. Use the "Improvise, Adapt, Overcome" mantra to get your team focused on getting the solution to work. Everybody is encouraged to make it work instead of finding every possible reason why it can't.

Also, nail down support costs for the initial rollout and ongoing support. Don't forget to clarify how the solution will be maintained. If is maintained by the vendor, how does the vendor expect to support you? Is the solution a mission-critical solution? Is the vendor aware how its solution is going to be implemented?

Stage 5 Deliverables

• Revised functional requirements.
  
• Revised non-functional requirements.
  
• Update to logical architecture.
  
• Update to physical architecture.
  
• Solution costing.
  
• Support model and costing.
  
• Input into the solution outline.
  

Stage 5 Outcomes

• Rough draft of the solution outline and very high level costs (+/- 25%).
  

Stage 5 Duration

• One to two weeks.
  

Stage 6 – Implementation Planning

This is where the rubber hits the road. All the work until now, for the most part, has been open-ended with no firm commitments on dates and deliverables. After stage 5, the client and you are committed for the implementation plan.

What the business unit wants to know is, "How long is it going to take and when will we get the nod?" This answer has to be sensitive to organizational approval schedules, other projects, resource constraints, and operational concerns.

The implementation project plan might include the following milestones for a development opportunity:

• Deploy and release to production plan.
  
• High level test plan – do not assume the user knows what or how to test.
  
• Procurement and setup timelines.
  
• Marketing communications plan – it is very important to get the word out on the positives of the opportunity.
  
• Infrastructure updates and configuration changes.
  

Stage 6 Deliverables

• Project plan.
  
• High-level costing.
  
• Communication plan.
  
• Input into the solution outline.
  

Stage 6 Outcomes

• Workable project plan and costing figures for approvals.
  

Stage 6 Duration

• Two to four weeks.
  

Stage 7 – Solution Outline

The solution outline is the culmination of all the previous steps. It is a technical document that will be the main resource for the solution after funding has been approved. Many organizations will get the business units to sign off on this document, but most users do not know what they are signing, so don't put too much weight on their signatures. Do, however, review the document with them to ensure you have captured the business drivers and guiding principles of the opportunity.

The important thing to remember is that the documents will contain all the relevant technical information for the proposed opportunity. Depending on the scale and scope of the solution, this document can be large and not a pretty read, but by culling this document you can build the requirements for the solution and for any Requests for Proposal (RFPs) that may need to be created as a result of this opportunity getting funded. It will become an invaluable resource for your technical team even if it becomes a shelf-filler for your business units.

Your solution outline may contain some, all, or even more than the following items:

• Introduction.
  
• Business scope.
  
• Core businesses and services.
  

• Mission statement and guiding principals. Clearly state the guiding principles in the solution outline. This will ensure all players understand the overall guidelines of the solution being proposed.
  
  • Core business.
    
  • Programs.
    
  • Services.
    
  • Types of individuals and organizations.
    
  • Client needs.
    
  • Goals.
    
  • Business drivers.
    
  • Architecture overview – introduction.
    
  • Architecture overview – enterprise view.
    
  • User groups and delivery channels.
    
  • Business services.
    
  • Resources.
    
  • Architecture overview – components view.
    
  • Presentation services.
    
  • Architecture overview – software view.
    
  • Architecture overview – IT system view.
    
  • Logical technical architecture.
    
  • Architecture overview – physical view.
    
• Non-functional (operational) requirements – Do not overlook the importance of getting in writing some of the non-functional constraints.
  
• IT standards – It is always good to state the baseline for which the solution must adhere to. This will give valuable insight into why certain technical decisions where made long after the opportunity has passed and the designers have moved on.
  

Stage 7 Deliverables

• Revised functional requirements.
  
• Revised non-functional requirements.
  
• Update to logical architecture.
  
• Update to physical architecture.
  
• Solution costing;
  
• Support model and costing.
  
• Final report back on solution to business area.
  

Stage 7 Outcomes

• Final report on solution outline and high level costs (+/- 10%).
  

Stage 7 Duration

• One to two weeks.
  

Stage 8 – Business Plan/Case

Where the solution outline addresses the technical problems and opportunities, the business case addresses the business problems and opportunities. The business case has very little technical information in it and is written to be read by the business decision-makers. The main focus of this document is to state the business opportunity with its associated costs and benefits.

It is imperative to include the business unit in the creation of this document. They have to not only buy-in, but must also contribute to the end result. The organization will be using this document as the core document to make its decisions, so it must be written in common business language and any technical information should be filtered for readability. You do not want the organization to mistake this opportunity as a technical project, and remember that even technical opportunities must drive the business forward.

A sample table of contents of a business case is:

• Background.
  
• Guiding principles.
  
• Solution.
  
• Software.
  
• Technology/hardware.
  
• Network.
  
• Cost summary.
  
• Benefit summary.
  
• Conclusion.
  

Stage 8 Deliverables

• Business case.
  
• Revised costs.
  

Stage 8 Outcomes

• Business case.
  

Stage 8 Duration

• One to two weeks.
  

Stage 9 – Funding Approval

The "hurry up and wait" game begins here. All the effort, time, money, and resources are now on hold until you get the nod. If this project is high profile and important you may be working the back room to sell the opportunity before the formal approval process commences, so you want to make sure the elevator speech is being worked at all levels.

Stage 9 Deliverables

• None – trust the process.
  

Stage 9 Outcomes

• Funding approval or a "go/no go" decisions.
  

Stage 9 Duration

• Dependent on how your organization approves opportunities.
  

Stage 10 – Implementation

It has been correctly said that you should be careful what you wish for, because you may just get it. The fun is over when the project has been approved, because now your team has to deliver the promise. The main source document is the solution outline, and depending on the time lapse between its initial creation and your approval to implement you will have to update the numbers and project plan accordingly.

It is important you get sign-off on all changes to the solution outline and business case prior to implementing the previously agreed plan. The line "Don't confuse the sell with the install" comes back again to haunt. The sell cycle is always fraught with positive statements and "don't worry" attitudes. However, once the contract is being presented, the install side of the house arrives to take all the fun and money away. This is also a good time to get the vendors to commit to their schedules and resources as were agreed to in previous steps.

Stage 10 Deliverables

• The solution as agreed to.
  
• Execution of the project plan.
  
• Execution of the communications plan.
  

Stage 10 Outcomes

• Commencement of proposed solution.
  

Stage 10 Duration

• Dependent on implementation schedule as defined in stage 6.
  

Conclusion

These steps, at first blush, may appear too complicated for most IT groups. However, upon review you will find you have been doing most of these steps all along. This methodology was meant as an "aide de memoir" to ensure your opportunities are given every chance to succeed, and for you to gain valuable input on why the business units are looking for your team's help.

This methodology has proven very successful for both small and large projects. It can span from one week to many months, depending on complexity and scope. After the first few formal uses of this methodology, user groups will grow to understand why previous IT projects failed. One of the major reasons they fail is a basic failure to speak the same language across boundaries within and without the organization, and this approach rectifies that problem by its adherence to a well-founded process.

Being involved in the opportunity stage is new to most IT groups. They are used to users coming up with requests and then being tasked to complete them. This methodology puts you in the trusted-advisor role within your organization, where you will become part of the decision making process. You will be providing the organization business-value through your input and pragmatic approach. The goal is for them to succeed, because when they succeed your IT group will be validated.

Some organizations have swat teams for opportunity development. These teams consist of Web design, graphic design, infrastructure support, business analysis, telecommunications, and customer support. It sounds impressive, but for some opportunities all these roles and more are needed to prove or disprove the opportunity's viability. The bottom line is an opportunity team is a small team that is able to be creative and drive the business value forward.

The risk of not getting involved at the opportunity level reduces the IT group to order takers. By being an order taker, you are bound to the business area's comprehension of the overall business needs and your unique requirements of trying to keep their house of cards from collapsing. As the competitive forces increase and the user community gets more knowledgeable about IT, the ability to manage opportunities will become paramount. Most IT groups are feeling the pinch now. The wave is coming, and it is better to learn to surf then to be swept up by it.