WO2001026014A1 - Method and estimator for providing service control - Google Patents

Abstract

A method for providing service control (13) in an information technology organization provides the tasks involved in building a service control (13) function. The tasks include planning, analysis, design, build, test, and deployment of service control (13). Each task includes process, organization, and technology infrastructure elements.

Description

METHOD AND ESTIMATOR FOR PROVIDING SERVICE CONTROL

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application 60/158,259, filed October 6, 1999. This application is related to Application Serial No. entitled "Organization of Information Technology

Functions," by Dove et al. (Atty. Docket No. 10022/45), filed herewith. These applications are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

Expenditures on information technology have risen over the past twenty years to the point where they are almost always a significant amount in the capital budget of any enterprise. These enterprises include business enterprises, and may also include non-for-profit businesses, charitable institutions, religious institutions, educational establishments, governmental agencies, non-governmental organizations, and other organizations of many types.

The expenditures are not only for computers and their software, but also for many other purposes associated with computers and information technology. These further expenses often include the cost of networking a plurality of computers. Once networks are established, servers of several varieties may be used, as well as other computers and peripherals. As the

Internet and e-commerce have come of age, firewalls, intranets, and web servers are constructed and must be administered. Computer security concerns arise as well.

The biggest challenges in Information Technology ("IT") development today are actually not in the technologies, but in the management of those technologies in a complex business environment. From idea conception to capability delivery, and to operation, all IT activities, including strategy development, planning, administration, coordination of project requests, change administration, and managing demand for discretionary and non- discretionary activities and operations, must be collectively managed. A shared understanding and representation of IT management is needed because today's technological and business environment demands it. The new technological management orientation should include ways for planning, assessing, and deploying technology within and across enterprises. Businesses need to balance technological capability with enterprise capability in order to remain modern organizations with a chance of survival. There is a need, therefore, to construct a complete yet simple IT framework that would quickly convey the entire scope of IT capability in a functional decomposition. Such a framework needs to be a single framework describing an entire IT capability, whether as functions, systems or tasks. The IT framework should be a framework of functions, a representation of a complete checklist of all relevant activities performed in an IT enterprise. A single IT Framework should represent all functions operative in an IT enterprise.

Within that IT framework, there is also a need for a service control function that provides IT customers with a single point of contact for service requests, problems, or general user administration. A service control function should be proactive and focus on serving users' overall needs, providing a central point of contact and taking ownership of resolution. A service control function should coordinate with other function categories to provide input and aims to continuously improve current IT services and offerings.

BRIEF SUMMARY OF THE INVENTION

The present invention is defined by the following claims, and nothing in this section should be taken as a limitation on those claims. By way of introduction, one embodiment is a method for providing a service control system that includes planning, designing, building, testing, and deploying a service control system for an IT organization. In another embodiment, the method includes developing a business performance model for the planning phase of the service control.

In another embodiment, the method preferably includes designing business processes, skills, and user interaction for the design phase of service control. The method further includes designing an organization infrastructure and a performance enhancement infrastructure for said service control. The method also includes designing technology infrastructure and operations architecture for the design phase of service control. In the building phase of the method, the technology infrastructure and the operations architecture for the building phase of service control are built. The technology infrastructure and the operations architecture for the testing phase of the service control are tested. In the deploying phase, the technology infrastructure for the IT organization is deployed. The method also provides for business policies, procedures, performance support, and learning products for service control.

Another aspect of the present invention is a method for providing an estimate for building a service control function in an information technology system. This aspect of the present invention allows an IT consultant to give on site estimations to a client within minutes. The estimator produces a detailed breakdown of cost and time to complete a project by displaying the costs and time corresponding to each stage of a project along with each task. Another aspect of the present invention is a computer system for allocating time and computing cost for building a service control function in an information technology system.

These and other features and advantages of the invention will become apparent upon review of the following detailed description of the presently preferred embodiments of the invention, taken in conjunction with the appended drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitation in the accompanying figures. In the figures, like reference numbers indicate identical or functionally similar elements. Figure 1 shows a representation of service control functions.

Figure 2 shows a representation of an operation management method for service control according to the presently preferred embodiment of the invention.

Figure 3 shows a representation of a task for defining a business performance model for service control.

Figure 4 shows a representation of a task for designing business processes, skills, and user interaction for service control. Figure 5 shows a representation of a task for designing technology infrastructure requirements for service control.

Figure 6 shows a representation of a task for designing an organization infrastructure for service control. Figure 7 shows a representation of a task for designing a performance enhancement infrastructure for service control.

Figure 8 shows a representation of a task for designing operations architecture for service control.

Figure 9 shows a representation of a task for validating a technology infrastructure for service control.

Figure 10 shows a representation of a task for acquiring a technology infrastructure for service control.

Figure 11 shows a representation of a task for building and testing operations architecture for service control. Figure 12 shows a representation of a task for developing business policies, procedures, and performance support architecture for service control.

Figure 13 shows a representation of a task for developing learning products for service control.

Figure 14 shows a representation of a task for testing a technology infrastructure product for service control.

Figure 15 shows a representation of a task for deploying a technology infrastructure for service control.

Figure 16 shows a flow chart for obtaining an estimate of cost and time allocation for a project. Figures 17a, 17b, and 17c show one embodiment of an estimating worksheet for an OM service control estimating guide.

DETAILED DESCRIPTION OF THE INVENTION

In a modern information technology system, multiple functions are organized and categorized to provide comprehensive service to the user, and thereby a framework is provided for understanding the interrelationships of the various functionalities, and for managing the complex IT system. The functionalities with the IT system include a customer service management system function; a service integration function; a service delivery function, a capability development function; a change administration function; a strategy, architecture and planning function; a management and administration function; a human performance management function; and a governance and strategic relationships function. Within the customer service management function, service control plays an important role. The present invention includes a method for providing a service control function for an information technology organization.

Before describing the method and system for providing service control, a brief explanation is in order concerning service control, and its systems, functions and tasks.

Service control provides information technology customers with a single point of contact for service requests, problems, or general User Administration. This is the "traditional Help Desk" or "Service Desk" function with the addition of handling service requests and User Administration. The "traditional Help Desk" focuses primarily on system troubles, whereas Service

Control is more proactive and focuses more on serving the users' overall needs, providing a central point of contact, and taking ownership of resolution. In one embodiment as depicted in Figure 1 , the scope of Service Control 13 includes three organizations, Service Request Management 131 , Problem Management 132, and User Administration 133.

The Service Control function set is typically composed of three levels of support:

Level 1 - handles and resolves as many requests and problems, as possible, at the first contact using the tools and knowledge at the service desk. Level 1 should always be the single point of contact for a user's request or incident handling;

Level 2 - with more technical and business expertise, this level resolves the more difficult problems or specialized requests; and Level 3 - resolves problems that cannot be resolved by the first two levels of support and requires additional technical or programming expertise or vendor assistance (usually involving applications code changes or technical modifications).

Service Control provides the following services: Service Request Management - handles the fulfillment of all information technology requests and calls from the user (i.e., moves, password resets, etc.). Some of these requests may include requests for User Administration, while others are problems that would be handled by Problem Management. Note that "Larger" information technology requests are called "Project Requests". The differences between what is considered a "smaller'Vservice request vs. a "larger'Vproject request may be defined in the Governance & Strategic Relationships function categories;

Problem Management - handles the resolution of incidents (single occurrences of an issue that affects the delivery of normal or expected service) and problems (incidents that cannot be resolved at the first level of support);

User Administration - handles the day-to-day tasks involved in administering users on the system. Some of these tasks may be routine maintenance requests, while some may be received through the Project

Request Management or Problem Management functions.

Service request management acts as a single point of contact for all requests from users. This function coordinates and controls all service requests including install, move, add, or change activities necessary to fulfill business service requests that are not large enough to be considered projects. "Smaller" or non-project requests may include daily, routine application maintenance activities, such as: changing the date a "canned" report is printed, adding an additional field to a simple database, resetting application passwords, changing user Ids, and requesting additional telephones. Requests are classified as one of the following:

Simple Service Requests - A service request that does not require a lot of effort but may not be able to be resolved instantly, i.e., ordering a new LAN cable for a user.

Incident - A single occurrence of an issue that affects the user's ability to function in the environment. An incident is defined as an issue that can be resolved using business and product knowledge at the first level of support (i.e., by the person answering the phone at Service Control).

Problem - An incident that cannot be resolved at the first level of support and requires additional technical or business expertise. Because it is usually a more complex issue, it may also be the underlying cause of one or more incidents. Experts will correct the problem and its underlying cause(s), while attempting to prevent any recurring incidents. Experts should also provide Level 1 support with the knowledge required to resolve it when appropriate.

Change Request - Service Request Management receives change requests, but they are administered in Change Administration.

User Administration - Service Request Management receives requests for changes to user ID/accounts, but are acted upon in the User Administration function.

Note that Project Request Management handles project requests that involve new functionality or a significant work effort. Larger application maintenance requests (those that are not routine or do not have predetermined rules already associated with them) should be handled through appropriate maintenance, in one embodiment, service request management has four sub-functions, including but not limited to, service request logging and categorization, service request prioritization, service request assignment and tracking, and service request resolution.

Service request logging and categorization collects all information pertaining to the service request and logs it into a Service Control tracking tool. The information required might include: user name and contact number, date - when a service request has been raised, accepted, rejected, deferred, or implemented; current status of the service request; asset types affected; any approvals required; and name of person responsible for implementation. This function also performs an analysis on the service request in order to categorize it and assign its priority. Based upon the analysis, the assignment may be resolved immediately by the initial Service Control analyst or may be assigned to the appropriate support personnel. Additionally, this function verifies that the service request is reasonable in scope and that the caller is a valid user. Before assigning the request to support personnel, the Level 1

