WO2001026028A1 - Method and estimator for providing change control - Google Patents

Abstract

A method for providing change control in an information technology organization includes the tasks involved in building the change control function including planning (110), building (5550), testing (5590), and deployment (7170) of change control. Each task includes process, organization, and technology infrastructure elements.

Description

METHOD AND ESTIMATOR FOR PROVIDING CHANGE 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 modem 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 organization. A single IT Framework should represent all functions operative in an IT organization. Within the IT Framework, there is also a need for a change control function that plans, manages, schedules and coordinates all changes to the information technology environment.

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 of the invention is a method for providing a change control function in an IT organization that includes planning, designing, building, testing, and deploying the change control function. The method includes developing a business performance model for a planning phase of providing change control. The method preferably includes designing business processes, skills, and user interaction for the design phase. The method further includes designing an organizational infrastructure and a performance enhancement infrastructure for change control. The method also includes designing technology infrastructure and operations architecture for the design phase of change control.

In the building phase of the method, the technology infrastructure and the operations architecture is built. Also business policies, procedures, performance support, and learning products for change control are built. In the testing phase, the technology infrastructure and the operations architecture for change control are tested. In the deploying phase, the technology infrastructure for the IT organization is deployed. Another aspect of the present invention is a method for providing an estimate for building a change control function in an information technology organization. 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 break down 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 change control function in an information technology organization.

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 operation management change control functions.

Figure 2 shows a representation of a method for providing change 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 change control.

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

Figure 7 shows a representation of a task for designing a performance enhancement infrastructure for change control. Figure 8 shows a representation of a task for designing operations architecture for change control.

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

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

Figure 11 shows a representation of a task for building and testing operations architecture for change control.

Figure 12 shows a representation of a task for developing business policies, procedures, and performance support architecture for change control. Figure 13 shows a representation of a task for developing learning products for change control.

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

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

Figure 16 shows a flow chart for obtaining an estimate of cost and time allocation for a project.

Figures 17a and 17b show one embodiment of an estimating worksheet for a change control estimating guide.

DETAILED DESCRIPTION OF THE INVENTION

For the purposes of this invention, an information technology ("IT") enterprise may be considered to be a business organization, charitable organization, government organization, etc. that uses an information technology system with or to support its activities. An IT organization is the group, associated systems and processes within the enterprise that are responsible for the management and delivery of information technology services to users in the enterprise. In a modern IT enterprise, multiple functions may be organized and categorized to provide comprehensive service to the user. Thereby, an information technology framework for understanding the interrelationships of the various functionalities, and for managing the complex IT organization is provided.

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 system; a service delivery function, a capability development function; a change administration function; a strategy, architecture and planning function; a human performance management function; a management and administration function; and a governance and strategic relationships function. Within the change administration function, change control plays an important role. The present invention includes a method for providing a change control system for an information technology organization.

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

Change control is the process by which operations development and business process areas communicate, implement and document changes in the environment. Change control allows the impact of the change to be assessed along with the merits, timeframes, and so on. Change control monitors the change process to make sure that changes are delivered according to established plans. The change control function or organization monitors the change process to make sure that changes are delivered according to established plans. Change control also finalizes release planning and provides communications to end users concerning the change process. Finally, the change control function is responsible for rationalizing multiple change requests against each other to determine what changes should actually be implemented. In one embodiment as depicted in Figure 1 , the scope of Change Control 51 includes three organizations, Change Planning 511 , Change Communications 512, and Migration Control 513.