Service Control personnel ensures that all approvals have been collected, since some service requests may require multiple approvals (i.e., remote access) before they can be assigned. Service request prioritization verifies requestor's priority for the service request and prioritizes the request against all other requests made by the customer using the prioritization guidelines. This function determines the appropriate speed with which the service request should be handled, clearly communicates the assigned priority level to the customer, and queues the request in the service request-tracking tool with the correct assigned priority level. Priorities for standard or common service requests should be clearly defined by the Governance & Strategic Relationships function category, and the priority levels and their expected turnaround time should be clearly communicated to the user groups.

Service request assignment and tracking assigns the service request to the appropriate support personnel once all approvals have been made. Using the service request-tracking tool, Service Control will be able to track the request through closure and ensure that while service requests are resolved, all service levels are being met. Service request resolution resolves all simple service requests, i.e., those that do not require escalation. An example of a simple service request would be a request for a new LAN cable. This function verifies the resolution of all service requests through a confirmed resolution. A problem management function coordinates problem resolution among the users of the system and those operating and maintaining the system from incident logging through confirmed resolution. This function includes receiving incidents from users and informing users of potential workarounds or resolutions, when possible. If Service Control cannot resolve the incident, the incident will be classified as a problem and assigned to the appropriate support group. This function continues to provide status and track the problem through resolution, including escalations as necessary. Resolution of problems is approached through levels of support with various service providers utilized as appropriate.

Functions within resolution management include incident resolution, which attempts to resolve incidents by gathering all relevant information from the user, recreating the incident if necessary, prioritizing the incident, and using business and product knowledge, together with known problem checklists and other diagnostic aids, to deliver quality resolutions. If an incident cannot be resolved through analysis or if similar incidents are occurring, the incident becomes a problem and is assigned to a higher level

(i.e., technical support groups, developers, business experts, etc.) for resolution. Related incidents are associated with problems, so that the resolutions can be applied to each occurring incident. Problem escalation functions monitor all open/outstanding problems and escalate the problem if it is urgent or exceeds the established service levels.

This function includes the notification of the person working on the problem and the next level of management. Problems may continue to be escalated up the levels of Service Control and information technology management if the problem is not resolved, the problem affects a business-critical system, or if users are not being satisfied. A sample escalation path, within information technology, may be: support group leader, support group manager and support group director.

Note that as problems are escalated within the information technology organization, information technology also communicates the status with the customer or user liaison on a regular basis. If the problem cannot be resolved within the established service levels, the business customer should be notified. If there is a significant business impact, escalation within the business should be initiated. A sample escalation path may include the user's manager, the user's department director, and the user's department VP. For certain problems that affect the overall enterprise, Service Control may make a communication to the entire user community regarding the problem and its status.

A proactive function may be that of problem resolution, which corrects identified problems and prevents recurring incidents by determining and correcting the underlying problems causing those incidents; this typically requires an expert or support groups. In a preferred embodiment, the user confirms all problem resolutions. All problem resolutions are logged, tracked, and archived for future reference. Going further, root cause analysis group's similar problems reactively to try to avoid future problems. Service Control monitors daily metrics and collects historical data about recurring incidents that could be associated with an underlying problem. This function uses monitoring tools and documented incidents to complete an analysis to identify issues causing problems and uses the resolution to prevent additional incidents from occurring. A Level 1 lead or manager typically performs this function.

In another proactive effort to improve information technology performance, a Knowledge Repository Management function may be implemented. Knowledge Repository Management identifies common incidents and problems documented by the service request tracking tool and reviews and approves associated resolutions. This function identifies areas where new knowledge is created, updated, or simply communicated to the

Service Control teams. This also includes archiving or deleting obsolete knowledge (i.e., Windows 3.1 resolutions when the enterprise has upgraded to Windows NT). This function coordinates with the business unit and information technology enterprise experts in developing and publishing knowledge (i.e., Top 10 resolutions) to improve the resolution rates at Level 1. By working closely with Root Cause Analysis, Service Control can publish resolutions and prevent problems from recurring. Although knowledge is usually stored within a knowledge base within the service request-tracking tool, it may be beneficial to publish a newsletter or web site with Top 10 resolutions that customers can resolve themselves, without having to call the Service Control. A Level 1 lead or manager typically performs knowledge Repository Management.

A User Administration function is also useful in customer service management. User administration handles the day-to-day tasks involved in administering users on the system. These tasks include such things as: Moves/Adds/Changes for desktops, Adding/Deleting/Modifying users, User ID changing, Re-establishing user passwords, Maintaining groups of users, and maintaining sets of profiles.

Note that larger application maintenance activities or changes in which a large group of users are being affected are typically handled through different functions, either Project Request Management or Change Administration. The Governance & Strategic Relationships function set determines how to differentiate between what is a standard User Administration task (i.e., a request for two new user IDs) vs. a larger User Administration process (30 new user IDs for a new system). Requests are received through Service Request Management and are approved or disapproved based upon predetermined Security Administration procedures. Included in this group are the functions of user tracking, user status and notification, user group maintenance, and desktop Moves/Adds/Changes.

User tracking receives personnel employment activity information from Human Performance Management regarding employees' hiring, transfers, leaves of absences, and termination. This function establishes an effective communication mechanism between Human Performance Management and the appropriate information technology User Administration personnel. Maintenance of this system will facilitate up-to-date information regarding employee arrival, transfer, hold, and departure dates. For example, Human

Performance Management would send a list of new hires, their start dates, and the groups or departments they will be working in to the User Administration group. Once this list is received, the following actions can take place: User Addition - Adds users to all necessary systems (i.e., network, mail, etc.). User Administration Personnel should create IDs/accounts and all users with appropriate type of access to all necessary systems and accounts and procure hardware as needed (through Desktop Moves/Adds/Changes), and User Account Maintenance - Changes user information on all necessary systems. By having established an effective communication mechanism, User Administration personnel can schedule updates and modifications to existing user accounts.

User Deletion - Deletes user information on all necessary systems. Effective communication mechanisms allow personnel to schedule user account deletions on all necessary systems (i.e., network, mail, etc.).

The function of User Status and Notification may be used to clearly document the various access levels a user has to the various information technology systems and notifies appropriate parties periodically of User Administration status. The function includes documenting user account maintenance and goal fulfillment and distributing user account status to the appropriate parties. Parties may include Human Performance Management, Applications Support, and Operations Support, as well as the user himself/herself. Depending on the urgency of the maintenance, this notification to other groups can take many forms: immediate notification - e- mail, pager; scheduled status reports or information through Change Control meetings; or information presented at Change Administration meetings.

User group maintenance functions maintain the user groups and group profiles. The function includes clearly documenting the various access levels a user group has to the various IT systems. This group makes all appropriate changes, including adding/moving/deleting users from a group. A user group may be a department or a role that has certain privileges. It is easier to maintain access levels for a group rather than to individually maintain all user IDs and access levels; therefore, user groups should be established for employees with similar roles who require the same access level. Lastly under customer service management, a group or function may handle desktop moves/adds/changes. This group handles desktop alterations. The function includes moving desktops from location to location, adding desktops to new locations, and making some changes to existing desktops. Large department moves or changes would be handled in Project Request Management or Change Administration. The Governance & Strategic Relationships function category would clearly define what number of moves constitutes a "large" move/add/change request, and thus what should be handled through a project or change request.

According to the present invention, the method for providing Operations Management ("OM") service control includes the tasks involved in building a particular OM function. These specific tasks are described in reference to the Operations Management Planning Chart ("OMPC") that is shown on Figure 2. This chart provides a methodology for capability delivery, which includes tasks such as planning analysis, design, build & test, and deployment. Each OM function includes process, organization, and technology elements that are addressed throughout the description of the corresponding OM function.

METHOD FOR PROVIDING SERVICE CONTROL

According to the present invention, the method for providing service control includes the tasks involved in building a particular OM function. These specific tasks are described in reference to the Operations Management Planning Chart ("OMPC") that is shown on Figure 2. This chart provides a methodology for capability delivery, which includes tasks such as planning analysis, design, build & test, and deployment. Each OM function includes process, organization, and technology elements that are addressed throughout the following description of the corresponding OM function.

The method comprises four phases, as described below in connection with Figure 2. The first phase, "plan delivery" 102, or planning, includes the step of defining a business performance model 2110. The second phase, design, 104, has a plurality of steps, including design of business processes, skills and user interactions 2410, design of organizational infrastructure 2710, design of performance enhancement infrastructure 2750, analyze technology infrastructure requirements 3510, select and design operations architecture 3550, and validate technology infrastructure 3590. A third phase, build and test 106, has a second plurality of steps, acquire technology infrastructure 5510, build and test operations architecture 5550, develop policies, procedures and performance support 6220, develop learning products 6260 and prepare and execute technology infrastructure product tests 5590. The fourth phase 108 includes the step of deploying 7170. In the following description, the details of the tasks within each step are discussed. Service Control delivery and deployment focuses on a new or enhanced business capability. One of the key steps in defining business and performance requirements is identifying all of the types of support and levels of support that end users and other stakeholders should receive from the Service Control function. While Service Control personnel may be responsible for performing other OM functions in the organization, this set of task packages is limited to analysis of functions which are nearly always associated with Service Control. They include Service Request Management, Problem Management, and User Administration.

Step 2110 - Refine Business Performance Model In step 2110, the business model requirements for service control are defined, and the scope of the delivery and deployment effort is determined. Figure 3 shows a representation of the tasks for carrying out these functions according to the presently preferred embodiment of the invention. Figure 3 is a more detailed look at the business performance model 2110, which may include the functions of confirming business architecture 211 1 , analyzing operating constraints 2113, analyzing current business capabilities 2115, identifying best operating practices 2117, refine business capability requirements 2118, and updating the business performance model 2119.

Task 2111 : Confirm Business Architecture Task 211 1 includes assessing the current business architecture, confirming the goals and objectives, and refining the components of the business architecture. Preferably, the task includes reviewing the planning stage documentation, confirming or refining the overall service control architecture, and ensuring management commitment to the project. The amount of analysis performed in this task depends on the work previously performed in the planning phase of the project. Process, technology, organization, and performance issues are included in the analysis. As part of a business integration project, Service Control delivery and deployment focuses on a new or enhanced business capability, whereas, an enterprise- wide Service Control deployment requires analysis of multiple applications rather than a single business capability.

One of the key steps in defining business and performance requirements is identifying all of the types of support and levels of support that end users and other stakeholders should receive from the Service Control function. While Service Control personnel may be responsible for performing other OM functions in the organization, this set of task packages is limited to analysis of functions which are nearly always associated with Service Control. They include Service Request Management, Problem Management, and User

Administration.

Task 2113: Analyze Operating Constraints

Task 2113 includes identifying the operating constraints and limitations, and assessing their potential impact on the operations environment. Preferably, the task includes assessing the organization's strategy and culture and its potential impact on the project, and assesses organization, technology, process, equipment, and facilities for the constraints. The task includes assessing the organization's ability to adapt to changes as part of the constraints analysis.

Pre-selected package software may cause Service Control constraints. In looking at this function and assessing the cost, the estimator must assess the organization's ability to adapt to change as part of the constraints analysis. As an example, Service Level Agreements (SLA) frequently contain Service Control provisions. Any existing SLAs with Service Control provisions will create expectations within the user community about the delivery of services, and must be taken into account. In addition, any work underway to define new SLAs which affect Service Control need to be incorporated in the requirements. The key point in confirming a business architecture may be to understand the customer's expectations of services to be supported and levels of service.

Task 2115: Analyze Current Service Control Capability Analyzing the current business capability 2115 is the next task in the process. One way to accomplish this is to document current activities and procedures to establish a performance baseline if there is an existing system. An analysis may also assess strengths and weaknesses of any existing Service Control capability in order to better plan and design for the future. Important considerations include understanding the Service Control processes before looking into how they are currently measured. Another important consideration is to perform this task to the level of detail needed to understand the level of service desired, and if a change is involved, the degree of change required to move to a new Service Control capability.

Task 2117: Identify Service Control Best Practices

The next task may be to identify the best operating practices 2117 for the operation, and to identify the Service Control areas that could benefit from application of best practices. In one embodiment, a provider will research and identify the optimum best practices to meet the environment and objectives. In a preferred embodiment, applying best practices may require customization of the system to meet the particular circumstances of the organization. Task 2118: Refine Service Control Requirements

The next task in the planning 102 may be to refine business capability requirements 2118. Capability requirements define what the Service Control infrastructure will do; capability performance requirements define how well it will operate. In defining the requirements, it may be useful to meet with the user community to determine the types of services and levels of service that users believe should be provided. User perceptions of Service Control may vary widely, and therefore service issues should be documented carefully and in as much detail as possible to ensure expectations are properly controlled. This would cover not only specific services, but also the policies and procedures for access requirements, setting of severity levels, prioritization, and escalation.

Another key issue in determining the requirements is location, specifically whether Service Control personnel will be centrally located or distributed in some way. This can have a major impact on staffing levels, training needs, and deployment of Service Control software. Naturally, these decisions also affect the cost of the design and deployment of the Service Control function. If necessary, an iterative loop with feedback may be useful in defining and costing this portion of the system.

Task 2119: Update Business Performance Model

The last block in Figure 3 calls for updating the business performance model 2119. To accomplish this, it is necessary to understand the performance and operational objectives previously defined. In a preferred embodiment, the a provider or manager will align the metrics and target service levels with performance provisions for batch Service Control and processing as outlined in service level agreements. Considerations may include a business performance model to define the overall design requirements for the Service Control capability. It is advantageous to keep the metrics as simple and straightforward as possible and to consider the Service Control infrastructure's suppliers and customers in defining the metrics.

After refining the business performance model 2110, the task of designing may proceed simultaneously along two or more tracks. One track focuses on the business aspects of the task, while the other focuses on technology. Thus, referring to Figure 2, function block 2410 calls for designing business processes, skills and user interactions, while block 3510 calls for analyzing the technology and infrastructure requirements.

Step 2410 - Design Business Processes, Skills & User Interaction:

In step 2410, the business processes, skills, and user interaction are taken into account, as shown in Figure 4. The step includes designing the new service control processes, and develops the framework and formats for service control. Figure 4 shows a representation of the tasks for carrying out these functions, according to the presently preferred embodiment of the invention. One task 2411 is to design workflows, or to create the workflows diagrams and define the workloads for all service control activities. Other tasks include defining the physical environment interactions 2412, identifying skills requirements for performing service control tasks 2413, defining application interactions, that is, the human-computer interactions necessary to fulfill key service control activities 2415. Still other tasks include identifying performance support requirements 2416, developing a capability interaction model 2417, and verifying and validating business processes, skills and user interaction 2419. Task 2411 : Design Workflows for Processes, Activities and Tasks

As part of the design or capability analysis stage 104, relationships are defined between core and supporting processes, activities, and tasks, and the metrics associated with the processes and activities are also defined. Considerations may include whether or not packaged software has already been selected for Service Control. If so, the business processes implied by that package or selection should be used. These should be the starting point for developing the process elements.

Once all requirements are defined, they are analyzed and detailed into specific activities and tasks. The activities will typically fall into four main categories: Direct support of end users - responding to user questions and issues, identifying solutions, escalating problems, and communicating solutions to users.

Trend/Problem analysis of incidents - analyzing Service Control events, identifying system problems that are causing common incidents, creating and communicating interim work-arounds, developing permanent solutions.

Knowledge Management - identifying and communicating new knowledge (e.g., applications, hardware, problem resolutions) to Service Control resources, as well as sharing knowledge (e.g., FAQs, common problems/resolutions) with customers.

Administrative functions - interfacing with Service Control management software to log event (service) tickets, track open tickets, close tickets, and solicit user feedback.

Task 2412: Define Physical Environment Interaction A next task is to define the physical environment interaction 2412. The objective of this task is to understand the implications of the Service Control processes on the physical environment; mainly this involves location, layout and equipment requirements. As part of the analysis, the provider will want to take into account a physical environment interaction model. Costing elements may include identifying the Workflow/ Physical environment interfaces, designing the facilities, layout and equipment required for Service Control, identifying distributed Service Control physical requirements, if any, as well as central needs.

Considerations may include the interaction that defines the layout and co-location implications of the Service Control workflows and the physical environment. In one embodiment, the physical layout should be semi-private space (low walls) that allow for knowledge sharing. The location of the service control function should also be considered. It may be best to locate it away from general users, sometimes setting up a single counter, if walk-up service is a requirement. If facilities or equipment are to be re-used, a prudent planner will confirm their condition and adequacy. Task 2413: Identify Skill Requirements

The next task for a comprehensive look at the design is to identify skill requirements 2413. The goal is to identify the skill and behavior requirements for performing Service Control tasks. The deliverables from this task may include both a role interaction model and skills definition. A planner or provider should identify critical tasks from the workflow designs, define the skills needed for the critical tasks and identify supporting skills needed and appropriate behavioral characteristics.

Considerations may include centralization or de-centralization of the service control function if the infrastructure or supported organization is widely distributed, and the mix of skills needed for remote rather than a centralized organization. The scope and breadth of services defined in prior tasks will also assist in determining the skill requirements for Service Control. Any information technology standards regarding hardware and software will constrain the specific skills needs. If the scope of the project covers basic

Service Control functions, skill requirements would normally include technical skills related to platform and support software, such as operating systems, network management software, print administration, groupware, voice software, etc. Application skills related to the installed or to-be-installed applications will also be required. This area may or may not be the responsibility of Service Control, and may be split up. In some embodiments, Service Control will have responsibility for custom-designed applications, and third party vendors will be contracted to support packaged application software. Business Process Skills related to the applications/business unit being supported will also be important considerations.

Valuable customer service skills that include all the skills (i.e., listening, interpersonal communication, etc.) necessary when communicating and working with customers. The depth of skills required in each area should also be considered, because the user service component of Service Control is usually stratified by level of skill in order to control costs and still provide the required performance levels. Whether this will be needed may affect the project-install cost. Task 2415: Define Application Interaction

The next task is to define application interactions 2415, or to identify the human-computer interactions necessary to fulfill key Service Control activities. This will most often involve identifying required Service Control features not supported by the Service Control software and defining the human-computer interactions needed to meet the requirements. It should be recognized that packaged software has a pre-defined application interaction. This task may only be performed for activities that are not supported by packaged software. All Service Control personnel will normally require familiarity with the tracking software in order to log incidents, track them while they are open, close them once they are complete, forward them to specialists as needed, or review and analyze incidents to identify underlying system problems.

Task 2416: Identify Performance Support Requirements Identifying performance support requirements 2416 is the next function block for the planner. The provider will want to analyze the Service Control processes and determine how to support human performance within these processes. The task is to analyze the critical performance factors for each Service Control task and to select a mixture of training and support aids to maximize workforce performance in completing each task. These can include