Change planning addresses how all changes are handled, coordinated, implemented, and documented in both production and development environments. Change planning coordinates the release of updates to the IT environment and defines the requirements for the change (i.e., a new version of software, data, user procedures, training, or support materials). A release is defined as maintenance changes to an application, operating system, or firmware that are made prior to the readiness of a version change to be sent to a user. An upgrade is defined as a maintenance change to hardware that is being made prior to a model change. After a release or upgrade has been tested, it is then ready to be deployed (or "rolled out") to the end user community. A desirable part of the change plan is to conduct an analysis to identify the change type (i.e., emergency fix release or planned release), change priority (severity level), and change category or contents of the change package (i.e., hardware, application software, web content, system software, data, configuration parameters). A change plan includes a Contingency and Backout Plan, and is linked to the Change Communication process in order to inform/include all appropriate parties. The Change Control Committee members are the central point of contact for these base practices.

A group or function for change request creation collects and documents all information pertaining to the change request and logs it into the Change Control tracking tool. Completed change requests include the following information:

• Date - when a Service Request has been raised, accepted, rejected, deferred or implemented

• Change Category • Change Type (i.e., permanent, temporary, emergency, etc.)

• Change Priority - Critical, High, Medium

• Implementation Date • Description of Change

• Reason for change

• Areas Affected (departments, files, directories, hardware, software web content, etc., that may be affected by the proposed change) • Special Instructions - if applicable

• Any approvals required

The request for change should include change, contingency, backout, testing, and training plans as well as installation documentation, and change/release documentation.

A group or function for change request logging and characterization logs requests into the system. The group confirms that the request is complete and all information is accurately categorized. The group reviews the change request for completeness and accuracy. All change requests are forwarded to the Change Coordinator who reviews them for completeness. If additional information is needed, the Change Coordinator will send the Change Request back to the requester and/or the appropriate support group. If the request information is complete, the Change Coordinator will begin the approval process. In order for a Change Request to be considered, all required information is entered on the Change Request Form.

A change impact analysis group performs an impact analysis for a change to determine if the change is an emergency or planned. Change requests need to be analyzed in order for the impact to be fully realized and prioritized for resource purposes. The analysis may be based on such things as cost, performance, resources, organization, timeframes, network configuration, or architecture issues. A related but distinct function or group is change criticality. Change criticality determines the criticality or importance of the change. Changes can be classified as standard changes that are reviewed on a regularly scheduled basis and are planned and implemented during an "official" change maintenance window. Changes may also be classified as urgent, but whose implementation cannot wait for review at a regularly scheduled change maintenance window. Other functions may include change approval, charged with approving a change request. Authority to proceed with a change request can come from various sources, depending on the type of change. A change effort group determines the effort required to implement the change. A group for change request milestones identifies dependencies and critical milestones for the change request. A group for change request prioritization prioritizes a change request against outstanding change requests, as change requests may come from multiple sources. The enterprise desirably copes with not only varying types of change, but varying urgencies as well. A release planning function coordinates the functions required to release a new version of any combination of software, data, user procedures, training, or support materials. This group or function determines what will change, the timeframes for the change, and defines the testing and fallback/contingency approaches for a release according to the agreed upon SLAs. The overall release plan is then agreed upon and documented by the appropriate parties.

The final group or function in change planning is change scheduling, handled by a change scheduling group. This group creates the master schedule for changes to the environment. The group tracks status and ensures that the change requirements are synchronized to minimize the risk associated with changing the information technology environment.

The next function, change communications, has several sub-groups or functions. Change communications informs all affected parties on the status of planned and unplanned changes to the information technology environment before scheduling the changes and after the changes have taken place. As part of change communications, change communications management directs, coordinates, and monitors the communication activities required to implement an information technology change into the production environment. The communications plan for the change will be designed and documented. It has also been found useful to include a function for change schedule confirmation, which verifies that change notifications are consistent with the information contained in the master schedule for changes and communications plan, and that the change contact list is current and correct. A change schedule update function involves tracking all modifications or alterations to a change that affect the implementation schedule. This involves updating the master schedule for changes and notifying the change contact list. A related but distinct function is change schedule reporting, which ensures that the progress or status of a change request is communicated to the change contact list according to the communications plan. Reporting is additionally responsible for change status categories, change requests, etc. Change status categories are defined as:

• New - the change request has been submitted and is awaiting review by the change control board

• Pending - the change request has not been submitted with all required information

• Reviewed - the change request has all required information and will be presented at the next change control board meeting • Denied - the change request was not approved in the change control board

• Approved - The groups/individual(s) responsible for executing the change have received the approval and the change has been scheduled

• Aborted - execution of the change request failed • Completed - execution of the change request was successful

• Closed - the completed change request that did not experience problems has been reviewed by the change control board, and the appropriate configuration information has been updated

• Closed with exception - the completed change request that experienced problems that were fixed has been reviewed by the change control board, and the appropriate configuration information has been updated.

Change request reports may be categorized by request number, by role (initiator, manager, controller, etc.), by status, by priority, by due date, by category, by environment, or as desired. A function for change schedule dissemination notifies all affected parties before a change is initiated according to the communications plan. Change notifications are completed prior to any change. Notifications should be given with enough advance notice so affected parties may plan accordingly. The last function in change control communications is change schedule feedback. This group reports the results (success, failure, change production metrics data, etc.) of the change once it is in the production environment and initiates appropriate action as needed.

Migration control coordinates the movement and maintains the integrity of a release package while in the development and testing environments, before a change is ready to be deployed to a production environment. Besides its main function, migration control contains several other sub-groups or functions. Migration control ensures smooth handling of changes from test environments to staging locations for subsequent release packaging and deployment. In order to do this, Migration Control ensures that the proper updates are received from development, versioned accordingly, and moved into the test environment after the pre-release tests have been successfully completed. Migration Control is implemented to maintain integrity of ail master release packages and ensure version control on releases. Examples of a release package include software, data, procedures, and support materials.

A highly desirable function of migration control is to ensure the integrity of code for the purposes of version control. Migration control also controls the development of all components to ensure new capability development stays on schedule to deploy the new/enhanced capability. Migration control is used in Application Management as well as Capability Development. Note that Migration does not include Operability Testing. Strong security measures are also taken in the migration control function to ensure that the number of people who can make changes to production are minimized and that adequate separation of duties exists.

One group or function within migration control is release package assembly. This group bundles the requirement components of a release, and ensures that it is correct and complete. Assurances are made that the tools, testing, software, space, and version control are in place before a package is released. A release assembly kit function or group identifies all components that are required for release and installation, including proper documentation, instruction kit, interfaces, links, etc. Release package integrity ensures that the changes in the enterprise environment are synchronized in order to ensure a successful change/release. Master releases should be processed from development, through testing, to production in a like manner to ensure the integrity of all releases. Migration control also includes a group or function for version control implementation. This group ensures that the multiple entities that make up the release package are versioned and controlled. Version control on releases allows for software to be documented thoroughly. Change requests, environment, description, responsible programmer, migration date, problems, and status should be noted for all versions via Change Control personnel.

Successful release package release confirmation ensures that tested release packages are stored prior to release. Releases will be tested and confirmation will be noted on the version control documents as to the tester, status, comments, etc. This group is additionally responsible for assigning dates and storing a release until the actual deployment.

Release packaging migration notification ensures that access to tested releases for distribution to the production environment are available to those who require access. Multiple releases can be dependent and need to be deployed in sync and require that users, programmers, and other departments be informed. Deployment and/or Software & Data Distribution personnel are notified of the release status so they can schedule appropriately for possible system unavailability, etc. Migration library maintenance ensures housekeeping is performed on migration libraries. Libraries are maintained for backout and backup purposes. This ensures that copies of releases are available for any future use, along with supporting documentation that thoroughly describes changes, status, programmers, and owners of release.