Service Control policies and detailed procedures, on-line help screens of various kinds, checklists, etc. If the design process is a change from a present system it is important to understand what has changed from the current processes, and use this to determine the support requirements. The delivery mechanisms should be carefully considered. For example, if a group of support items undergoes frequent changes, the support aid containing these items should probably be accessible on-line so it can be more easily maintained. Depending on the applications and other functions supported, Service Control performance support could entail a wide range of items. Policy and Procedure manuals and operations manuals on each application are normal requirements. A key feature of applications documentation would be a comprehensive list of error messages that can be generated and the common problems that cause each message to appear. While the planner of this invention is not meant for ongoing, operational costing, this analysis may be useful in designing a service control system that avoids mistakes and takes advantages of opportunities for improvement over an existing system. Another item that may be appropriate for capital expenditure is software that lets Service Control personnel obtain access to a user's computer and view what is appearing on the screen. This lets the Service

Control walk through a procedure with a user while the user is on the phone to determine what has gone wrong. Task 2417: Develop Capability Interaction Model

The next task is to develop a capability interaction model 2417. In this task, the provider will identify the relationships between the tasks in the workflow diagrams, the physical location, skills required, human-computer interactions and performance support needs. In one embodiment, a provider will develop a capability interaction model by understanding the interactions within each process for physical environment, skills, application and performance support, and unifying these models. The goal is an integrated interaction model that will integrate workflows, the physical environment model, role and skill definitions, the application interactions, and support requirements to develop the capability interaction models. At least one consideration is how the roles will be supported to maintain the Service Control capability.

Task 2419: Verify and Validate Business Processes, Skills and User Interaction

The final task of step 2410 is to verify and validate business processes, skills & user interaction 2419. A provider will want to verify and validate that the process designs and the Capability Interaction Models meet the Service Control requirements and are internally consistent. The end result is a business performance model that will help the design team and guide the project manager in both the technical and business aspects of the project. In one embodiment, a provider will use stakeholders in the Service Control domain and outside experts as well as the design teams to do the validation. Step 2710 - Design Organization Infrastructure: ln step 2710, the method includes defining the structures for managing human performance, and defining what is expected of people who participate in the service control function, the required competencies, and how performance is managed. Figure 6 shows a representation of the tasks for carrying out these functions, according to the presently preferred embodiment of the invention. After defining business processes, skills and user interactions, a provider may proceed to design an organizational infrastructure 2710. The design may define the structures for managing human performance and also define what is expected of people who participate in the Service Control function 2711 , the required competencies 2713, and how performance is managed 2715. Other tasks in this area will include organizational infrastructure mobilization 2717, or hiring, and lastly, to verify and validate 2719 that the organization is meeting service control needs.

Task 2711 : Design Roles, Jobs and Teams

The task will include the design for the roles, jobs and teams. As an example, the design may wrestle with the issue of whether the service control function will be centralized, distributed, and decentralized. Not only will this affect the capital costs, but it may also help to determine the reporting relationships and to identify the performance measurement factors. Service

Control roles and jobs will typically be based on the breadth of functions assigned. The Service Control organization structure should be designed around all these business requirements. In this particular portion of the design, it is easy to imagine that a central consideration is whether the organizational plan is simple, moderately complex, or complex, with anticipated capital costs to match.

Key issues for accomplishing service control include the scope of activities to be performed, geographic distribution of the function, the Service Control software tools selected, and the complexity of the environment. The process of defining both the skill requirements for Service Control and the locations for its resources will, in many cases, lead to a tiered structuring of the organization. Each tier, or level, will possess an increasing degree of skill, with tasks and responsibilities distributed accordingly. This may vary depending on specific requirements and availability of resources. The Service Control hours of operation can influence job and team design. Support will normally cover the organization's standard working hours. Added coverage, if provided, would normally be with reduced or skeleton staffing.

Task 2713: Design Competency Model After designing the roles and teams, the next task 2713 may be to design a competency model. In this task, the designer can define the skills, knowledge, and behavior that people need to accomplish their roles in the Service Control process. The goal of this task is a Competency Model for Skill/Knowledge/Behavior, that is, to determine the characteristics required of the individuals/teams that will fill the roles. Sub-tasks or portions may include defining the individual capabilities necessary for success in these roles. The manager may then organize the capabilities along a proficiency scale and relate them to the jobs and teams. Attitude and personality are factors that will impact the performance of Service Control personnel nearly as much as technical training and expertise.

Task 2715: Design Performance Management Infrastructure

These tasks define the people and teams that will perform in service control. The next task may be to design a performance management infrastructure 2715. The design here will define how individual performance will be measured, developed, and rewarded. There may be implications here on both the design and capital costs. The design here may also include determining a performance management approach and appraisal criteria. The goal of the design effort may be to deliver a performance management infrastructure or design, and to develop standards for individuals and teams involved in the Service Control process. If management wishes also to identify a system to monitor the individuals' and teams' ability to perform up to the standards, the infrastructure to accomplish this is desirably included "in the ground floor," that is, when the system is designed and the cost is determined, rather than later. Task 2717: Determine Organization Infrastructure Mobilization Approach

The next task of determining the organization mobilization approach 2717 may be necessary primarily if service control is a new function within an organization, or of course, if the organization itself is new. The function must be staffed, or put another way, the organization must determine an infrastructure mobilization approach 2717. This is not normally a factor in capital costs, since personnel tend to be ongoing expenses. However, any peculiarities or changes from a "standard" design should be considered when costing a project or establishing a budget. In any case, the project manager or designer may want to consider at some point how to mobilize the resources required to staff the new Service Control capability. For instance, if staffing is extraordinarily difficult or complex in a distributed or remote location, an alternate location or approach may be desirable.

In staffing, the manager should identify profiles of the ideal candidates for each position, identify the sourcing approaches and timing requirements, and determine the selection and recruiting approaches. Service Control is often a new function within the organization (i.e., new application area) or an expansion of current services supported. This may require working with temp agencies or recruiting to mobilize the organization.

Task 2719: Verify and Validate Organization Infrastructure

Once designed and costed, it may be prudent to verify and validate the organizational infrastructure 2719. The goal of this task is to verify and validate that the Service Control organization meets the needs of the Service Control capability and is internally consistent. A designer will want to confirm the organization with subject matter experts. The end result is that the designer will verify that the organization structure satisfies Service Control capability requirements.

Step 2750 - Design Performance Enhancement Infrastructure: In this step, a performance enhancement infrastructure is designed.

The method includes determining the training needed for new service control functions, and determining the on-line help text, procedures, job aids, and other information to be used. Figure 7 shows a representation of the tasks for carrying out these functions, according to the presently preferred embodiment of the invention. Functions include employee assessment 2751 , any performance enhancement needs 2753, investigation into performance enhancement products 2755, and verification and validation of the performance 2759.

Task 2751 : Assess Employee Competency and Performance.

In this task, the method includes refining the information about the current service control staff's competency, proficiency, and performance levels in specific areas, and assessing the gaps in competencies and performance levels that drive the design of the performance enhancement infrastructure. Preferably the method includes assessing the competency of the current service control staff based on the competency model previously developed.

Task 2753: Determine Performance Enhancement Needs

In this task, the method includes assessing the performance support and training requirements necessary to close the competency and performance gaps in the workforce. Preferably, the method includes using the employee assessment to determine the type of performance enhancement required to close the gaps and reach the desired competency levels.

The service control function requires communication, negotiation, and other management skills that do not lend themselves to one-time training and job aids. Performance enhancement in this case focuses on training needed by clerical and operations personnel to collect appropriate data and prepare service level reports as identified in the capability requirements analysis.

Task 2755: Design Performance Enhancement Products

In this task, the method includes defining the number and structure of performance support and learning products. Preferably, the method also includes determining the delivery approaches for training and performance support, designing the learning and performance support products, and defining the support systems for delivering training and performance support.

Data collection is a combination of automated and manual processes, which may require some knowledge of computer applications. Reporting may be via customized applications, or via spreadsheets in less complex environments. Due to part-time service control roles, job aids or desktop reminder systems are frequently the preferred approaches for performance support in this type of situation. When these situations arise, the performance enhancement infrastructure focuses on fairly training and support for the part-time function.

After considering available enhancement products, a manager may wish instead to design specific performance enhancement products 2755. If so, the method and cost may include defining the number and structure of performance support and learning products. The process should also determine the delivery approaches for training and performance support.

Specific tasks may include, but are not limited to, designing the learning and performance support products and defining the support systems for delivering training and performance support.

The scope of procedural training will be dependent on the requirements and activities set up for the Service Control function in the prior analysis and design tasks. In general, formal learning products should focus on how to access and use information, while performance support tools should focus on providing information at the point of need. This is especially true of the Service Control function, where there are a great number of information elements which can be placed "on the desktop" for rapid access and consultation. Two key elements usually found in a Service Control solution are the request tracking software and its accompanying request database, and the incident/problem historical database, which may also be referred to as a problem repository or knowledge repository.

Task 2757: Define Learning Test Approach

In this task, the method includes developing a comprehensive approach for testing the learning products with respect to achieving each product's learning objectives. Preferably, the method includes identifying which learning objectives are to be tested, and identifying the data capture methods to be used to test those objectives. With an idea of the needs and specific products in mind, the next step in a design may be to define a learning test approach 2757. The objective is to develop a comprehensive approach for testing the learning products with respect to achieving each product's learning objectives. The testing process will include identification of which learning objectives will be tested and identification of the data capture methods that will be used to test those objectives. One approach is to concentrate on learning objectives which focus on knowledge gain and relate directly to the Service Control Performance Model and Employee