A group or function for change backout and contingency planning ensures that backout plans and contingency plans are in place in the event that problems arise. Courses of actions are outlined to reverse change or to serve as alternative methods of achieving desired outcome, in the event of unpredicted consequences. A contingency plan is defined as a detailed plan that explicitly describes the actions that will be taken to correct any problems to the existing information technology environment that may be caused by the implementation of the change. Implementing a contingency plan repairs any damage that may have been caused by the intended change. Conversely, a backout plan is a detailed plan that explicitly describes the actions that will be taken to undo the change, should a problem be encountered when implementing the change. Implementing a backout plan removes the change to the environment.

Change reporting reports on changes made to the operations environment as well as changes put on hold, cancelled, etc. Change reporting generates monthly reports detailing the status of change requests, and in one embodiment, notes completed as well as pending changes.

METHOD FOR PROVIDING CHANGE CONTROL

According to the present invention, the method for providing Operations Management ("OM") change 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. 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 o 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.

Change Control delivery and deployment focuses on a new or enhanced business capability. One of the key steps in defining business and performance requirements is to determine the overall effect of changes on the information technology organization and the enterprise which IT serves. While Change Control personnel may be responsible for performing other OM functions in the organization, this set of change task packages is limited to analysis of functions which are nearly always associated with Change Control. They include change planning, change communications, and migration control.

Step 2110 - Refine Business Performance Model

In step 2110, the business model requirements for change 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 2111 , 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 2111 assesses the current business architecture, confirming the goals and objectives, and refining the components of the business architecture. 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 project, change control should review any planning stage documentation, confirm or refine the overall change control architecture, and ensure management commitment to the project and the potential costs involved. Change control terminology can mean different things in different organizations; define and clarify terms carefully with the sponsor to ensure all parties understand the scope. In order to respond to business requirements there might be multiple categories of changes, for example:

New capability, such as new applications or hardware components. - Modification, which can change functionality, improve performance, etc.

Maintenance, typically to correct errors. Emergency, which require immediate attention and correction/implementation. As shown in Figure 1 , change control consists of three major activities:

Change Planning, Change Communications, and Migration Control. Change Planning 511 is the process of managing change requests throughout their life cycle. Software packages are available which permit automation of portions of the software planning process. The elements which typically make up Change Planning include Creation of change requests, Request logging and categorization, Impact Analysis and criticality, Approval and prioritization, Change scheduling and request milestones, and Release planning.

Change Communication 512 is the process of keeping all involved parties informed as to where changes are at any given time in the change life cycle. Change control software can also aid in the automation of the communication process. Typical elements include Change communications management, Change schedule confirmation, Change schedule update, Change schedule reporting, and Change schedule dissemination.

Migration Control 513 focuses on management of the release of changes once they are ready for distribution to affected parties. Again, several of these elements may be automated if warranted. Elements of migration control include Release package assembly, Release package integrity, Version control implementation, Successful release package confirmation, Release package migration notification, Migration library maintenance, Change back-out and contingency planning, and Change reporting. Task 2113: Analyze Operating Constraints

Task 2113 identifies the operating constraints and limitations, and assesses their potential impact on the operations environment. Preferably, the task includes assessing the organization's culture, pre-selected packaged software, funding, external issues, and other issues, and their potential impact on the project. Change control also assesses and classifies constraints according to organization, technology, process, equipment, and facilities issues. The task may include assessing the organization's ability to adapt to change as part of the constraints analysis. The change control elements and change request categories noted can be used to develop a structured outline or interview format to collect data for analyzing constraints, assessing current capabilities, and defining requirements.

Task 2115: Analyze Current Change 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 estimator may also assess strengths and weaknesses of any existing Change Control capability in order to better plan and design for the future. Important considerations include understanding the Change Control processes before looking into how they are currently measured.

Particular tasks or functions in this step may include documenting the present change control workflows, focusing on what is wrong with current workflows, procedures, and the like. Then the function or group may include documenting performance levels to establish a baseline, and reviewing any SLAs for change request response timeframes. An 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 and management commitment required to move to a new Change Control capability.

Task 2117: Identify Change Control Best Practices The next task may be to identify the best operating practices 2117 for the operation, and to identify the Change Control areas that could benefit from application of best practices. In one embodiment, the user 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 Change Control Requirements The next task in the planning 102 may be to refine business capability requirements 2118. Capability requirements define what the Change Control infrastructure will do; capability performance requirements define how well it will operate. One task is to integrate the operating constraints, current capabilities, and best practices information to develop the capability requirements. Performance requirements for change control should also be defined, as should the interfaces for change control with other OM components and other enterprise units. Requirements should indicate how operating constraints will be overcome and how current capabilities will be utilized.

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 provider will align the metrics and target change levels with performance provisions for batch Change Control and processing as outlined in service level agreements. Considerations may include a business performance model to define the overall design requirements for the Change Control capability. It is advantageous to keep the metrics as simple and straightforward as possible and to consider the Change Control infrastructure's suppliers and customers in defining the metrics. After refining the business performance model and completing the planning step 102 by delivering the plan 110 to the client, the step of designing 104 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 provider designs the new change control processes, and develops the framework and formats for change 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 change control activities. Other tasks include defining the physical environment interactions 2412, identifying skills requirements for performing change control tasks 2413, defining application interactions, that is, the human-computer interactions necessary to fulfill key change 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 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 Change 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 considerations will typically fall into several categories:

The new processes and workflows should reflect any packaged software that is currently being used or has been purchased.

Design of the workflows should allow for the possibility of emergency changes.

How long it takes to process and implement a change will be key to the success of the new Change Control system. System ease of use from both the customer and the change control teams point of view.

Are different processes needed for hardware, systems software, prepackaged software, and custom applications? Reporting requirements should be analyzed and documented in as much detail as possible.

Options for request initiation should be assessed, and selected methods approved and documented.

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 Change 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 Change Control, identifying distributed Change Control physical requirements, if any, as well as central needs. Change control processes and tools should be designed to interface with other processes, such as asset management, service control, etc.

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 Change Control tasks. The deliverables from this task may include both a role interaction model and skills definition. A planner 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 for change control tasks.

Considerations include the makeup and responsibilities of any Change Control Board or Advisory Board needed. Any changes to the Change Control process may impact the role and skill requirements for other processes that interface with Change Control. Considerations may include centralization or decentralization of the change 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 Change Control. Any information technology standards regarding hardware and software will constrain the specific skills needs.

The next task is to define application interactions 2415, or to identify the human-computer interactions necessary to fulfill key Change Control activities. This will most often involve identifying required Change Control features not supported by the Change 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 will only be needed for change control activities where customization or custom software is being used.

Task 2416: Identify Performance Support Requirements Identifying performance support requirements 2416 is the next task block for the planner. The planner will want to analyze the Change Control processes and determine how to support human performance within these processes. The task is to analyze the critical performance factors for each Change Control task and to select a mixture of training and support aids to maximize workforce performance in completing each task. These can include Change Control policies and detailed procedures, on-line help screens of various kinds, checklists, etc.

If the 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. Considerations may include roles that deal directly with change control software, roles directly involved with the processes and activities, and roles which only indirectly use the processes by submitting and tracking change requests.

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. Considerations include who is responsible for fulfilling the activities involved and how the roles will be supported to maintain the Change 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 Change 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 Change Control domain and outside experts as well as the design teams to do the validation.

Step 2710 - Design Organization Infrastructure:

For step 2710, the method of the present invention includes defining the structures for managing human performance, and defining what is expected of people who participate in the change 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 Change 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 change control needs.

Task 2711 : Design Roles, Jobs and Teams

The task will include the design for the roles, jobs and teams. The Change Control organization structure should be designed around 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. Particular tasks include confirming the Change Control competency requirements, and confirming the roles involved with any new Change Control system. Roles, jobs and teams should be designed, and their reporting relationships determined. Their performance measurement factors should also be identified, and any SLA requirements should be included.

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 Change 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 Change Control personnel nearly as much as technical training and expertise.