Competency Model 2713.

Task 2759: Verify and Validate Performance Enhancement Infrastructure

In this task, performance enhancement infrastructure is validated. The method includes verifying the performance enhancement infrastructure and the learning test deliverables to determine how well they fit together to support the new service control capability. Preferably the method includes simulating the processes and activities performed by the members of the service control team in order to identify performance enhancement weaknesses. The method includes identifying the problems and repeating the appropriate tasks necessary to address the problems.

Technical Aspects

While the above sections have dealt with organizational aspects of the invention, it may now be appropriate to consider certain technical aspects.

This subject will pertain to the method shown in the lower left portion of Figure 2: studying how to analyze technology requirements 3510, selection and design of operations architecture 3550, and validating the choices for technology. When this portion is completed, the planning stages of the project for the project will be complete.

Step 3510 - Analyze Technology Infrastructure Requirements:

The first functional block 3510 is analyzing technology infrastructure requirements, and is shown in more detail in Figure 5. The step here is to prepare for the selection and design of the technology infrastructure and to establish preliminary plans for technology infrastructure product testing. The project deliverables here will include operations architecture component requirements, a physical model of the operations architecture, and a product test approach and plan. Other functions shown in Figure 5 include tasks of analyzing technology infrastructure requirements 3511 , analyzing component requirements 3515, and planning their tests 3517.

Task 3511 : Prepare Technology Infrastructure Performance Model The first task block is to prepare a technology infrastructure performance model 3511. The goal here is simple: analyze the functional, technical, and performance requirements for the Service Control infrastructure. In this task, the project manager or planner seeks to identify key performance parameters for Service Control, and to establish baseline project estimates, setting measurable targets for the performance indicators.

This phase of the project should also include developing functional and physical models, and a performance model as well.

The focus here is on the technology, and the goal should be to resolve all open issues as soon as possible, whether in this step or the next (selection and design 3550). Key issues for service control may include whether an automated system is required. If so, a good question for resolution is which software package may be best suited, given the key business criteria for the particular situation. If the organization has already purchased a Service Control package, this is a strong indicator for reuse. If the business capability requirements suggest a change to other software, a strong business case will be needed to support the recommendation.

Task 3513: Analyze Technology Infrastructure Component Requirements The next task 3513 is to analyze technology infrastructure component requirements. This portion of the project begins to get into hardware and software required, as the project manager analyzes and documents requirements for Service Control components, and defines additional needs. Tasks to be accomplished include identifying any constraints imposed by the environment and refining functional, physical, and performance requirements developed in the models previously built. In order to insure a "fit" with other aspects of the enterprise, the manager or planner should also assess the interfaces to other system components to avoid redundancy and ensure consistency/compatibility. Practical hardware and cost considerations may include, but are not limited to, automated tools common in Service Control environments, call handling software, which provides logging and tracking of incidents and problems, automated call distributor (ACD) software, which controls the routing of incoming calls to the various elements of Service Control, and perhaps even a Problems/Solutions database where routine problems and their solutions are stored to assist Service Control personnel in solving user problems.

Task 3515: Assess Technology Infrastructure Current Environment Once the components have been selected, the next task should be to assess the ability of the current service control infrastructure to support the new component requirements 3515. In one sense, this task is simply a system analysis step, in which a project manager or planner will consider the components described above in 3513, and see whether they are consistent with the desired infrastructure. The steps should include identifying current standards for technology infrastructure, and noting current standards and any gap in the analysis or the capability. Details desired may include documenting and analyzing the current Service Control technology environment. It is important to identify the areas where gaps exist between the current infrastructure and the new requirements.

It may be important for smooth functioning to note any organizational standards or policies regarding Service Control technology. Important for both system and cost considerations are any potential areas of reuse of current components. While not strictly a cost consideration, Service Control may interface with several other operations architecture components (i.e., event monitoring system, reporting tool) in managing a system, and any automated interactions involved here may impose constraints. Managers and planners will ideally be aware of constraints and limitations, in order to avoid repeating or re-doing work, or using the wrong infrastructure or components in planning the service control function.

Task 3517: Plan Technology Infrastructure Product Test Once the components and system are planned, the next task may be to plan a product test for the technology infrastructure 3517. The results of this task will provide the basis on which the product test will be performed as well as the environment in which it is run. The task includes defining the test objectives, scope, environment, test conditions, and expected results. Sub- tasks may include defining a product test approach, designing a product test plan, and generating a deployment plan. It is important to remember that service control is not an island, and that all elements of service control need to be implemented for this test. The organization served by service control may expect service, and may not be patient if some portions of service control are still being installed or tested prior to this product test.

Step 3550 - Select and Design Operations Architecture: After the infrastructure requirements have been analyzed, it is time for the step of selecting and designing operations architecture 3550, Figure 8. In this step, the manager will select and design the components 3551 required to support a high-level Service Control architecture; include re-use 3552, packaged 3553, and custom components 3555. After selection and design, the architecture is validated 3557. This is the module where a provider or a manager designs service control and formulates component and assembly test approaches and plans 3558.

Task 3551 : Identify Operations Architecture Component Options

A first task is to identify operations architecture component options 3551. It is important to identify specific component options that will be needed to support the production environment. Tools used in this task may include an Request for Proposal/ Request for Quotation (RFP/RFQ) approach with vendors, and a service control component summary for internal use. In this step the manager will be sure to identify all risks and gaps that exist in the current Service Control environment, select components that will support the Service Control architecture, and consider current software resources, packaged software and custom software alternatives during the selection process. If packaged software is part of the solution, the manager should submit RFPs to vendors for software products that meet basic requirements. Some packages can usually be eliminated quickly, based on such things as lack of fit with the operating system(s), server(s), or other operations architecture components already in place. Comparative analysis should be performed by prioritizing and ranking the requirements based on what is most important to the organization. It may be helpful to assign a numerical rating for how well each component option supports the given requirement (e.g. 0=does not support, 1 = partially supported, 2 = supported in full). A requirements matrix is helpful in completing this task.

Task 3552: Select Reuse Operations Architecture Components

A potentially useful task in costing and designing a system is whether one can select reuse operations architecture components 3552. If existing architecture components can be reused without extensive hardware, or more importantly, software changes, it may be possible to save on purchase and installation expense. This step should finalize the component selection and may be done in tandem with the package and custom tasks. The manager should evaluate component reuse options, determine gaps where (typically) software will not satisfy requirements, and select any components for reuse.

For future use, it may be desirable to document the findings with an evaluation summary and a component gap analysis.

Task 3553: Select Packaged Operations Architecture Components

This same analysis applied to "packaged" operations architecture components, where the project manager may wish to select packaged operations architecture components 3553, or custom components 3555. In the same manner described for architecture components, a manager may evaluate packaged component options or custom options against the selection criteria in order to determine the best fit. In both cases, the options should be considered, vendor demonstrations and site visits may be conducted.

Packaged software 3553 may well be the primary alternative for Service Control component requirements. The manager should make her or her selection is based on how well the options fit the requirements, the level of vendor support and cooperation, and cost factors. Organizational biases for or against particular products or vendors may be issues to be addressed. Site visits to other organizations using the software components are desirable to verify the vendors' claims of functionality and to obtain independent opinions about vendor support and cooperation.

Task 3555: Design Custom Operations Architecture Components

If custom-designed components 3555 are considered, then any custom components may have to be designed, rather than merely purchased. On the other hand, it may be possible to customize a reused or packaged component. There is usually more risk associated with custom components, if only because of the time constraints. Before deciding on custom components, a manger should evaluate the time, cost, and risk associated with custom development. This portion of the task may be reiterated as necessary until the manager or cost person is satisfied with the choices made.

Task 3557: Design and Validate Operations Architecture

Having selected the components needed by the enterprise, the next task may be to develop a high-level design for the architecture, or to design and validate an operations architecture 3557. This portion of the design is primarily concerned with combining the reused, packaged and custom components into an integrated design and ensuring that the selected architecture meets the requirements for service control of the enterprise. One portion of the task may be to define the standards and procedures for component building and testing. The manager may even consider prototyping if there are any complex interfaces to other components of the operations architecture. The end result of this task is to finish with a design for service control, complete with standards and procedures.

Task 3558: Develop Operations Architecture Component and Assembly Test Approach, and Plan With components and a system designed, a component and assembly test approach and plan 3558 is needed. In this task, the approach and test conditions for the Service Control Architecture Assembly, Component, and Component Acceptance Test Approaches and Plans are defined. The outputs may include separate plans for a test approach and plan for components, assemblies, and acceptance procedures. For each plan, there should be defined objectives, scope, metrics, a regression test approach, and risks associated with each test. Details may include component testing for the components selected above, whether new or reused.

To insure an integrated service control system, all components and interfaces are tested in an assembly stage. All customized software is tested in component and assembly stages. All interfaces of Service Control to other operations architecture software are tested in assembly testing. All automated features of the Service Control that will be used in the production environment are tested during assembly testing.

Step 3590 - Validate Technology Infrastructure: The next block in a technology portion of the method or cost planner a step wherein the manager validates the chosen technology infrastructure 3590, as shown in Figure 9. An analysis is undertaken of the service control design 3591 , the technology infrastructure is validated 3593, the infrastructure design is validated 3595, and the plans for deploying the system and its test approach are reviewed and revised as necessary 3597. The manager will verify that the Service Control design is integrated, compatible, and consistent with the other components of the Technology Infrastructure Design, and meets the Business Performance Model and Business Capability Requirements.