Task 2715: Design Performance Management Infrastructure These tasks include defining the people and teams that will perform in change control. The next task may also include designing 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 determine 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 Change 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 may be necessary primarily if change 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 may want to consider at some point how to mobilize the resources required to staff the new Change 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. Change 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 Change Control organization meets the needs of the Change 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 Change Control capability requirements.

Step 2750 - Design Performance Enhancement Infrastructure: In this step, a performance enhancement infrastructure is designed. The designer determines the training needed for change control functions, and determines 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. Tasks 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.

This task is to refine the information about the current change control staffs competency, proficiency, and performance levels in specific areas, and assess the gaps in competencies and performance levels that drive the design of the performance enhancement infrastructure. Preferably the task includes assessing the competency of the current change control staff based on the competency model previously developed.

Task 2753: Determine Performance Enhancement Needs

This task is to assess the performance support and training requirements necessary to close the competency and performance gaps in the workforce. Preferably, the task includes using the employee assessment to determine the type of performance enhancement required to close the gaps and reach the desired competency levels. Considerations may include the organizational approach to staffing, that is, whether the change control personnel are permanent, an additional duty, or staffed on a rotating basis.

Task 2755: Design Performance Enhancement Products This task includes defining the number and structure of performance support and learning products. Preferably, the designer determines the delivery approaches for training and performance support, designs the learning and performance support products, and defines the support systems for delivering training and performance support. Due to part-time change 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 Change 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 Change

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 Change 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

This task includes developing a comprehensive approach for testing the learning products with respect to achieving each product's learning objectives. Preferably, the task includes identifying which learning objectives 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 Change 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 task includes verifying the performance enhancement infrastructure and the learning test deliverables to determine how well they fit together to support the new change control capability. Preferably the method simulates the processes and activities performed by the members of the change control team in order to identify performance enhancement weaknesses. The method identifies the problems and repeats 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 goal of this step 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 Change Control infrastructure. In this task, the project manager or planner seeks to identify key performance parameters for Change 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).

Task 3513: Analyze Technology Infrastructure Component Requirements

The next task 3513 is to analyze technology infrastructure component requirements for change control. This portion of the project delves into the hardware and software required, as the project manager analyzes and documents requirements for Change 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, hardware and software used, reporting requirements, storage requirements, and interfaces to other systems. 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 change 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 Change Control technology environment. It is important to identify the areas where gaps exist between the current infrastructure and the new requirements.

Important for both system and cost considerations are any potential areas of reuse of current components. Other considerations include the configurations of each site where a change control function is desired: different configurations may be required at different sites. Note should also be taken of any enterprise or organizational standards or policies regarding change control technology.

Task 3517: Plan Technology Infrastructure Product Test Once the components and system are planned, the next step 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. Any new or changed change control processes should be tested prior to release.

Step 3550 - Select and Design Operations Architecture:

After the infrastructure requirements have been analyzed, it is time for the step of selecting and designing an operations architecture 3550, Figure 8.

In this step, the manager will select and design the components 3551 required to support a high-level Change 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 the manager designs change 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 change 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 Change Control environment, select components that will support the Change 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.

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 Change 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 reuse 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. Considerations may include, but are not limited to, the number of custom reports, the number of interfaces between support organizations, and the degree of automation provided by the application and the amount desired by the client or enterprise served.

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 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 change 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 change 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 are defined the approach and test conditions for the Change Control Architecture Assembly, Component, and Component Acceptance Test Approaches and Plans. 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. In this task, a component test approach and plan are generated, as is an assembly test approach and plan, and a component acceptance test approach and plan. The plan should include the objectives, scope, metrics, regression test approach and risks associated with each test. The tests should cover component testing for custom and customized (reused or packaged) components, and should cover new packaged components. Assembly testing for all components, and especially all interfaces, should be defined as well.

Step 3590 - Validate Technology Infrastructure:

The next block in a technology portion of the method or cost planner is a step wherein the manager validates the chosen technology infrastructure 3590, as shown in Figure 9. An analysis is undertaken of the change 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

Change 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 task may be to review and refine the technology infrastructure design 3591. This task is undertaken to ensure that the Change Control infrastructure design is compatible with other elements of the technology infrastructure. The manager may want to ensure that the change 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 Change 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 valuable in the validation task to include designers or architects of enterprise operations components which will interface with Change 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 Change 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.

The technology infrastructure design should be completed in this phase. The goals in this task should include a technology infrastructure deployment plan, a deployment test approach, and a deployment test plan. Since the point of the information technology group is to service an enterprise, Change Control itself may only be part of the validation scope.

After designing 104 the change control function and obtaining authorization for build and test 112, the project may proceed along three timelines 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 step in build and test 106. 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 for change control 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. Attention should be paid to considerations of integrating the selected components with other operations and tools within information technology and the enterprise served by IT.

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 step, steps are taken to ensure that the Change 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 Change Control components are installed.

Step 5550 - Build and Test Operations Architecture:

Having acquired the technology, the project now proceeds to a build and test stage 5550, depicted in Figure 11. In this stage, personnel design and program the Change 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. Custom components typically include interfaces to other OM components and consider any special reporting requirements for change control operations. 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 monitoring 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 change 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. This task includes building all custom change 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. Training and training time may be required if any software packages have unique or proprietary languages, in order to customize or configure the change control function.

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 Change 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 Change 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. Several test cycles may be needed to test all reporting periods and any long-term trend reporting requirements.

This task ensures that the Technology Infrastructure Design has been properly implemented, and that the infrastructure can support the development, execution, and operations architectures. The new technology infrastructure and its integration with the current infrastructure are tested. Tested and delivered are the change control infrastructure, and a product test model and a deployment model. 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 Change Control policies, procedures, and reference materials. It is also desirable to conduct a usability test and review to verify ease of use with both change control personnel and personnel from the supported enterprise. Upon successful completion of this task, the operating personnel will have Change 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 Change 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. Each category of change request may require a separate set of procedures, including different approaches for review and approval. The process must support any SLAs and not be too cumbersome to deliver decisions on changes in a timely manner. Since change policies are subject to change themselves, they should be reviewed and updated periodically.

Task 6225: Develop User Procedures

In this task, a detailed set of change control user procedures are delivered. User procedures provide the details necessary to enable smooth execution of new tasks within a given business procedure. Preferably, the provider collects and reviews content information, drafts the procedures, verifies consistency with business policies and procedures, and plans for the production of the materials. It is presumed that enterprise users or "customers" will not interact with change control processes on a regular basis. Change requests are preferably submitted in a written manner, such as e-mail or other written medium. 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 change control personnel 6227. In this task, the provider drafts any reference materials and job aids that make a task easier or more efficient. 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 Change 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 Change Control personnel can have ready access to information at their desktops for responding to users. Tasks within this function include collecting and reviewing content information, and drafting performance support products. The materials written are then verified for consistency with organizational policies and procedures. While "production" is possible for these materials, outside user support products should preferably be available on-line.

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 confirm that the products meet the requirements of the Change 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. Any open issues should be resolved as quickly as possible.

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, a desirable step may include development of learning products 6260, as shown in Figure

13. A first task may include defining the needs for learning products and the environment in which they are to be used 6261. Technical training in Change 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 tasks 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

In this task, the environment for developing the change control learning products is created. Preferably, the provider selects authoring and development tools, defines standards, and designs templates and procedures for product development. Technical training in change control software components may come from the package vendor or a third party training organization. Procedural training may be custom designed.

Task 6263: Perform Learning Program Detailed Design In this task, the provider specifies 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 change 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 change 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