Task 3591 : Review and Refine Technology Infrastructure Design A first sub-task may be to review and refine the technology infrastructure design 3591. This task is undertaken to ensure that the Service Control infrastructure design is compatible with other elements of the technology infrastructure. The manager may want to ensure that the service control function is integrated and consistent with the other components of the technology infrastructure. It may also be prudent to develop an issue list, or "punch list" for design items that conflict with the infrastructure or items that don't meet performance goals or requirements. This "punch list" may be subsequently used to refine the Service Control infrastructure if needed.

Task 3593: Establish Technology Infrastructure Validation Environment

The next task in the design process may be to establish a technology infrastructure validation environment 3593. In this task, the manager designs, builds, and implements the validation environment for the technology infrastructure, and may deliver a validation schedule. Specific tasks may include establishing the environment, that is, the timing, and selecting and training participants. It may be useful in the validation task to include designers or architects of enterprise operations components which will interface with Service Control.

Task 3595: Validate Technology Infrastructure Design

Having established the environment, the next task is to validate the technology infrastructure design 3595. The manager at this point will desirably identify gaps between the design and the technology infrastructure requirements defined earlier. Projects will proceed smoothly if the manager will record issues as they arise during this phase for corrective action. The manager should also, during this phase, identify and resolve any remaining gaps between the design and the expectation or the required service. Part of the process is to iterate through the validation until all critical issues have been resolved and to develop action plans for less critical issues. If Service

Control is being installed as part of a larger business capability, this phase may serve as a checkpoint to verify that the most current requirements from the business capability release are being considered.

Task 3597: Analyze Impact and Revise Plans for Technology Infrastructure

The final task sub-block in the task of validating the technology infrastructure is to analyze the impact of the system and to revise plans 3597 as necessary. Tasks to be accomplished during this phase include analyzing the extent and scope of the work required for modifications and enhancements, analyzing the impact of validation outcomes on costs and benefits, and refining the plans for deployment testing. The point of this task is to update the appropriate technology infrastructure delivery plans based on the outcome of the validation process. Since the point of the information technology group is to service an enterprise, Service Control itself may only be part of the validation scope.

After completing the design phase 104, authorization 112 for proceeding to the build and test phase 106 is obtained. The project may proceed along three time-lines in the build and test portion 106 of Figure 2. One time-line continues in the technical vein, that is, acquiring the technology infrastructure 5510 and building and testing the selected operations architecture 5550. At the same time, other groups or personnel may develop learning products 6260 and other groups or personnel may develop policies, procedures and performance support 6220 for the new system. With these tasks completed, the project manager will proceed to prepare and execute a test of the new system, that is, a technology infrastructure product test 5590. With these tasks completed, all that remains is to deploy the new system 7170.

Step 5510 - Acquire Technology Infrastructure:

Acquiring the technology infrastructure 5510, Figure 10, is the first task in build and test. Tasks forming a part of this block include planning and executing the acquisition of components 5511 , which suppliers will supply the components and services 5513, and how they will be supplied. This task package is primarily required if new packaged software is to be procured and installed as part of the project. The economic impact or implications are evaluated 5515, and the organization prepares and executes acceptance tests 5517 for the new components.

Task 5511 : Initiate Acquisition of Technology Infrastructure Components.

The first task may be to initiate acquisition of the technology infrastructure components, primarily packaged software 5511. A "normal" procurement plan will suffice, so long as it includes RFP/RFQ documentation, defined vendor selection criteria, selecting from among the offering vendors, and so on. The process is smoothed if component capability and performance requirements are clearly defined in the documentation provided to vendors.

Task 5513: Select and Appoint Vendors

The next task may include selecting and appointing vendors 5513. The task may include evaluation of the several product offerings, negotiating contracts, and arranging for delivery and timing of delivery. It may be desirable if software training is negotiated as part of the contractual agreement. If multiple components and multiple vendors are involved, the project manager may find it advantageous to have delivery and installation of the components occur simultaneously so that the component interfaces can be tested with vendor representatives on site.

Task 5515: Evaluate Deployment Implications of Vendor Appointments

Having chosen vendors and arranged for delivery, the next task is to determine the impact and deployment implications of the software and vendor selection 5515 on the project economics and the enterprise served. The manager at this point may wish to compare procurement costs with project estimates, and assess the impact on the business situation. Revisions should be made and any approvals needed should be obtained. The manager should ensure that the economics of the transaction(s) are consistent with plan documentation, or changed as appropriate.

Task 5517: Prepare and Execute Acceptance Test of Technology

Architecture Components With these tasks completed, the next task is to prepare and execute an acceptance test of the new components 5517. In this task, steps are taken to ensure that the Service Control packaged components meet the technology infrastructure requirements. Personnel in this step build the test scripts, the test drivers, the input data, and the output data to complete the Technology Architecture Component Acceptance Test Model. They then execute the test and document any fixes or changes required of the component vendor(s).

Software component training may be scheduled and conducted as soon as the new Service Control components are installed.

Step 5550 - Build and Test Operations Architecture:

Having acquired the technology, the project now proceeds to a build and test step 5550 Build and Test Operations Architecture depicted in Figure 11. In this stage, personnel design and program the Service Control components, including extensions to reused and packaged items. This is also the time to perform component and assembly testing. Major tasks may include detailed design of the operations architecture 5551 , assembly test plan 5552, building of the system 5553, component tests 5555, and assembly and test 5557.

Task 5551 : Perform Operations Architecture Detailed Design

Detailed design should include the preparation of program specifications for custom and customized components. This task also desirably includes a design of the packaged software configuration, and detailed design reviews. Any software tool configurations should include customized reporting needs, creation of standard ACD interactive responses, and development of any standard data items needed in Call Handling for categorization and subsequent analysis of incidents to detect problems.

Task 5552: Revise Operations Architecture Component and Assembly, Test Approach, and Plan

If this task shows the need for any revisions, they should be accomplished when personnel revise the operations architecture component assembly test approach and plan 5552. This task includes updating the service control test plans to reflect the components' detailed design, and defining revised considerations or changes to the requirements. Preferably, the task includes reviewing the test approaches and plans, and revising as needed for new or updated requirements.

Task 5553: Build Operations Architecture Components

The project may then proceed to building the components 5553. In this task, personnel will build (or program) all custom service control components and extensions to packaged or reuse components. Some packages may have unique or proprietary languages for customizing or configuring. If so, there may be a need for training. In this task, the method includes building all custom service control components and extensions to packaged or reuse components. Preferably, the task includes building the custom components, building the customized extensions to package or reuse components, and configuring the packaged components.

Task 5555: Prepare and Execute Component Test of Custom Operations Components Having built the system, the next task is to prepare and execute tests of the custom operations components 5555. This testing will ensure that each custom Service Control component and each customized component meets its requirements. Retesting may be required in an iterative fashion until the design meets the system requirements. In one embodiment, personnel should confirm component performance as well as functionality. System performance should not be compromised by the amount of customization. The tests are not limited to this stage, but may proceed in subsequent testing tasks.

Task 5557: Prepare and Execute Operations Assembly Test Following component tests, the project engineer or manager then proceeds to prepare and execute an operations assembly test 5557. In this task, a full test is performed of all interactions between Service Control components. Personnel verify the assembly test model, set up a test environment, execute the test, and make fixes and retest as needed, again in an iterative fashion. Shell programs or stub programs may be needed to perform the assembly test. If shell programs are used, it is important to test not only successful completion, but to build in the error conditions which would cause abnormal endings or problems. Here, personnel verify that all interfaces to other components are tested and operate correctly for successful, predictable outcomes and error conditions. This completes the build and test stage.

Step 6220 - Develop Policies, Procedures and Performance Support: Having completed the technical aspects, the project manager now considers some longer-term portions of the project, the policies, procedures and performance support detailed design 6220, as shown in Figure 12, needed for ongoing operation of the service. The purpose of this task is to produce a finalized, detailed set of new Service Control policies, procedures, and reference materials. It is also desirable to conduct a usability test and review to verify ease of use with both service control personnel and personnel from the supported enterprise. Upon successful completion of this task, the operating personnel will have Service Control Policies & Procedures and may also have any performance support products that may be necessary or useful. Subtasks include writing or performing the policies and procedures 6221 , developing business policies and procedures 6223, user procedures 6225, reference materials and job aids 6227, and validating and testing 6229. Task 6221 : Perform Policies, Procedures and Performance Support Detailed Design

Subtasks include writing or performing the policies and procedures, and a detailed design of for performance support 6221. This task includes providing the product structure for all the new Service Control policies, procedures, reference materials, and job aids. It may also be desirable to provide templates for each product, and to create prototype products with reference to the overall project.

Task 6223: Develop Business Policies and Procedures It may also be necessary or desirable to develop a set of business policies and procedures 6223 for the operation. This is typically a rule set governing workflows and priorities. Business policies in this context describe the business rules governing workflows. Business procedures describe the sequential sets of tasks to follow based on the policies.

Task 6225: Develop User Procedures

This task includes drafting a detailed set of service control user procedures. User procedures provide the details necessary to enable smooth execution of new tasks within a given business procedure. Preferably, the task includes collecting and reviewing content information, drafting the procedures, verifying consistency with business policies and procedures, and planning for the production of the materials. Each business unit and each user may require its own unique user procedures. Since a number of clerical and management personnel may perform part-time tasks to achieve the objectives of service control, job aids and quick references are desirable performance support tools to supplement the user procedures.

Task 6227: Develop Reference Materials and Job Aids

Along with policies and procedures, it may be useful to develop reference materials and job aids for service control personnel 6227. In this task, any reference materials and job aids that make a task easier or more efficient are prepared. The information provided in the reference materials and job aids is typically difficult to memorize, but is used frequently on the job. Performance support materials for Service Control personnel should almost always be on-line rather than paper-based, due to the likelihood of frequent changes. As much material as possible should be incorporated into performance support tools, so that Service Control personnel can have ready access to information at their desktops for responding to users.