In this task, prototypes are completed and ease-of-use sessions on classroom-based learning components are conducted (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

In this task, the learning materials proposed and prototyped during the design activities are developed. Preferably, the provider develops activities, content, and evaluation and support materials required, develops maintenance plan, trains instructors/facilitators, and arranges for production if necessary. Online aids are preferred.

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 change control. Preferably, the task includes confirming the Test Plan, executing 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 change 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 Change 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 is to create the change control infrastructure test model. Preferably, the provider creates the test data and expected results, creates the testing scripts for production, deployment, and configuration tests. The provider also conducts the change control training not yet completed, and reviews and approves the test model. If a complete business capability is being deployed, this is a comprehensive test with change 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. If change control is being implemented independently, than all or a portion of the production environment can be used as the "test" application.

Task 5593: Execute Technology Infrastructure Product Test This task is to verify that the technology infrastructure successfully supports the requirements outlined in the business capability design stage. Preferably, the provider executes the test scripts, verifies the results, and makes changes as required. Preferably, the test simulates actual change control working conditions, including related manuals and procedures.

Task 5595: Execute Technology Infrastructure Deployment Test

In this task, the provider ensures that the new change control infrastructure is correctly deployed within the organization. Preferably, the provider executes the test scripts, verifies the results, and makes changes as required. Task 5597: Execute Technology Infrastructure Configuration Test This task is to ensure that the performance of the technology infrastructure, including change control, is consistent with the technology infrastructure performance model after the infrastructure has been deployed. Preferably, the provider executes the test scripts, verifies the results and makes changes as required, and updates the risk assessment.

After completing the build and test phase 106, a milestone 114 is reached, as to whether or not to deploy the change 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 change control infrastructure may be deployed online 7170, Figure 15. At this point, the tasks remaining include configuring the technology infrastructure 7171 to prepare for any new business capability components. In this task, the deployment unit is brought up to the technology infrastructure baseline required, including change control.

This step will generally be required if the change 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 Change 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 change 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 Change Control is being installed independently.

Task 7171 : Configure Technology Infrastructure In this task, the deployment unit's technology infrastructure is customized 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

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

Task 7179: Verify Technology Infrastructure

In this task, the new technology infrastructure environment verified and the issues raised as a result of the testing are addressed. 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 change control function, as described above, the present invention also includes a method and apparatus for providing an estimate for building a change 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 change control in an information technology system. In Fig. 16, a provider of a change 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 for a given operations management OM function. Table 1 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 activities ("SLA") 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.

Table 1

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 and 17b. 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 change 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 and 17b. 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 and 17b, 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 and 17b, 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 920, organizing project resources 940, controlling project work 960, and completing project 960, as shown in FIG 17a.

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 use a change control system within an information technology organization. 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 change control function in an IT organization, comprising:

(a) planning for said change control function; (b) designing said change control function;

(c) building said change control function;

(d) testing said change control function; and

(e) deploying said change control function.

2. The method of claim 1 wherein said planning act includes: (f) developing a business performance model for said change 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 change control capability;

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

(k) defining a plurality of requirements for said change control function; 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 change control function.

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

(h) identifying physical environment interactions;

(i) identifying skill requirements for performing said change control function; (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 change control function.

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;

(i) designing a performance management infrastructure;

(j) 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 change control function.

9. The method of claim 8 wherein said step (f) includes: (g) assessing employee competency and performance for a change 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 change control function.

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 change control function.

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 change control function.

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 change control function.

17. The method of claim 16 wherein said acquiring act includes: (0 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 change control function.

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 change control function.

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 change control function.

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 change control function.

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 change 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 change control function based on said estimating factor and said difficulty rating; and

(d) generating a cost for building said change control function 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 activities, components, interfacing entities, locations, personnel, total roles, workflows, 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 change control system 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 change control where said stages are plan and manage, capability analysis and design release, 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 change 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 change control function;

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