Task 6229: Validate and Test Policies, Procedures and Performance Support

Having accomplished these tasks for developing policies procedures and performance support materials, the project manager may now want to test and validate 6229 them. This task will include confirming that the products meet the requirements of the Service Control capability and the needs of the personnel who will use them. It is also useful as a follow-up tool to resolve open issues. Specific acts that may be useful in this vein include, but are not limited to, preparing validation scenarios, validating content and ease of use of materials, and testing on-line support products.

Step 6260 - Develop Learning Products: Though not strictly a part of project hardware building, a successful project will typically include some thought to training its users. Thus, an important task may include development of learning products 6260, as shown in Figure 13. A first step may include defining the needs for learning products and the environment in which they are to be used 6261. Technical training in Service Control software components may come from the package vendor or a third party training organization. Procedural training for an organization's procedures is often custom built or tailored for the situation. After learning these requirements, the next steps are to perform a learning program detailed design 6263 and to make prototypes 6265. Using the prototypes, actual learning products may then be made, and produced 6267. The products should be tested 6269. Testing may take place later in the cycle, as depicted in Figure 13, or earlier, using prototypes, to achieve feedback and ensure the effort is on track and useful to the students or trainees.

Task 6261 : Develop Learning Product Standards and Development Environment

This task includes creating the environment for developing the service control learning products. Preferably, the task includes selecting authoring and development tools, defining standards, and designing templates and procedures for product development. Technical training in service control software components may come from the package vendor or a third party training organization. Procedural training may be custom built.

Task 6263: Perform Learning Program Detailed Design

This task includes specifying how each learning product identified in the learning product design is developed. Preferably, the task includes defining learning objectives and context, designing the learning activities, and preparing the test plan. Where service control data collection and reporting are supported by other components of the operations architecture or the application itself, training in those components may be necessary. The available learning products for those components are used when possible to cover the service control interfaces, since custom training for what are often part-time responsibilities may not be cost effective. Because of the part-time aspect of the work, job aids and other performance support means are used in lieu of formal training

Task 6265: Prototype Learning Products

This task includes completing prototypes and conducting ease-of-use sessions on classroom-based learning components (i.e., activities, support system, instructor guide). Preferably, the task includes creating the prototype components, and conducting and evaluating the prototype.

Task 6267: Create Learning Products

This task includes developing the learning materials proposed and prototyped during the design activities. Preferably, the task includes developing activities, content, and evaluation and support materials required, developing a maintenance plan, training instructors/facilitators, and arranging for production.

Task 6269: Test Learning Products This task includes testing each product with the intended audience to ensure that the product meets the stated learning objectives, that the instructors are effective, and that the learning product meets the overall learning objectives for service control. Preferably, the task includes confirming the Test Plan, executing the learning test, and reviewing and making required modifications. If the target audience is small, this test serves as the formal training session for the group. Multiple sessions may be appropriate if responsibilities are split and all personnel are not responsible for knowing all activities.

Step 5590 - Prepare and Execute Technology Infrastructure Product Test: At this point, much of the project work has been completed, and the product is ready for testing in a realistic environment 5590 to insure it is ready for deployment. A series of tests is depicted in Figure 14. The test and its design or model are first prepared 5591 , with expected results. The test is then performed 5593, by executing the tests prepared earlier. The tests should simulate actual working conditions, including any related manuals, policies and procedures produced earlier. An objective of the test should be to notice any deficiencies and make changes as required.

Following these tests, a deployment test should be executed 5595, to ensure that the service control infrastructure can be gainfully deployed within the enterprise or organization. If this test is successful, the last stage of testing may then be executed, the technology infrastructure configuration test 5597. This test will ensure that the performance of the Technology Infrastructure, including Service Control, will be consistent with the Technology Infrastructure Performance Model after the infrastructure has been deployed. The test should be made with an eye to risk assessment of the integration of the new system within the enterprise, and the risk assessment should be updated as needed.

Task 5591 : Prepare Technology Infrastructure Test Model

This task includes creating the service control infrastructure test model. Preferably, the task includes creating the test data and expected results, creating the testing scripts for production, deployment, and configuration tests. The task also includes conducting the service control training not yet completed, and reviewing and approving the test model. If a complete business capability is being deployed, this is a comprehensive test with service control being one piece. The product test should occur in a production-ready environment and should include the hardware and software to be used in production.

Task 5593: Execute Technology Infrastructure Product Test

This task includes verifying that the technology infrastructure successfully supports the requirements outlined in the business capability design stage. Preferably, the task includes executing the test scripts, verifying the results, and making changes as required.

Task 5595: Execute Technology Infrastructure Deployment Test

In this task, the provider or manager ensures that the new service control infrastructure is correctly deployed within the organization. Preferably, the task includes executing the test scripts, verifying the results, and making changes as required.

Task 5597: Execute Technology Infrastructure Configuration Test

This task includes ensuring that the performance of the technology infrastructure, including service control, is consistent with the technology infrastructure performance model after the infrastructure has been deployed. Preferably, the task includes executing the test scripts, verifying the results, making changes as required, and updating the risk assessment.

After completing the build and test phase 106, a milestone 114 is reached, as to whether or not to deploy the service control function which has been built and tested. If approval is given, the project proceeds, and the deployment phase 108 is commenced.

Step 7170 - Deploy Technology Infrastructure:

Following successful testing, the service control infrastructure may be deployed online 7170, Figure 15. At this point, the tasks remaining may include configuring the technology infrastructure 7171 to prepare for any new business capability components. This step will generally be required if the Service Control capability is being deployed at more than one site (i.e., individual desktops or multiple servers). In these cases, variances in the existing configurations will determine any customization required. If the configuration is complete, the technology infrastructure may then be installed 7173. In addition to the

Service Control software, all documentation, performance support tools and training must be completed and in place prior to the deployment. A final task may be to verify the technology infrastructure 7179 and address any issues raised as a result of the testing or the deployment. Customers and service control members, as well as enterprise management should be kept abreast of developments, successful and less successful, so all issues can be resolved quickly. This task should require minimal effort if Service Control is being installed independently.

Task 7171 : Configure Technology Infrastructure This task includes customizing the deployment unit's technology infrastructure to prepare for the new business capability components.

Preferably, the task includes reviewing the customization requirements, performing the customization, and verifying the infrastructure configuration.

Customizing the infrastructure is normally completed in task package 5550, build and test operations architecture.

Task 7173: Install Technology Infrastructure

This task includes installing the technology infrastructure for service control. Preferably, the method includes preparing installation environment, installing service control infrastructure, and verifying the installation. In addition to the service control software, the documentation, performance support and training tools are completed and put in place prior to the deployment.

Task 7179: Verify Technology Infrastructure

This task includes verifying the new technology infrastructure environment and addressing the issues raised as a result of the testing.

Preferably, the task includes performing the infrastructure verification, making changes as required, and notifying stakeholders. A follow-up audit is recommended after some period of production operations to confirm the validity and accuracy of service reports.

ESTIMATOR

In addition to the method for providing the service control function, as described above, the present invention also includes a method and apparatus for providing an estimate for building a service control function in an information technology organization. The method and apparatus generate a preliminary work estimate (time by task) and financial estimate (dollars by classification) based on input of a set of estimating factors that identify the scope and difficulty of key aspects to the system.

Previous estimators only gave a bottom line cost figures and were directed to business rather than OM functions. It would take days or weeks before the IT consultant produced these figures for the client. If the project came in either above or below cost, there was no way of telling who or what was responsible. Therefore, a need exists for an improved estimator

Fig. 16 is a flow chart of one embodiment a method for providing an estimate of the time and cost to build a service control in an information technology organization. In Fig. 16, a provider of a service control system, such as an IT consultant, for example, Andersen Consulting, obtains estimating factors from the client 202. This is a combined effort with the provider adding expertise and knowledge to help in determining the quantity and difficulty of each factor. Estimating factors represent key business drivers

Table 1

for a given operations management OM function. Table 1 below lists and defines the factors to be considered along with examples of a quantity and difficulty rating for each factor.

For example, as an illustration of the method of the invention, the provider, with the help of the client, will determine an estimating factor for the number of current roles 202. Next comes the determination of the difficulty rating 204. Each of these determinations depends on the previous experience of the consultant. The provider or consultant with a high level of experience will have a greater opportunity to determine the correct number and difficulty. The number and difficulty rating are input into a computer program. In the preferred embodiment, the computer program is a spreadsheet, such as EXCEL, by Microsoft Corp. of Redmond, Washington, USA. The consultant and the client will continue determining the number and difficulty rating for each of the remaining estimating factors 206.

After the difficulty rating has been determined for all of the estimating factors, this information is transferred to an assumption sheet 208, and the assumptions for each factor are defined. The assumption sheet 208 allows the consultant to enter in comments relating to each estimating factor, and to document the underlying reasoning for a specific estimating factor. Next, an estimating worksheet is generated and reviewed 210 by the consultant, client, or both. An example of a worksheet is shown in FIGS. 17a,

17b, and 17c. The default estimates of the time required for each task will populate the worksheet, with time estimates based on the number factors and difficulty rating previously assigned to the estimating factors that correspond to each task. The amount of time per task is based on a predetermined time per unit required for the estimating factor multiplied by a factor corresponding to the level of difficulty. Each task listed on the worksheet is described above in connection with details of the method for providing the service control function. The same numbers in the description of the method above correspond to the same steps, tasks, and task packages of activities shown on the worksheet of FIGS. 17a, 17b, and 17c. The worksheet is reviewed 210 by the provider and the client for accuracy. Adjustments can be made to task level estimates by either returning to the factors sheet and adjusting the units 212 or by entering an override estimate in the 'Used' column 214 on the worksheet. This override may be used when the estimating factor produces a task estimate that is not appropriate for the task, for example, when a task is not required on a particular project.

Next, the provider and the client review and adjust, if necessary, the personnel time staffing factors for allocations 216 for the seniority levels of personnel needed for the project. Referring to FIGS. 17a, 17b, and 17c, these columns are designated as Partner - "Ptnr", Manager - "Mgr", Consultant -

"Cnslt", and Analyst - "Anlst", respectively. These allocations are adjusted to meet project requirements and are typically based on experience with delivering various stages of a project. It should be noted that the staffing factors should add up to 1. The consultant or provider and the client now review the workplan 218, and may optionally include labor to be provided by the client. In one embodiment, the workplan contains the total time required in days per stage and per task required to complete the project. Tasks may be aggregated into a "task package" of subtasks or activities for convenience. A worksheet, as shown in FIGS. 17a, 17b, and 17c, may be used, also for convenience. This worksheet may be used to adjust tasks or times as desired, from the experience of the provider, the customer, or both.

Finally, a financial estimate is generated in which the provider and client enter the agreed upon billing rates for Ptnr, Mgr, Cnslt, and Anlst 220.

The total estimated payroll cost for the project will then be computed and displayed, generating final estimates. At this point, a determination of out-of- pocket expenses 222 may be applied to the final estimates to determine a final project cost 224. Preferably, the provider will then review the final estimates with an internal functional expert 226.

Other costs may also be added to the project, such as hardware and software purchase costs, project management costs, and the like. Typically, project management costs for managing the provider's work are included in the estimator. These are task dependant and usually run between 10 and 15% of the tasks being managed, depending on the level of difficulty. These management allocations may appear on the worksheet and work plan. The time allocations for planning and managing a project are typically broken down for each of a plurality of task packages where the task packages are planning project execution, organizing project resources, controlling project work, and completing project, as shown in FIGS. 17a, 17b, and 17c.

It will be appreciated that a wide range of changes and modifications to the method as described are contemplated. Accordingly, while preferred embodiments have been shown and described in detail by way of examples, further modifications and embodiments are possible without departing from the scope of the invention as defined by the examples set forth. It is therefore intended that the invention be defined by the appended claims and all legal equivalents.

While this invention has been shown and described in connection with the embodiments described, it is apparent that certain changes and modifications, in addition to those mentioned above may be made from the basic features of this invention. Many types of organizations may benefit from the use of this invention, e.g., any organization wishing to use a service control system within an information technology system. In addition, there are many different types of computer systems, and computer software and hardware, that may be utilized in practicing the invention, and the invention is not limited to the examples given above. Accordingly, it is the intention of the applicants to protect all variations and modifications within the valid scope of the present invention. It is intended that the invention be defined by the following claims, including all equivalents.

Claims

1. A method for providing a service control function in an information technology organization, comprising:

(a) planning for said service control; (b) designing said service control;

(c) building said service control;

(d) testing said service control; and

(e) deploying said service control.

2. The method of claim 1 wherein said planning act includes: (f) developing a business performance model for said service control function.

3. The method of claim 2 wherein said developing act includes: (g) confirming business architecture;

(h) analyzing a plurality of operating constraints; (i) analyzing a current service control capability;

(j) identifying a plurality of best practices for said service control;

(k) defining a plurality of requirements for said service control; and (I) developing said business performance model.

4. The method of claim 1 wherein said designing act includes:

(f) designing business processes, skills, and user interaction for said service control system.

5. The method of claim 4 wherein said step (f) includes: (g) designing a plurality of workflows for processes, activities, and tasks for said service control;

(h) identifying physical environment interactions; (i) identifying skill requirements for performing said service control; (j) defining application interactions; (k) identifying performance support requirements; (I) developing a capability interaction model; and (m) developing said business processes, skills, and user interaction.

6. The method of claim 1 wherein said designing act includes: (f) designing an organization infrastructure for said service control.

7. The method of claim 6 wherein said step (f) includes: (g) designing a plurality of roles, jobs, and teams; (h) designing a competency model; designing a performance management infrastructure;

G) determining an organization infrastructure mobilization approach; and

(k) developing said organization infrastructure.

8. The method of claim 1 wherein said designing act includes:

(f) designing a performance enhancement infrastructure for said service control.

9. The method of claim 8 wherein said step (f) includes:

(g) assessing employee competency and performance for a service control organization;

(h) determining performance enhancement needs;

(i) designing performance enhancement products;

(j) defining a learning test approach; and

(k) developing said performance enhancement infrastructure.

10. The method of claim 1 wherein said designing act includes: (f) designing a technology infrastructure for said service control.

11. The method of claim 10 wherein said step (f) includes:

(g) preparing a technology infrastructure performance model; (h) analyzing a plurality of technology infrastructure component requirements;

(i) assessing a current technology infrastructure;

(j) developing a technology infrastructure design; and (k) planning a technology infrastructure product test.

12. The method of claim 1 wherein said designing act includes:

(f) designing operations architecture for said service control.

13. The method of claim 12 wherein said step (f) includes:

(g) identifying operations architecture components; (h) selecting reuse operations architecture components;

(i) selecting packaged operations architecture components; (j) designing custom operations architecture components; and

(k) designing the operations architecture.

14. The method of claim 10 wherein said testing act includes:

(g) validating said technology infrastructure for said service control.

15. The method of claim 14 wherein said validating act includes: (h) reviewing said technology infrastructure; (i) establishing an environment for validating said technology infrastructure;

(j) validating said technology infrastructure; and (k) analyzing an impact of said technology infrastructure.

16. The method of claim 14 wherein said building act includes: (h) acquiring a plurality of technology infrastructure components for said service control function.

17. The method of claim 16 wherein said acquiring act includes: (i) defining acquisition criteria;

(j) selecting vendors for said technology infrastructure components; (k) appointing said vendors;

(I) evaluating deployment implications of said selecting and appointing; and

(m) testing said technology infrastructure components for acceptance.

18. The method of claim 13 wherein said building act includes: (I) building said operations architecture components.

19. The method of claim 18 wherein said testing act includes: (m) testing said operations architecture components; and (n) testing said operations architecture.

20. The method of claim 1 wherein said building act includes: (f) developing policies, procedures, and performance support for said service control.

21. The method of claim 20 wherein said developing act includes: (g) developing business policies and procedures;

(h) developing user procedures;

(i) developing reference materials and job aids; and

(j) validating said policies, procedures, and reference materials.

22. The method of claim 1 wherein said building act includes:

(f) developing learning products for said service control.

23. The method of claim 22 wherein said developing act includes:

(g) developing learning products standards; (h) prototyping said learning products; (i) building said learning products; and

(j) testing said learning.

24. The method of claim 16 wherein said testing act includes: (i) testing said technology infrastructure for said service control.

25. The method of claim 24 wherein said step (i) includes:

(j) preparing a plurality of test models for said technology infrastructure;

(k) executing a technology infrastructure product test; (I) executing a technology infrastructure deployment test models; and

(m) executing a technology infrastructure configuration test model.

26. The method of claim 24 wherein said deploying act includes: (j) deploying said technology infrastructure for said service control.

27. The method of claim 26 wherein said step (j) includes: (k) configuring said technology infrastructure;

(I) installing said technology infrastructure; and (m) verifying said technology infrastructure.

28. A method for providing an estimate for building a service control function in an information technology system, the method comprising:

(a) obtaining a plurality of estimating factors;

(b) determining a difficulty rating for each of said estimating factors;

(c) generating a time allocation for building said service control based on said estimating factor and said difficulty rating; and

(d) generating a cost for building said service control based on said time allocation.

29. The method as recited in claim 28, wherein obtaining said estimating factor further includes receiving said estimating factors from a client.

30. The method as recited in claim 28, wherein said estimating factors include the number of at least one of acquired components, current service desks, current roles, current services, future service desks, future roles, new personnel, new services, personnel, services, software components, and vendors.

31. The method as recited in claim 28, wherein said difficulty rating is selected from the group of simple, moderate, or complex.

32. The method as recited in claim 28, wherein said time allocation includes time allocated for a plurality of individual team members where said individual team members include at least one of partner, manager, consultant, and analyst.

33. The method as recited in claim 28, wherein said cost depends on said time allocation and a billing rate for said individual team member.

34. The method as recited in claim 28, wherein said cost is broken down for each of a plurality of stages for building said service control where said stages include at least one of plan and manage, capability analysis, capability release design, capability release build and test, and deployment stages.

35. The method as recited in claim 28, wherein said time allocation is used to generate a project work plan.

36. The method as recited in claim 28, wherein said billing rate generates a financial summary of said cost.

37. The method as recited in claim 35, wherein said work plan is broken down for each of a plurality of stages for building said service control where said stages are plan and manage, capability analysis, capability release design, capability release build and test, and deployment.

38. The method as recited in claim 37, wherein said plan and manage stage is broken down for each of a plurality of task packages where said task packages are plan project execution, organize project resources, control project work, and project complete.

39. A computer system for allocating time and computing cost for building a service control function in an information technology system, comprising:

(a) a processor;

(b) a software program for receiving a plurality of estimating factors and difficulty rating for each of said estimating factors and generating a time allocation and cost for building said service control function;

(c) a memory that stores said time allocation and cost under control of said processor.