Anticlue

SIPOC Diagrams

We have a habit sometimes of only looking at a portion of the puzzle. Sometimes it is just necessary for being able to focus and manage your time appropriately, other times there is a need to collectively see the same picture. A situation where it is useful to see the entire process collectively is when you are trying to find a problem within a business process. The Six Sigma tool to help teams see the global big picture view of the process is the SIPOC diagram.

A SIPOC diagram is a high-level map of the process with the suspected problem. The diagram portrays a clear concise illustration of the entire process to allow the team to see the picture from the same perspective.

The SIPOC diagram consists of five elements:

1. Supplier – The suppliers are the individuals, departments, or organizations that provide the materials, information, or resources that are worked on in the process being analyzed.
2. Inputs – The inputs are the information or materials provided by the suppliers. Inputs are transformed, consumed, or otherwise used by the process.
3. Process – The process is the steps or tasks that transform the inputs into outputs: the final products or services.
4. Outputs – The outputs are the products or services that result from the process.
5. Customers – The customers are the individuals, departments, or organizations that receive the outputs, the products or services, generated by the process.

The SIPOC diagram purpose is to provide a clear, simplistic illustration of the process under inspection. It is the airplane view of the cat herding farm.

Creating a SIPOC diagram involves five steps:

1. Name the process - Naming the process involves identifying the process the sigma team is examining. This gives the team a reference point and enhances the team's focus. Make sure to name the process after the key functions the process performs; this will enhance the sigma team's focus on the entire process in question, rather than on one aspect of that process.
2. Establish the process boundaries - Establishing the process boundaries involves defining where the process begins and ends. This helps prevent the team from straying into unrelated processes.
3. Identify key outputs and customers - Identifying key outputs involves listing the products or services that result from the process. Identifying key customers involves listing the recipients of these outputs.
4. Identify suppliers and key inputs - Identifying suppliers involves listing the people or sources who provide the materials or information for the process. Identifying the inputs involves listing the materials or information provided.
5. Identify and order the key process steps - Identifying and ordering the steps entails listing up to seven tasks or activities that are involved in transforming the inputs into outputs. You can also refer to these steps as the core process of the larger process. On the SIPOC diagram, the core process transforms the inputs into outputs. This process is displayed in the middle box on the chart.

The ultimate goal to creating a SIPOC diagram is to develop a new set of key process steps that present the solution to the identified problem.

The SIPOC diagram is yields a broad perspective of the process it's investigating. The diagram illustrates complex processes in a simple flowchart, helps teams stay on course, and ensures that all team members are viewing the process in the same way.

Common Risks associated with Service Level Management

As with everything there are some common issues encountered in implementing a Service level management program. Recognizing the risks ahead of time can help mitigate, avoid, or lessen the impact of them.

The first risks are associated with the culture change that arises within the IT department. The old ways of doing things may become not acceptable processes and the conversion to the new practice should be strategically planned.

SLM costs include the expenses related to the implementation and operating cost. These costs are typicalling categorized by the personnel, training, and documentation costs.

Controlling and Monitoring the Service Level Management Process

Like everything else in life, if you want to assure service level management is going to succeed you need to have the right person accountable or the right level of leadership. This designee is normally the service level manager. The service level manager should be empowered and accountable for the following:

• Creating and updating the service catalog
• Defining and maintaining an effective SLM process, specifically in regard to the service level agreements (SLAs), operational level agreements (OLAs), and underpinning contracts (UCs)
• Updating the existing service improvement program (SIP) by reviewing the performance of the IT organization and improving performance where necessary.

Obviously all of the above are impossible to execute without the right tools, management repots are used to identify improvements and control the internal process. Some key reports that are commonly used in the service level management process are:

• the number of times an SLA was not fulfilled
• the cost of measuring and monitoring the SLA
• the progress of improvement actions
• customer satisfaction, based on survey complaints
• statistics about incidents, problems, and changes

At this point it is becoming clear that the ITIL Management Processes do not operate in a silo. This is also true with the Service Level Management process. The following is a list of the interdependencies between SLM and the other IT Service Management processes:

• Service desk - The service desk can provide feedback regarding user satisfaction of SLM. This feedback can be an indicator of customer satisfaction and ultimately loyalty. The service desk is also a good place to find the response and solution times that are needed when an event occurs with the provided service.
• Availability management – Service Level Management provides availability management with input about the required availability of the IT services. Availability management returns the favor by giving SLM information about the actual availability.
• Capacity management - Capacity management inputs information about the impact of a new service or the extension of an existing service has on capacity. Capacity management also reports if the use of a service is within the agreed thresholds. Service Level Management informs Capacity Management about the current and future usage of a service.
• Incident management and problem management - The time to respond and solve for both incident and problem management are defined by the service level agreement. This information creates an efficient measure of service. SLM uses this information to identify patterns and trend of incidents and problem to help clarify service level targets.
• Change management – The change management process will let the service level management process know if there was a change that affected service level agreement standards.
• Financial management – Financial management provides Service Level Management with the costs associated with providing the service, the charging methodology and the rate to be charged. This information is included in the development and final Service Level agreement.
• IT service continuity management - During the SLM process, agreements are made regarding continuity management measures and procedures. The measures and costs are then included in the SLA. Changes to the service and the SLA may require modification of the continuity measures and procedures.
• Security management - The security requirement agreements are defined in the SLA. Security management assures that the agreed security measures are implemented, monitored, and reported to the Service Level Management process.
• Configuration management - The creation or modification of a service or SLA will affect the configuration management database (CMDB). The CMDB is also used to report about the quality of the configuration items; this allows SLM to report about the quality of the service provided.

Service Level Management Processes

Service Level Agreements are the foundation of the Service Level Management Process. When deciding to implement an SLA, one has to consider the different structures to determine what will work with your organization.
There are different structures for Service Level Agreements.

1. Multilevel – A multilevel structure assists in reducing the overall volume of specific agreements needed to outline all available services. This structure is normally applied to cover the following levels:
   • Corporate level - The corporate level covers all of the generic service level management issues appropriate to every customer in the organization. For example the network services agreement level or desktop support would be applicable at this level.
   • Customer Level – The customer level covers all service level management issues to a specific customer group, such as the patient billing group or the radiology department.
   • Service Level – The service level covers the service level management issues to a specific service used by a customer group. For example, the PACS and Radiology Information System (RIS).
2. Service or customer based structure – A service or customer based structure is really suitable in smaller business environments. A service-based service level agreement structure encompasses one service for all customers. A customer-based service level agreement structure covers all the services used by one specific customer group.

Different structures work for different organizations. Doing some research on this topic is time well spent.
After the determination of which structure will be utilized it is time to move to the first part of the process, scoping and creating the service level agreement. Scoping and creating the SLA is a part of the negotiation and finalizing stages. During negotiations, the customer’s needs are defined in service level requirements (SLRs) and the service catalog. Quite often there are two different viewpoints here between the service level requirements and the IT service provider. The IT service provider should also look to any vendor agreements or third-party providers to assure the same standard is applied.

Once the Service Level Requirements are vetted, accepted, and validated. Service targets are derived and defined within an Operational Level Agreement (OLA) and an underpinning contract (UC). The Operational Level Agreement and Underpinning Contract are supporting documents to the SLA.

The outputs of the negotiating stage of the SLM process are:

• Service catalog – The Service catalog portrays IT as a service instead of as an implementing or maintaining organization. The service catalog details the IT services that are offered as well as the features and functions of that service.
• Service level requirements – Service level requirements are documents which define the customers need. These are used to obtain the scope of the customer’s need. Once derived, SLRs provide a mechanism to develop, modify, and initiate service.
• Operational level agreement – The operational level agreement covers the delivery of services that support the IT organization in its delivery of services. This document provides an internal quality check for the service agreement. For example, if vendor support is only 8 am – 8 pm Mountain time weekdays, it is impossible to offer a service agreement which only provides upgrades and system outage at 9:00 PM EST on Saturday.
• Underpinning contract - The underpinning contract is a contract with an external vendor or supplier. The underpinning contract covers the delivery of services that support the IT organization in its own delivery of services. The underpinning contract can be a master service agreement, with a support addendum or schedule of services agreement.

The second stage of the service level management process is the finalizing stage. The primary activities that occur during finalizing are drafting, reviewing, agreeing upon, completing, and validating, and completing the SLA and supporting agreements.

The next stage is the monitoring stage. Within this stage both technical and procedural actions are monitored. Monitoring coincides with the next stage, reporting. Reports are created to measure the service level compared with the agreed standard.

The final stage is the review stage. When reviewing Service Level Agreement, it is important to keep in mind the changing business environment. There maybe symptomatic problem and trends that highlight the need to change procedures and possibly the need for additional resources. A common technique is to use a Service Improvement Process (SIP) to allocate additional personnel and resources, to modify procedures, and to recommend changes to the level in the SLA.

Introduction to ITIL's Service Level Management Process

There is a simple process that needs to be followed in providing great customer service. First, you have to understand what the customer needs, desires, and dreams. Second, you have to clearly define if you what you can meet. For example, don’t go to starbucks for a great burger. Finally you have go above and beyond in assuring you can deliver what you plan to meet.

So in the field of information technology what has best practices shown us? First you can really deliver anything that one cannot measure. Once you have a measurable level of service, a Service Level Agreement can be drafted. A Service Level Agreement (SLA) is a document stipulating the measurable levels of service and assuring the services are provided. It provides the customer and IT with a defined product. Once an SLA is drafted and agreed with by the customer it becomes a guideline for managing the relationship between the customer and IT. Service Level Management (SLM) is the process of planning, coordinating, drafting, agreeing on, monitoring, and reporting on the service level agreements (SLAs). SLM also engages in assuring that the service quality strives for continuous improvement.

Service Level Agreements are the tools which assure the customer receives the level of service they expect, and they also help with setting those expectations. Within a service level agreement one can expect to see the following ten points:

1. Service description – The service description details the key business functions and deliverables, and information to describe the service and its scale, impact, and priority for the business. It also includes signatory details.
2. Service hours – Service hours list the hours that customers can expect the service to be available.
3. Service availability – Service availability is all about the targeted levels the IT organization will deliver within the agreed-upon service hours.
4. Support levels – Support levels explain how to reach out to the service desk, the hours the service desk is open, and what the process is to receive help after hours.
5. Performance – The performance point provides the expected responsive of the IT service, such as workstation response times, details of expected service, and the threshold of unacceptable service.
6. Functionality – The functionality section specifically details how many errors of a specific category can be tolerated before calling a breach of service.
7. Charges – The charges component clearly revels any charging formulas or costs for the service.
8. Continuity – Continuity refers to continuity of operations planning with references to the disaster recovery plan, specifying how the service will be provided and estimated recovery time.
9. Security – Security lists the procedures and protocols surrounding security of IT services as well as the measures needed to assure that security.
10. Changes – The changes section list the organizational change management policies and procedures and how to properly follow these procedures.

Once the Service level agreement is drafted, one can use the service level management process to execute the agreement. The Service Level Management process involves the following five stages:

• Negotiation – The negotiating phase is where the IT service provide and customer collaborate to ascertain SMART service levels. SMART refers to Specific, Measurable, Agreed to, Realistic, and within a Time Frame. This collaboration is cyclical as both parties work to refine according to the customer’s needs.
• Finalizing – In the Finalizing Phase, the Service Level Agreement is completed along with any other sustaining and supporting agreements.
• Monitoring – In the monitoring phase, service quality is measured by the SLA’s defined service targets. Service targets refer to the agreed-upon levels of service. Any variances need to have an action plan of how to correct and resolve them before the business is adversely affected.
• Reporting – In the reporting phase, Reports are generated that compare the agreed-upon service levels with baseline service levels. These reports are the basis for continual service improvement.
• Reviewing – In the review phase, a comprehensive enterprise wide review of service quality is provided. Problems are brought into the light of the examinations and lessons from the problems and issues are shared and hopefully learned.

Each stage in the service level management process fuels the next stage. So taking the time to plan, vet, and negotiate the SLA is well spent and helps to assure the success of implementing a SLM process.

Creating Work Breakdown Structures

The creation of a work breakdown structure (WBS) is the process of subdividing the major project deliverables and project work into smaller, more manageable components at least according to the PMBOK. There are two formats of presenting a WBS, the outline (MS project view) and Graphical, network diagram view. The WBS ultimately enlightens the team and stakeholders by providing a clear picture of what is needed to complete the project.

The inputs to creating a WBS are:

1. The Project Scope Statement - The Project Scope Statement is a description of the project scope (including major deliverables, project objectives, project assumptions, project constraints, and a statement of work) that provides a guidelines for making future project decisions and for creating a common understanding of the project scope among the stakeholders.
2. The Project Scope Management Plan - The Project Scope Management Plan details the actions necessary in preparing the Work Breakdown Structure. This plan also describes how the project scope should be defined, verified, and controlled. This includes a description of the process that should be used to create the WBS from the Project Scope Statement. When reviewing the Project Scope Statement, the project manager should extract the following components to help create the WBS.
   • Objectives – Objectives are what the goal of the project is.
   • Boundaries – Boundaries help determine what is to be included and what is not to be included.
   • Description – The product scope descriptions definitely offers insights to the details involved in decomposing tasks.
   • Deliverables – All deliverables should be contained within the work breakdown structure.
   
   After reviewing the Project Scope Statement, the project manager should review the Project Scope Management Plan to utilize the following information in creating the work breakdown structure.
   • Decomposition - Decomposition involves breaking a large item down into smaller components.
   • Template – Honestly having standard templates for developing all WBS should be a cornerstone of your organizations project management methodology. The standard template specified in the Project Scope Management Plan should be utilized.
3. Organizational process assets – Organizational process assets give the project manager a wealth of information regarding standards, procedures, guidelines, and lessons learned from previous projects.
4. Approved change requests – Approved change requests are authorized changes to the project scope.

Once you have gathered all these inputs together it is time to use some tools and techniques to create the work breakdown structure. The goal of creating the work breakdown structure is only attack a part of the elephant at a time. The tools and techniques used to create a WBS are:

• Work breakdown structure templates – Work breakdown structure templates from previous project work can be useful. Its easier not re-inventing the wheel every time.
• Decomposition – Decomposition is used to break a project down into smaller, more manageable components. There are three steps involved in performing decomposition:
  1. Identify the project deliverables – This step involves reviewing the inputs detailed above.
  2. Break the project down into components – This step involves producing a hierarchical descriptions of the project’s project. It can be in a graphical or outlined display.
  3. Verify the WBS – In other words check your steps and work. Common quality assurance questions are:
     • Did I include all relevant deliverables?
     • Did I accidentally include any deliverables that are outside the scope of the project?
     • Did I break the project down into the correct components--such as subprojects, sub-subprojects, activities, and deliverables?
     • Did I state all known tasks associated with the creation of each deliverable?
     • Has the WBS been verified by the person or persons indicated in the project documents?

Now that you have done the heavy lifting, it is easy to grasp how important and key the WBS to overall project delivery. Creating the Work Breakdown Structures has six main outputs.

1. The WBS itself - A WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages.
2. WBS dictionary - The WBS dictionary is a document that describes each component in the Work Breakdown Structure (WBS). For each WBS component, the WBS dictionary includes a statement of work, defined deliverables, a list of associated activities, and a list of milestones. Other information may include the responsible organization, start and end dates, the resources required, an estimate of cost, the charge number, contract information, quality requirements, and technical references that facilitate performance of the work.
3. Project Scope Management Plan updates - The Project Scope Management Plan specifies how the scope will be defined and controlled, and how the WBS will be created and defined.
4. Scope baseline - The scope baseline is a collection of approved documents. These documents consist of the detailed Project Scope Statement, the WBS, and the WBS dictionary.
5. Project Scope Statement - The Project Scope Statement provides descriptions of the required deliverables and associated work. As the WBS is created, certain changes may need to be made to the described deliverables and work. The Project Scope Statement must be updated to reflect these changes.
6. Requested changes - When project managers are creating the WBS, they will often find that certain changes affecting the scope need to be made. These changes should be thoroughly reviewed and then approved according to the project's Integrated Change Control process.

The WBS is the foundation. Without the foundation really don’t have anything to build upon for your project. Obviously it is needed.

Defining Project Scope

Let’s face it, defining what project scope means is critical. We have all been in the meetings where two or three people leave with different impressions of the discussion. Creating a project scope statement is a key way to ensure everyone is on the same page. The Project Scope Statement defines the project scope and what needs to be accomplished to meet the project’s objectives.
The five inputs to defining project scope are:

1. Organizational process assets – Organizational process assets provide information about standards that the company has already set in place—standards that are likely to be applied to every project. This information is re-used when creating the Project Scope Statement.
2. Project Charter – The project charter authorizes the existence of the project. It outlines the project objectives, which project managers need to detail further in the Project Scope Statement.
3. Preliminary Project Scope Statement – The Preliminary Project Scope Statement provides a description of the major project deliverables, project objectives, project assumptions, project constraints, and a statement of work.
4. Project Scope Management Plan – The Project Scope Management Plan provides a description of how the stated project objectives will be developed within the detailed Project Scope Statement.
5. Approved change requests – Change request which are agreed-upon and documented amendments to project scope. Approved change requests will ultimately be added to the Project Scope Statement.

There are several tools and techniques used to developing a detailed Project Scope Statement.

• Product analysis - Project managers use product analysis to improve their understanding of the project's product. Product analysis is important to scope planning because it helps project managers determine how the product is made.
• Alternatives identification - When creating a Project Scope Statement, project managers use alternatives identification to produce different ways of approaching project tasks. Lateral thinking and brainstorming are two examples of alternatives identification.
• Expert judgment - To make informed decisions, project managers use their own expert judgment and the expert judgment of others who have advanced skills or previous experience. These experts help project managers make decisions when developing the Project Scope Statement.
• Stakeholder analysis - Project managers use stakeholder analysis to identify the potential people, groups, and institutions that may affect or be affected by the project. After identifying the stakeholders, the importance of key people that may significantly influence the project's success is assessed.

After putting the effort in one earns to view the outputs, the outputs of the Scope Definition process are as follows:

• Detailed Project Scope Statement – The detailed project scope statement is the description of the project scope, major deliverables, project objectives, project assumptions, project constraints, and a statement of work. It provides a documented basis for making future project decisions.
• Requested changes - A requested change is a formally documented change request that is submitted for approval to the Integrated Change Control process.
• Project Scope Management Plan updates – Project scope management plan updates are contained within or is a part of the subsidiary plan of the Project Management Plan. It describes how the project scope will be defined, verified, and controlled, and how the Work Breakdown Structure (WBS) will be created and defined.

The detailed Project Scope Statement and the updated Project Scope Management Plan, as well as approved change requests, will be used as inputs for one of the most important items produced as part of the Planning Process Group—the Work Breakdown Structure.

Six Sigma Creating SMART Project Goals

"We want to become the most powerful, influential, and respected Healthcare information technology department in the world."

Take a moment and consider the above goal? Is it obtainable? How do you measure the success of obtaining such a goal? While this is a goal, from a Six Sigma perspective it needs to be transformed into something achievable, clear, concise, and measurable.

A better example of a project goal is, "We agree we reduce break fix issues in our production environment by 50 percent within three months." This goal is clearly defined because it's SMART: Specific, Measurable, Agreed upon, Realistic, and within a clear Time frame for reaching the goal.

Six Sigma's SMART methodology helps keep a project team focused and dedicated to a common goal. While improvement projects are typically complex, lengthy, and involve a cross functional team of people from different work areas, a project goal helps ensure that the sigma team stays focused and on-track.

There are five guidelines for making a project goal SMART:

• Make the goal Specific - The goal should be exact regarding what the team hopes to accomplish.
• Make the goal Measurable - When a project goal is measurable, the team knows exactly when the goal has been achieved and what has been achieved.
• Make sure the goal is Agreed upon - Everyone involved in the process in question, especially all Six Sigma team members, must agree to the goal and agree that its successful completion is important. At some point, all team members and project stakeholders will be asked to contribute their time and resources to the project. Agreement commits everyone to achieving the same goal.
• Make sure the goal is Realistic - Whether a goal is realistic depends on the resources and needs of the organization. Make sure the goal is neither too ambitious nor too trivial. Make it just right.
• Make sure the goal has a Time frame - Like all the elements of the project goal, the time frame should be realistic. The time frame should be achievable yet limited enough to make the goal valuable to the company.

Creating the goal for a Six Sigma improvement project requires that the team follow five guidelines for making the goal SMART.

Scope Planning

Scope Planning is an important component of the project management. The Project Scope Management Plan is the document that details how the project scope will be defined, developed, and verified while provisioning how scope will be managed and controlled by the project management team. The Project Scope Management Plan also defines how the WBS will be created and detailed.

The following items are the five inputs used to create a Project Scope Management Plan:

• Enterprise environmental factors – Enterprise environmental factors can influence how the project scope is defined, controlled, verified, and managed.
Organizational process assets – Organizational process assets provide information about existing policies, procedures as well as historical records and lessons learned from previous projects. They provide information that is used to help the project manager take measures to control scope in the Project Scope Management Plan.
• Project Charter – The project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. This objective forms the basis of scope planning.
• Preliminary Project Scope Statement – The Preliminary Scope Statement begins to define the project and what needs to be accomplished. It includes the product requirements, project boundaries and methods of acceptance. The deliverables are used in scope planning as the basis for the WBS.
• Project Management Plan – The Project Management Plan is a formal, approved document that provides the structure and outline for the Project Scope Management Plan. It describes which project scope management processes will be performed and at what level they'll be implemented.

In order create the Project Scope Management Plan, project manager often rely on the following tools and techniques.

1. Expert judgment - Expert judgment is based on expertise in a particular discipline, industry, application area, or knowledge area. Such expertise may be provided by a individual or a group with specialized education, skills, or training, and it is available from such sources as consultants or stakeholders.
2. Templates, forms, and standards - Templates, forms, and standards are commonly used tools for creating the Project Scope Management Plan. Examples include Project Scope Management Plan templates and project scope change control forms.

An output of Scope Planning is the Project Scope Management plan. This plan is defined as the document that describes how the project scope will be defined, developed, and verified and how the Work Breakdown Structure (WBS) will be created and defined.

The necessary components of the Project Scope Management Plan are:

• Scope Planning, including information about scope stability – Scope planning contains a description of the preparation of a detailed Project Scope Statement.
• Scope Definition – Scope Definition contains a description of the preparation of a detailed Project Scope Statement.
• Work Breakdown Structure – The Work Breakdown Structure contains a description of the creation of the WBS from the detailed Project Scope Statement.
• Scope Control – Scope Control contains a description of the process for handling changes to the detailed Project Scope Statement.
• Scope Verification – Scope Verification contains a description of the process for verification or acceptance of the completed project deliverables and the WBS.

To ensure that project tasks are manageable, project managers establish a Project Scope Management Plan.

Measuring Process Problems

A process problem is a problem that weakens the quality of the process. The need is what the customer is looking to obtain from that process. If customer consistently do not get what they want or need, then the process has a problem. The success of a process is measured by the customer satisfaction. As you engage in resolving process problems, remember to measure the problem in a way that addresses the needs of those affected by the process.

The first step in determining how to resolve a problem is to obtain an effective measure of the problem. An accurate measurement is one that the customers comprehend because it addresses their particular needs. Six Sigma offers a two-step method for ensuring measurement accuracy:

1. Identify the problem - Find out what the customer needs or wants from the process. Methods for finding out what the customer wants from the process include surveys, focus groups, and market research. Compare information about customer needs to what your organization is currently measuring. The difference between what the customer wants and what the company provides is the process's problem.
2. Determine how to measure the problem - Review the strategy the company currently uses to measure process problems. Make sure that the method is without bias or agenda. Change or modify the measurement to match what the customer wants measured, that is, the problem.

An existing measurement may not always require modification, even if customers complain about a problem in the process. According to Six Sigma guidelines, measuring a process problem requires two steps:

1. Clarify the customer's need by identifying the problem in the process from the customer's point of view.
2. Help the team devise a strategy that measures the problem in that process.

Measuring the process problem is a necessary phase that precedes problem resolution. By identifying the problem in a process and modifying the existing strategy used to measure the process problem, a Six Sigma team creates an accurate way to assess the problem and measure the quality of the process itself.

Six Sigma – Defining the Problem Statement

A key element of a Six Sigma project charter is the problem statement. The problem statement is a clear and concise statement that describes the symptoms of the problem to be addressed.

A good example of a problem statement is, “Ten percent of the Invision system updates that we applied last month had to be backed out. This has caused a 18% increase in service desk issues.”
The problem statement provides three benefits to Six Sigma teams.

• creates a sense of ownership for the team
• focuses the team on an accepted problem
• describes the symptoms in measurable terms

The Six Sigma problem statement is clear, concise and well-written. Please use the following four guidelines in creating a problem statement.

• Define the problem - In the problem statement, team members define the problem in specific terms. They present facts such as the product type and the error made.
• Identify where the problem is appearing - Identifying where the problem is appearing, or manifesting, as specifically as possible helps the team focus its improvement efforts.
• Describe the size of the problem - The size of the problem is described in measurable terms.
• Describe the impact the problem is having on the organization - The description of the problem's impact on the organization should be as specific as possible.

The truth of the matter is that the more specific the statement, the better the chance the Six Sigma team has of fixing the problem.

The team should be wary of and try to avoid four common pitfalls when creating a problem statement;

• The problem statement should not address more than one problem.
• The problem statement should not assign a cause.
• The problem statement should not assign blame.
• The problem statement should not offer a solution.

The Six Sigma problem statement is a valuable tool that focuses the team on an acknowledged problem and describes the symptoms of the problem in measurable terms.

Planning Project Scope

Managing project scope requires a planning. The project scope is the foundation of all other project management activities and processes. The project scope management processes are:

• Scope Planning – Scope Planning is all about developing the Project Scope Management Plan. A document that provides how scope will be defined, verified, and controlled. In addition there are elements to discuss how the WBS will be created and defined.
• Scope Definition – Scope Definition is the preparation of a detailed Project Scope Statement.
• Create WBS (Work Breakdown Structure) – Creating the Work Breakdown Structure breaks the project deliverables and tasks into smaller and more manageable components.
• Scope Verification – Scope Verification is the way to provide a quality assurance check by stating how project deliverables will be validated and approved.
• Scope Control – Scope Control revolves around controlling and managing any changes to the project scope. This is a check and balance to assure the approved scope was implemented.

Now we come to the every popular when and where question. When and where do these processes occur in the five Project Process Groups?
These project scope management processes are interrelated with the five Project Process Groups as follows:

1. Initiating Process Group - None of the project scope management processes are found in in the Initiating Process Group.
2. Planning Process Group - Scope Planning, Scope Definition, and Creating the WBS occur in this process group.
3. Executing Process Group - None are found in this process Group.
4. Monitoring and Controlling Process Group - Scope Verification and Scope Control are done within this process group.
5. Closing Process Group - The closing process group does not contain any planning scope processes.

As a pm, it is important to know understand how to fight the evil scope creep. Knowing the project scope management process is a key factor in your fight.

Closing a project

Closing a project follows the same pattern as all other project management processes, there are inputs and outputs associated with closing a project, as well as tools and techniques to help with the process.
The inputs are used to verify project completion and validate that all issues are resolved. The inputs are:

• Project Management Plan - The Project Management Plan presents how the project is executed, monitored and controlled, and closed. It also documents the collection of outputs from the Planning Process Group processes.
• Contract documentation – Contract documentation details the requirements of contracts to supply the project with materials or resources, which are deemed to have been successfully delivered or not on the basis of a review of work performance information.
• Organizational process assets – Organizational process assets are the standards, policies, life cycles, quality documents, and procedures that have a bearing on the completion of the project. They must be updated to take account of any decisions to change or update these policies and procedures during project execution.
• Enterprise environmental factors – Enterprise environmental factors are any or all external environmental factors and internal organizational environmental factors that surround or influence the project's success.
• Work performance information – Work performance information is the raw data about the status and quality information of all completed activities. It is used to confirm that all necessary activities have been completed and that the project and its contracts can be closed.
• Deliverables - A deliverable is any unique and verifiable product, service, or result that must be produced to complete a process, phase, or project. When all deliverables have been approved, the executing processes end and the closing processes begin.

To assure that everything necessary has been completed and the project meets its objectives, a project manager will continue to use the same tools and techniques as from the previous integration knowledge group processes.
The tools and techniques that you'll use in this final phase are:

• Project management methodology - A project management methodology will provide you with the guidance, procedures, and templates that you'll need to manage project closure. The methodology should provide a guideline to help validate all products have been delivered and approved by the customer.
• Project management information system (PMIS) – A PMIS is a repository for all project related data, documents, and information. This central repository can be used as an archive for knowledge sharing across future projects.
• Expert judgment – The team will also need to rely on their collective experience to review the outcomes and determine the project has been satisfactorily concluded.

From project initiation through execution and monitoring, you will have used methodologies, tools, and expert judgment to help you deliver on all aspects of the project. At the close of a project, these tools and techniques will help you ensure that everything is completed, recorded, stored, and accessible for future reference.

Closing a project can vary greatly from one project to another. Every project is different, so each will have different techniques for measuring satisfaction in each area. There are four outputs from closing a project.

• Administrative closure procedure – The administrative closing procedure includes collecting project records, analyzing project success or failure, gathering lessons learned, and archiving project information for future use.
• Contract closure procedure – The contract closure procedure addresses the terms and conditions of any agreements relating to the project. The closure procedure ensures that all responsibilities have been met, all results are verified, sign-off is received, and payments are made.
• Final product, service, or result - The final product, service, or result is the item or items, service, or result that the project was commissioned to deliver. It also includes any ongoing warranty period.
• Organizational process assets updates - Changes to procedures that impact future projects, completion or termination closure documents, and project files are all process assets that can be recorded in a lessons-learned knowledge base.

Going through the project is very rewarding although time-consuming. It provides an opportunity to learn from the experience, and assurance that everything is truly completed.

Integrated Change Control

In project management, integrated change control is a way to manage the changes incurred during a project. Integrated change control is the described method that manages reviewing the suggestions for changes and utilizing the tools and techniques to evaluate whether the change should be approved or rejected.

The inputs for integrated change control include the following:

• Project Management Plan – The project management plan is the basis for all project activities, so it offers insights when considering changes and deciding whether to proceed with the change or not.
• Requested changes – Requested changes arise from the executing or monitoring and controlling process groups.
• Work performance information – Work performance information acts as an input because the information will influence your decisions on how to handle the requests and recommendations you receive.
• Recommended preventive actions – Recommended preventive actions are recommendations or requests that are generated as the project progresses. Normally to alleviate, mitigate or avoid a risk.
• Recommended corrective actions – Recommended corrective actions result from the identification of problems, while others result from the Monitor and Control Project Work process.
• Recommended defect repairs – Recommended defect repairs are all produced as outputs from the Monitor and Control Project Work process.
• Deliverables – The project manager may need to make changes to deliverables as a result of decisions made while evaluating change requests.
  Having a functional, working, and understood integrated change control process is a way to manage and handle changes to the project management plan.

To make sure that these changes are reflected in your project components you'll have to use the following tools and techniques:

• Project management methodology - A project management methodology provides guidelines, procedures, and templates for implementing integrated change control. The methodology may be specific to your organization, external standards, or a combination of both.
• Project management information system (PMIS) - A PMIS can house project documents and control a user's ability to edit these documents. Additionally, a PMIS can automatically generate notifications to alert team members when documents have changed.
• Expert judgment - Expert judgment means using your past project experience—and that of your teammates and coworkers—to make decisions about whether to approve or reject requested changes.

Using these tools and techniques it is easier to assure that changes are implemented and recorded and that their impact on the project baseline is recognized.
A control process in place for changes needs to have consideration for the impact the changes will have on the project outcomes. These effects should be updates to the project management plan, scope statement, and deliverables. The outputs of an integrated change control process are:

• approved change requests
• rejected change requests
• Project Management Plan (updates)
• Project Scope Statement (updates)
• approved corrective actions
• approved preventive actions
• approved defect repairs
• validated defect repairs
• approved deliverables.

When evaluating changes needed in a project, speed of evaluation is important. The worst place is to have no anticipated times for a change evaluation decision. Either the project will have time added to its timeline, or changes that are not evaluated will start to consume project resources.

Monitoring and Controlling Project Work

Considering that the Project Management Plan is the baseline for the project. This is guide for monitoring and controlling the project. As a project manager, one will need access to work performance information, performance reports, and change request. This information will need to be at your fingertips as inputs to yield project performance indicators. After analyzing and reviewing the information, it is time to decide whether corrective or preventative actions are needed.

The four inputs to monitoring and controlling project work are:

1. Project Management Plan – The project management plan is the main source of information about how the project will be executed, monitored, and controlled. It is the plan, with all additional subsidiary plans as needed.
2. Work performance information – Work performance information is the information about project activities. This includes status information about progress, deliverables, expenses, and quality assurance validations.
3. Rejected change requests – Reject change request can be enlightening when reviewed in the context of determining how the progress of the project is fairing.

Remember the quality of the measurement is only as good as the data gathered to ascertain the measurement. While it may take time, being vigilant and reviewing this information will save one headaches in the long run.

So how do you sort through the granular details and formulate it into information? Well the good news is this isn’t a single problem, it affects all project managers, and there are standardized tools and techniques for monitoring and controlling project work.

These tools and techniques are:

• Expert judgment - On the basis of current project information and experience with similar projects, project managers and team members can use expert judgment to make decisions, such as whether to take corrective or preventive actions.
• Earned value technique (EVT) – Earned Value Technique (EVT) provides project managers with a means of calculating current project schedule and cost performance. Project managers can then use this information to forecast future schedule and cost performance.
• Project management methodology – The organizational project management methodology provides project managers with detailed guidance and procedures to enable effective monitoring and control through each stage of a project.
• Project management information system (PMIS) - A PMIS allows for monitoring and controlling parameters such as cost and resource usage. A PMIS can also enable project managers to calculate and manage earned value information, as well as request and update project information automatically.

Using the correct tools and techniques will help keep you in the loop of what’s going on with your project.
Obviously as one monitors and controls there will be some action items that occur. These action items cycle back into the project execution. So what are some outputs or action items that occur during the Monitor and Control Project Work process?

The outputs of monitoring and controlling project work are:

• Recommended corrective actions - These are based on project work performance information. By comparing this information to the project plan, the project manager or team uses expert judgment to put forward ideas to remedy problems that have arisen.
• Recommended preventive actions - These are based on project work performance information. By comparing this information to the project plan, the project manager or team uses expert judgment to suggest ways of avoiding project risks.
• Forecasts - Based on work performance information received during the Monitor and Control Project Work process, forecasts allow the prediction of successful or unsuccessful project outcomes.
• Recommended defect repairs - These are an output of monitoring and controlling project work. This output recommends the remedial work necessary when a product does not meet quality requirements.
• Requested changes - These are revised actions that are necessary for meeting project objectives. The requests are often made by the project manager or members of the project team as a way of improving methods or overcoming problems.

Just keep in mind that every organization is different, and your experiences of monitoring and controlling project work will depend on your company's project management methodology and the type of project.

Directing and Managing Project Execution

There are times it is about the planning, and then there is always the execution. Ideas are fundamentally wonderful. Implementing them is another matter. Directing and Managing project execution has the same characteristics as most of the PMI processes. There are inputs to the process, tools and techniques to use within the process, and outputs of the process.

Before one starts directing and managing project execution, it is good to have the following approved and validated inputs. Since the inputs are the basis for your course of action, and they are the path followed. It is a good idea to have them validated by the team and stakeholders. The six inputs to directing and managing project execution are:

• Project Management Plan – The project management plan is the plan on how a project will be executed, monitored, and controlled.
• Approved corrective actions – Approved corrective actions are authorized and documented actions that are taken to ensure that the project's performance conforms to the project plan. Approved corrective actions help keep projects on track.
• Approved preventive actions – Approved preventive actions are authorized and documented actions that are taken to reduce the likelihood that risks will damage or adversely affect a project's progress.
• Approved defect repairs – Approved defect repairs are requested to make fixes that have been authorized and recorded but not implemented. For example, if a defect is found during a quality inspection, a defect repair may be required. This defect repair needs to be approved before any action can be taken. Issues identified during testing that need to be resolved are normally approved defect repairs.
• Validated defect repairs – Validated defect repairs provide notification that repaired items have either been accepted or rejected following reinspection. After a repair has occurred, the item must be reinspected to determine whether it meets quality requirements.
• Approved change requests – Approved change requests are project changes that have been agreed on and documented. Examples include changes that affect project scope, the Project Management Plan, procedures, costs, budgets, or schedules. The project team implements changes as part of project execution.
• Administrative closure procedure - The administrative closure procedure details all the tasks, interactions, roles, and duties required to formalize project completion.

Once you have gathered all the inputs to directing and managing project execution, you should have firm footing to lead you down the path to project nirvana. However along the way there are some tools and techniques, that can aid you in your endeavors.

There are tools and techniques that you can use to direct and manage the execution of your project. They are:

• Project management methodology - A project management methodology is a documented process that contains roles and responsibilities, procedures, and definitions. A project management methodology can be your organization's own guidelines, or it can be an external standard. The methodology should contain some procedures that provides roles and responsibilities for the project manager, stakeholders, and team members.
• Project management information system – The project management information system is used to report on project activities, and track the progress on a project.
  To successfully direct and manage project execution, you have to know your team is doing, how they are planning to complete the task, and that everyone is on the same page about project activities. A project management methodology, combined with a project management information system, will helps coordinate activities and assure good communications with the team.

As you are going through the process of executing and directing your project let’s take a moment to discuss the outputs of that process. The outputs are:

• Deliverables - Deliverables are the outcomes that have been achieved as specified in the Project Management Plan. They might be products, results, services, or a combination.
• Work performance information - This is data on the status of the project activities being performed to accomplish the project work and is collected as part of the Direct and Manage Project Execution process.
• Requested changes - A requested change is a change that has been requested by a project stakeholder or team member but has not yet been approved or implemented. Requested changes can be direct or indirect, externally or internally initiated, and either optional, or legally or contractually mandated. These are often identified while project work is being performed. These requests can be to expand or reduce project scope, modify policies or procedures, modify project cost or budget, or revise the project schedule.
• Implemented change requests, implemented corrective actions, implemented preventive actions, and implemented defect repairs - These all relate directly to the completion of approved work. When creating outputs, you will have to implement the actions that have been approved as inputs.

Remember, for every input, there's an output. Also the old saying is true garbage in, garbage out.

Release Management Lessons Shared

Release management is all about having an efficient process of introducing new hardware and software into the IT infrastructure. However, there are some standard problems and costs that can occur at every company. Implementing a release management process is a culture change for most organizations, and as with any change there are some standard issues.

The issues one can expect to encounter with a new release management process are:

• Resistance - During the implementation of release management, some employees may cling to old processes and bypass the release management process. It may take time and repeated effort to bring the whole company into compliance with the new procedures.
• Responsibilities – It is not unusual to experience some confusion about responsibilities. Ownership of some activities may change. Also, new responsibilities will be created and owners will be assigned to them.
• Time – Often those places with the most releases have the most to gain from implementing a release management process, have the least amount of time because of the large number of releases. Working smarter is applicable here.

Also there are costs that can be expected to be incurred during the implementation of the release management process. The major costs normally are:

• Facilities - The release management process may require new facilities, including dedicated storage space for hardware and software configuration items. Companies that implement release management report increased costs for secure storage.
• Tools - The release management process may require new hardware and software tools and new network capabilities. These tools may be purchased from outside vendors, or they can be developed internally.
• Employees - The release management process requires trained employees who can perform the activities of the process. Even if no new employees are hired for release management, the process may require many hours of each employee's time.

These issues and costs are pretty standard as a component of implementing and operating with the context of a release management system. However planning for these items, is a better course of action than simply letting them occur.

Release Management Management Tools and Techniques

All processes need quality control checks. They also need someone to manage and assure a successful process. In ITIL release management, the controller of the release management process is the release manager.

The release managers duties are:

• To act as an Advocate - One of the release manager's roles is to clearly communicate the benefits of adopting release management practices to system users, company managers, and to colleagues in the IT department. Think of it as a one man marketing campaign.
• To be an Investigator - Another important role of the release manager is investigating how and why new configuration items make their way into the live environment without following the release management process. This would be commonly referred to as auditing and investigating.
• To be a Trainer and communicator - The release manager is the point of communication between the release management process and other IT service processes. This role also includes providing written and oral instructions for introducing new releases to the customer base. It is really a good thing to centralize this because with centralization comes standardization.

When I first started in IT, we had this product upgrade that was overwhelming and time consuming. Every two months, we had to make the product unavailable for half a day toupgrade the system. Talk about disturbing the operations of the business. Thankfully we improved upon the implementation pattern and eventually eliminated that application. A successful release management process is determined by controlling the introduction of new releases without creating disruptions within the company. Here are four key performance indicators used to determine the success or failure of your release management process:

1. Schedules and budgets – Completing releases on time and within budget is a good indication that the process is successful.
2. Failures and backouts – Having a low occurrence of failures and back outs is an indication that releases have been properly planned and executed. Backing out a release normally equates to the fact that the release wasn’t tested thoroughly on the company infrastructure or with other systems.
3. DSL and DHS - A complete and up-to-date definitive software library (DSL) and definitive hardware store (DHS) indicate release management is exercising adequate control over new releases. The control of CIs in new releases ensures that they conform to planned standards.
4. Records and updates - The ability to plan and execute releases depends on an accurate configuration management database (CMDB). Release management must provide information about the changes new releases make to the infrastructure so the database will remain accurate. Release management's actions affect the efficiency of the rest of the company.

As the old saying goes it is difficult to manage that what you cannot measure. There are several managerial reports that assist in determining the opportunities for process improvement and rate how well the release management program is maintaining.

• by level - A report that shows the number of successful releases illustrates the degree of control the release management process exercises over the introduction of new hardware and software.
• actual versus plan - A report of successful releases should show the number of major, minor, and emergency releases. A report of successful releases should compare the actual time and cost of implementing releases to the planned time and cost.
• number of releases that failed - A report of the number of releases that failed reveals opportunities to improve the release management process.
• number of problems or errors caused by releases - A report of known problems resulting from releases provides an indication of inadequate planning or testing of releases. Although it's sometimes difficult to own up to mistakes in planning, this type of report provides a basis for discussing plans for improving the release management process.

The members of the release management team who plan and execute releases must pay close attention to details. The duty of the release manager and other senior company managers is to look at the big picture and direct the action with correction or preventative steps.

Developing the Project Management Plan

We know that the project management plan is the key document that contains the overall planning, monitoring, and implementing activities to be done in a project. So how does one derive such a document?

First one has to look at what one has around the desktop. The inputs for developing a Project Management Plan are:

• Preliminary Project Scope Statement - The preliminary Project Scope Statement forms the basis of the scope section of the Project Management Plan and includes a description of the scope, its boundaries, and the major deliverables.
• Project management processes - Project management processes are descriptions of how the project will be managed. For example, communication management at your company might include status updates included in the project bulletin board.
• Organizational process assets - Organizational process assets are resources, procedures, or processes, from any or all of the organizations involved in the project, that influence the process or outcome of a project. Plans, policies, procedures, and guidelines may be used to develop the Project Management Plan. For example the process of installing net new equipment in the data center is a part of the processes of the organization. Another is the skill set of current employees.
• Enterprise environmental factors – Enterprise environmental factors occur within and outside an organization from any or all of the organizations involved in the project that may affect the project outcome. Factors such as a company's culture and market conditions may be used to develop the Project Management Plan.

A key aside is the Project Management Plan needs to consider any conditions or factors that might impact it.

Thankfully, there are tools and techniques that can be used when developing the Project Management Plan. These tools and techniques are:

• Project management methodology - A project management methodology is an organized approach to creating a Project Management Plan. Methodologies can be simple or complex depending on the project type and the needs of the performing organization.
• Project management information system (PMIS) - A PMIS is typically a computer-driven system that helps a team develop the project plan. It can calculate schedules, costs, probable outcomes, and expectations. It can also publish the approved document.
• Expert judgment – Expert judgement is relied upon to develop technical and managerial details to be included in the Project Management Plan. Expert judgment is the technical and management expertise of the project management team. For example an experienced employee and an organization will have more insights into corporate culture, than a new hire.

Now we have the inputs, tools and techniques to use as we create a project management plan. The next step is actually having the plan and its components. The Project Management Plan consists of 11 core components for executing, monitoring, and controlling. There may be more, but the 11 is a good place to start. The eleven core components of a Project Management Plan are:

1. The processes determined by the project management team
2. The implementation level of each process chosen by the project management team
3. The descriptions of the tools and techniques to be used for accomplishing those processes
4. The chosen project life cycle and related project phases
5. How the selected processes will be used to manage the specific project
6. How work will be executed to achieve the project objectives
7. How changes will be monitored and controlled
8. How configuration management will be performed
9. How project management baselines will be maintained
10. Communication techniques among stakeholders
11. When management reviews will be scheduled to address issues and pending decisions.

Another way to go about developing a project management plan is gathering and collecting all subsidiary plans in the Project Management Plan. Subsidiary plans are the outputted document for planning from a knowledge area. These can also be included in the Project Management Plan. These plans are:

1. The Scope Management Plan
2. The Schedule Management Plan
3. The Cost Management Plan
4. The Communication Management Plan
5. The Process Improvement Plan
6. The Staffing Management Plan
7. The Quality Management Plan
8. The Risk Management Plan
9. The Procurement Management Plan.

When you create and follow a Project Management Plan that is composed of the nine subsidiary plans, you'll have a map that will guide your decisions and actions and help you reach your desired destination: a successful project.

Release Management Activities and Methodology

Take a moment and recall, release management is about controlling the flow of changes into a production environment. In order to control, one needs to know what is being controlled and how it is being controlled, so we need a plan.

The major elements of a release plan include the following:

• Build and test plan - The build and test plan describes how final versions of configuration items (CIs) will be existing in the production environment. Building and Testing in a prescribed agreed to manner assures that a standardized process is used to prepare new hardware or software. Software configuration items should be compiled on dedicated equipment. Hardware configuration items should be assembled and tested away from the live environment.
• Rollout plan - The rollout plan describes how the physical installation of configuration items will be accomplished. The rollout plan lists the configuration items to be installed or removed, the time frame for installation, and the locations where the configuration items will be installed.
• Backout plan - A release plan must include a backout plan to be followed in the event that a release doesn't work as expected. A backout plan may list steps to completely reverse a release or identify measures, such as using manual systems to restore service if a complete reversal isn't possible. There should also be a time of day when the backout plan will commence, not a duration effort.
• Communication plan - All participants in a release must know in advance what preparations must be made. A communication plan lays out the steps that will be taken to notify all participants of their roles in a release.
• Acceptance plan - Acceptance plans establish the conditions for the success of a release. After a release has been installed, users verify that the release meets their requirements. Then users give their final approval.

Performing a process the same way every time makes it more likely that you'll see the same, predictable output. It removes the variation which causes issues and problems. When the release management process is properly used, the installation of a release results in these predictable outputs:

• An upgraded IT service -The purpose of any release is to improve the services available to users of an IT system. Releases remove the causes of errors, or they add new features and capabilities to the system. An upgraded service is the primary output of a release.
• Updated records in the configuration management database (CMDB) - All changes made to the IT system should be recorded in the configuration management database (CMDB). Release management notes all changes that occur during installation. Configuration management updates the appropriate records in the database.
• Collected CIs to be retired - Many releases replace older versions of CIs or make them unneeded. Hardware or software, and the documentation that accompanies them, should be collected and removed during the installation of a new release. It is a good process to follow and removes from your configuration management system all retired components. The end of lifecycle for a product can be as important as the beginning.
• Known errors caused by the installation of the release - Although new releases should be carefully tested, many will introduce unexpected problems that will be discovered soon after the release is installed. The final output of a new release is a list of known errors caused by the release. This would be very helpful to give to your service desk.

Release management activities are carefully planned to be standardized and repeatable. Consistent execution of release plans minimizes the risk that changes in the system will disrupt a company's business.

Developing the Preliminary Project Scope

The preliminary Project Scope statement documents product requirements, project boundaries, methods of acceptance, and high-level scope control. As scope is defined a shared understanding among the stakeholders and project management team occurs, and it is further defined by the projects boundaries. This process of reviewing and analyzing project scope is commonly referred to as the Scope Definition process.

There are four inputs into the process of developing a preliminary project scope. They are:

1. Project Charter - This is the document that formally authorizes a project.
2. Statement of Work (SOW) - The SOW is a narrative description of products or services to be supplied by the project. It often indicates a business need, product requirements, and the strategic alignment with the performing organization.
3. Enterprise environmental factors – The Enterprise environmental factors are conditions within and outside an organization, from any or all of the organizations involved in the project, that may have an effect on the project outcome. Such factors include a company's structure and resources, and market and industry conditions.
4. Organizational process assets – Organizational Process Assets are resources, procedures, or processes, from any or all of the organizations involved in the project, that influence the process or outcome of a project. Organizational process assets include plans, policies, procedures, and guidelines.

The preliminary Project Scope Statement defines the project and establishes what must be accomplished at a high level. Commonly there are tools and techniques exploited by the project team to create the preliminary Project Scope Statement. These tools and techniques are:

• A project management methodology - A set of guidelines or principles that can be tailored and applied to a specific situation. This methodology aids a project team in the development of the preliminary Project Scope Statement. For example, the system development life cycle methodology is often used to in IT projects.
• A project management information system (PMIS) - A PMIS provides tools, including document management and collaboration tools, that can help project managers control project information and aid in the development and publication of the preliminary Project Scope Statement.
• Expert judgment - The exercising of skills or knowledge gained from previous experience to make decisions on the project at hand. It is applied to technical and management details to be included in the preliminary Project Scope Statement. Am example of expert judgement is the project teams inclusion of patient census and patient days report for the design of a hospital registration reporting system.

Once you have it the preliminary Project Scope Statement content typically includes 14 components – give our take a few as one traverses industries.

1. Project and product objectives - Project objectives are the measurable success criteria of the project. Product objectives are the desired characteristics of the product, service, or result that the project was undertaken to create.
2. Product or service requirements and characteristics - These are conditions or capabilities that must be met or possessed by a system, product, service, result, or component to satisfy a contract, a standard, a specification, or other formally imposed documents.
3. Project boundaries - Project boundaries explicitly define what's included in and excluded from the project.
4. Project requirements and deliverables - Project requirements describe the conditions or capabilities that must be met or possessed by the project deliverables to satisfy stakeholder expectations. Project deliverables include the outputs of the project and auxiliary results, such as reports and documentation.
5. Product acceptance criteria - Product acceptance criteria include performance requirements and essential conditions that must be met before project deliverables are accepted.
6. Project constraints - A constraint is a state, quality, or sense of being restricted to a given course of action or inaction. It is an applicable restriction or limitation, internal or external to the project, that will affect the performance of the project or a process.
7. Project assumptions - Assumptions are factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration. Assumptions affect all aspects of project planning.
8. The initial project organization – the project organization consists of the project team members, project stakeholders, and performing organization.
9. The initial defined risks – Risks are possible events or conditions that would have a significant effect on the project outcome if they were to occur. Some risks, when matched with their possible outcomes, could lead to time and cost overruns.
10. Schedule milestones – Milestones are key events in the project schedule that may affect the project timeline. Schedule milestones also indicate the completion of a major deliverable. An example is the completion of a design prototype.
11. Initial work breakdown structure - A WBS is a hierarchical chart that shows the breakdown of a project's activities and deliverables. The initial WBS should consist of a "bare bones" outline of activities and deliverables.
12. The order-of-magnitude cost estimate – The order-of-magnitude cost estimate is one way to estimate the project's cost. It is an estimate that is made without detailed data.
13. Project configuration management requirements – Configuration Management requirements describe the degree to which configuration management and change control will be implemented on the project.
14. Approval requirements – Approval requirements outline approval processes and procedures that can be put in place by any stakeholder. Approval requirements can be applied to project objectives, deliverables, and work.

The Preliminary Project Scope Statement provides a guideline for project decision and assures a shared knowledge of project scope among stakeholders has occurred.

Project managers will continue to refine project scope as the project continues, but they need to develop a preliminary version to establish project scope for progressing through the initial project phases.

Developing the Project Charter

Congratulations, you have been elected to write a charter. So with about 5 dollars you head over to your local starbucks and wonder what to do next. A project charter is a pretty systematic document. If you have one at your organization, you can derive several others from that foundational work.

In developing a project charter, there are several inputs to the process:

1. Contract - The contract that is used as an input is the contract between your organization and the organization you're asking to provide a product or service.
2. Statement of Work (SOW) - An SOW is a narrative description of products, services, or results to be supplied. The SOW indicates a business need, a product scope description, or a strategic plan.
3. Enterprise environmental factors – Enterprise environmental factors are any external environmental factors and internal organizational environmental factors that surround or influence the project’s success. These factors include organizational culture and structure, infrastructure, existing resources, industry databases, and market conditions.
4. Organizational process assets – Organizational process assets are any or all process-related assets, from any or all of the organizations involved in the project, that can be or are used to influence the project's success. These include processes and procedures as well as the organization's lessons learned and other historical information.

The inputs for creating a Project Charter are contracts, Statements of Work, enterprise environmental factors, and organizational process assets. You may not use all of these inputs for every Project Charter, but using some of these inputs is a good place to start before chartering.

A project manager requires an appropriate set of tools and techniques to build a Project Charter. With these tools and techniques, the project manager and project team can act on the inputs to create outputs. Creating a good charter often requires relaying on appropriate tools and techniques:

• Project selection methods – Project selection methods are used by the performing organization to determine which projects to undertake. Such methods include benefit measurement methods, constrained optimization (mathematical models), and decision models.
• Project management methodology - The methodology refers to a collection of processes, project process groups, and control functions that include formal and informal methods to help a team develop a charter. One such methodology is called the agile development lifecycle another could be ITIL release management.
• Project management information systems (PMISs) - A PMIS is a set of automated tools accessible within an organization and integrated into a system. It is used by a team to create a Project Charter, elicit feedback, manage changes, and submit the approved document. Some organizations successfully use project central and sharepoint as their PMIS.
• Expert judgment – Expert judgement is used to evaluate the inputs needed for Project Charter development. People with specialized knowledge apply expertise to project details during the Project Charter development process.

By applying these tools and techniques to the Project Charter inputs, the project manager and project team can develop the Project Charter.

Developing the Project Charter is the start for the rest of the project. The inputs and tools and techniques are used to create the Project Charter, which is the output of the Develop Project Charter process.

A Project Charter provides an overview of the project and its goals. The Project Charter details the project purpose, overview, goals, and high-level deliverables.

The elements of a Project Charter are:

• The project overview - A project overview contains a description of the business need, purpose, and product or service that is to be provided.
• Preliminary roles and responsibilities - This section describes the duties of the project team. This includes people who should be involved and why and how they might be involved. This might include customers, stakeholders, and the project team.
• Identification of the project manager - The project manager identification designates the project manager who has primary project oversight responsibility.
• A description of the project manager's authority - The description of the project manager's authority outlines the level of authority given to the project manager. This would include financial oversight and level of decision making.
• Sign-off - This is the approval required from the project's sponsor to give the go-ahead to the project.

When the sponsor or sponsors sign off on the charter, it marks the beginning of the planning phase of a project.

ITIL: Release Management Overview

Release management process is about controlling and monitoring the flow of changes into an IT infrastructure. Each update or upgrade of a Configuration Item is referred to as a release.

There are three levels of releases. These levels related to releasing hardware or software into your IT infrastructure. Some may be a single change, others may implement many changes at a time.

• Major - A major release usually introduces new capabilities or functions. Major releases may accumulate all the changes from previous minor releases. Major releases advance the version number by a full increment, for example, from version 5.70 to version 6.
• Minor - Minor releases incorporate a number of fixes for known problems into the baseline, or trusted state, of a item. Minor releases usually increment the version number at the first decimal place. For example, version 6.10 would change to version 6.20.
• Emergency - Emergency releases are quick fixes to repair unexpected problems or temporary measures to prevent the interruption of critical services. Emergency releases increment the version number at the second decimal place, for example, from 3.1 to 3.1.1.

Some releases of new versions of hardware or software introduce incremental changes, while other releases include completely new versions. There are three types of releases to reflect different ways of bundling and deploying changes to hardware or software CIs together. These types are:

1. Delta release - A delta release only includes the elements of a hardware or software CI that have changed. The changes are added to the existing version of the CI. In delta releases, it's not always possible to test how changes will affect the rest of the live environment.
2. Full release - A full release includes all the elements of a hardware or software CI, even those that have not changed. In full releases, the effect of the changes is more carefully tested and less likely to cause incidents during implementation.
3. Package release - A package release rolls the changes to different CIs into a single release. This release may include changes to hardware and software CIs and can contain delta and full releases. Package releases minimize disruptions in the IT environment.

Making changes to an IT infrastructure creates a risk that the changes will have unforeseen results. Careful execution of releases avoids errors and disruptions. There are five steps in the release management process:

• Build and configure - The components of the release are assembled in a controlled laboratory environment.
• Test and accept - Prior to distribution, testing by an independent group occurs. Testers can be business staff, users, or other IT staff. They verify the release using several testing methods; then it can be rolled out.
• Schedule and plan - The rollout of the release must be carefully planned and scheduled. The plan should include a list of all CIs to be added or removed and a schedule of activities at each location involved in the rollout.
• Communicate and prepare - Release management must communicate the rollout plan. Each participant needs to know what preparations to make. Users, managers, and technicians who will implement the release need to know what will happen and when it will happen.
• Distribute and install - When the planned date for installation arrives, the release can be installed according to the prepared plan. Hardware and software must be distributed to the installation site. Installers must follow a prepared script of activities to complete the installation.

Release management stores the master copies of all software applications in a Definitive Software Library (DSL). The library provides a storage facility that keeps master copies of software separate from copies in the live, test, or development environments. The contents of the DSL are recorded in the configuration management database.
Definitive hardware store (DHS)

The Definitive Hardware Store (DHS) is a secure storage location that contains duplicate copies of hardware CIs and assemblies. The CIs are identical to those in use. The spare CIs must be kept ready for use. Any changes to the configuration of CIs in the live environment are also made to the spares in the DHS. If a hardware CI fails, it can be quickly replaced.

A company's information needs change constantly. The available technology changes rapidly. The release management process provides a way to manage change without creating chaos.

Project Integration Management Processes

Project integration management is primarily concerned with integrating processes to accomplish project objectives.
The seven process are:

1. Develop Project Charter – Develop the Project charter is initiates the project. The derived project charter approves and sanctions the project and gives the project manager the authority to act and apply organizational resources to the project.
2. Develop Preliminary Project Scope Statement – The preliminary project scope statement is an initial, high-level definition of the project scope. This document defines the project’s product or service, methods of approval, and tactical strategies for the change control process.
3. Develop the Project Management Plan – Developing the Project Management Plan includes all activities needed to create and integrate all subsidiary plans into the Project Management Plan. This plan will be how the project is executed, managed, and monitored.
4. Direct and Manage Project Execution - Directing and Managing Project execution is orchestrating how the project team performs the actions to implement the Project Management Plan and complete the work detailed in the Project Scope Statement.
5. Monitor and Control Project Work – Monitoring and Controlling Project work measures and balance the projects progress and any corrective or preventative actions needed to assure all project objectives are met.
6. Integrated Change Control – Integrated Change Control is the change control process for the project which includes evaluating all change requests, authorizing changes, and managing changes to project plans and deliverables. The key benefit to this process is that only validated approved changes are implemented.
7. Close Project – Closing the project equates to completing all project activities, delivering the final project, turning over continual support to operations, and obtaining the client approval to formally close the project.

The seven processes in the Project Integration Management knowledge area work in concert to facilitate proper project coordination. The project integration requires each process seamlessly links and fuels the next process
All project management processes are divided into the following five project process groups:

• Initiating - The Initiating Process Group includes those processes necessary for formally authorizing the beginning of a new project. The processes for developing the Project Charter and developing the preliminary Project Scope Statement occur in the Initiating Process Group.
• Planning Process Group - The Planning Process Group includes those processes that establish the project scope, create the Project Management Plan, and identify and schedule the project activities. The process for developing the Project Management Plan occurs in the Planning Process Group.
• Executing Process Group – The Executing Process Group consists of those processes necessary for completing the work outlined in the Project Management Plan to achieve the project's objectives. The process for directing and managing project execution, which ensures that the Project Management Plan is implemented properly, occurs in the Executing Process Group.
• Monitoring and Controlling Process Group - The Monitoring and Controlling Process Group is necessary for gathering, assessing, and distributing performance information and analyzing measurements and trends to make continual process improvements. The processes for monitoring and controlling project work and implementing integrated change control occur in the Monitoring and Controlling Process Group.
• Closing Process Group – The Closing Process group consists of those processes necessary for officially ending project activities and handing off the completed product to others. This also includes closing a project that has been canceled.

The project process groups overlap, interact, and directly affect one another as they all play out the greater project plan. These interactions create project management synchronization.

Closing Process Group

Project closure is an important part of the overall project lifecycle. It brings things to the ended state in a formal approved way. PMBOK defines the Closing Process Group as “Those processes performed to formally terminate all activities of a project or phase, and transfer the completed product to others or to close a cancelled project.
It’s a nice way to move the project into the normal business operations or review cancelled projects to gleam information from them.

Projects are cancelled for numerous reasons. A late start to a project can ultimately cause the project to cancel. Budget cuts can cause end the funding of a project and bring it to a pre-mature end. Having a project with an inadequate skillset can bring about the end of a project. Also having a plethora of project changes can result in draining the life from the project, causing a cancellation situation. Also the idea of with ultimate resources one can rebuild the pyramids or unrealistic project objectives bring about the cancellation of a project - at least in profit based organizations.

Whether a project is successful or not, it is good to record the lessons learned from the project. These lessons are feed from the successes and failures in the project. It is important to keep this information and inject the knowledge into other project, current and future.

The Closing Process Group coordinates project completion required to close or cancel a project and document the lessons learned. There are two key processes that need to be executed in closing activities:

• Close Project - Close Project is defined by PMBOK as: "The process of finalizing all activities across all of the Project Process Groups to formally close the project or phase." The Close Project process can be described as documenting administrative procedures for the completion of a project and preparing contract closeouts. For example updating the organization process assets within the configuration management database are typical project closing activities.
• Contract Closure – Contract Closure is defined by PMBOK as “The process of completing and setline the contract, including resolution of any open items and closing each contract” This is essentially the completion and settling of contracts.

A closed project may mean cause for celebration or a sigh of relief. It definitely means that the project phase has been completed, the project has been finished, or it was cancelled.

Monitoring and Controlling processes

Monitoring and Controlling a project touches every facet of the project lifecycle. Changes can occur that impact project scope, time, cost, and quality. These changes need to be managed to assure there are no downstream impacts. While engaged in a project it is necessary to be aware of the impacts and affects of too little or too much resources and communications.

Within the Monitoring and Controlling Process Groups there are ten processes utilized. Five processes address scope, time, cost, and quality including the change herewith in the project lifecycle. The other five processes are overseeing the resources, communications, risk, and procurement processes.

The five process that address changes to scope, time, cost, and quality are as follows:

• Scope Verification – Scope verification is the process to obtain official acceptance of the completed project scope. A project scope that has not been officially reviewed and signed off on won't be beneficial as the project progresses.
• Scope Control – Scope Control engages in managing changes to the Project Scope. The Project Scope encompasses any identified work that will produce a product, service, or result.
• Schedule Control – Schedule Control is the process of managing changes to the Project Schedule. The Project Schedule outlines the timeline for various deliverables.
• Cost Control – Cost Control is the process of directing the cost factors that create variances, and controlling budget changes. Since the budget identifies agreed-upon expenditures for every line item, it has to be supervised closely.
• Perform Quality Control – Perform Quality Control involves monitoring the specific results of a project to assess whether those results are consistent with relevant quality standards. It also identifies ways to eliminate causes of unsatisfactory performance.

This Process Group also has the role of monitoring resources, communications, risk, and procurement. These variables must be contained as well to keep a project on track.

• Manage Project Team - The Manage Project Team process tracks team performance, giving feedback, handling issues, and coordinating changes to improve project performance. The goal is to improve overall performance through assessment, guidance, and problem solving.
• Performance Reporting – Performance reporting involves collecting and disseminating information about performance. This includes status reporting, progress measurement, and forecasting. This process is about measuring, documenting, and forecasting project performance.
• Manage Stakeholders – Managing Stakeholders is the process of managing communications with project stakeholders to satisfy their requirements and resolve their issues. This process involves diplomacy, tact, and a willingness to facilitate a two-way conversation.
• Risk Monitoring and Control – Risk monitoring and control involves assessing identified and residual risks, identifying new risks, executing risk response plans, and assessing the responses plan’s effect on the project.
• Contract Administration - Contract Administration is the process with deals with contracts and contract changes. Contract Administration manages the relationship between the buyer and the seller, and is the foundation for future vendor/business relationships.

With twelve processes in total, the Monitoring and Controlling Process Group is comprised of processes spreading across all nine Knowledge Areas. Remember iteration and constant vigilance is key when engaged in project management the processes of the monitoring and controlling process group will be a key tool in measuring project performance.

What are the Monitoring and Controlling Process Groups and Integrated Change Control

Monitoring and Controlling Project Work and Integrated Change Control processes are how one obtains information about the health of a project. These processes extended throughout the project lifecycle and are fueled by information from each of the other processes in the group.

The Project Integration Management knowledge area relates to the synchronization of all project activities to create a unified whole. Monitoring and Controlling Project Work and Integrated Change Management are a part of Project Integration because:

• Monitoring project work extends through all five Process Groups to ensure an effective project.
• Integrated Change Control process also occurs throughout the project and its purpose is to manage changes in a coordinated fashion.

Monitoring and Controlling project work and Integrated Change control utilized the schedule progress, deliverables completion information, quality results and cost expenditures from the work performance information of the Executing Process Group. The Monitoring and Controlling Project work process compares the actual results to the planned results to obtain variances in order to determine the corrective actions needed to re-align project performance. The outputs of monitoring and controlling are recommended corrective actions, recommended preventative actions, forecasts, recommended defect repair and requested changes.

The Integrated Change Process keeps track of the conditions that may create a project change, manages change when these conditions occurs, and evaluates the benefits of change based on the effect to the triple constraints: scope, cost, time, risk, quality, and customer satisfaction. The outputs of the Integrated Change Process are approved and rejected change requests, Project Management Plan and Project Scope Statement updates, approved corrective actions, approved preventative actions, approved defect repair, validated defect repair, and deliverables.

Six Sigma: Operational Definitions

Once you decided to collect data and measure performance, remember precise definitions are needed for what you are measuring. Its just not a good place to be to have gone through the collection and measurement process, then come to the realization you are comparing apples to arm chairs. Clarification of what defects count in a process or service is important, but deciding what is meant by each term has the same level of importance.

An operational definition is a specific description of the defect, process, product and/or service to be measured. The operational definition is agreed to by all and an exact consistent definition. As with the every quality process, controls and cross-check are used to assure it is valid. These are four criteria used in validating an operational definition.

1. The requirement to be measured must be agreed upon - The requirement being measured is the process, product, or service the team wants to improve. A requirement might be to provide a constant system availability. All the words in the phrase should be clear and understandable.
2. The method of measurement must be agreed upon - The method used to measure the requirement is typically expressed quantitatively so it will not be misunderstood. To measure and assure system availability, the method might be to gather all times the system is unavailable.
3. There must be agreement on what the definition will not include - The team should exclude from its operational definition anything that prevents it from being used consistently. For example, the definition for system availability might exclude the nightly processing when the system is unavailable to its users. Agreeing on what will not be included in the measurement of an operational definition is nearly as important as agreeing on what will be included.
4. Customers must agree with the team that the operational definition is appropriate- The customers of the process, product, or service must agree with the team on the appropriateness of the definition. To the customers, system availability might only mean during working hours.

The truth of the matter is that clarification is important, and vetted clarification has even a stronger need. The operational definition that results from validating through the four criteria has significance and is measurable. After all you can’t manage if you don’t know what you are measuring.

Critical-to-Quality Tree

The Critical-to-Quality Tree or CTQ Tree is the six sigma tool for transforming customer requirements into measurable data. The CTQ Tree identifies and describes customer requirements in a specific measurable manner. Once specific Critical to Quality requirements have been obtained, products or service measurements can be compared to them quantitatively.

The advantages of using a CTQ Tree are:

• translating vague or broad customer needs into specific requirements
• helping Sigma teams move from general to detailed specifications
• ensuring that all aspects of the customer requirement are identified.

The steps to create and use a Critical-to-Quality Tree are:

1. Identify the key customer requirement - In step 1, the team identifies the key requirement the customers have for the product or service. This is done through open discussion. Usually, this requirement is expressed in the broadest possible terms, such as good customer service, to ensure the team does not miss anything.
2. Identify the customer's first tier of requirements - In step 2, the team identifies two or three requirements that resolve the key customer need identified in step 1. Good customer service might mean that the phones are answered quickly by knowledgeable staff.
3. Identify the customer's second tier of requirements - In step 3, the team identifies two or three requirements that further resolve each of the customer requirements identified in step 2. Phones answered quickly might be defined as within 2 rings. A knowledgable staff might related to staff being able to answer 90% of the calls before transferring to another individual.
4. Stop when quantifiable requirements are reached - Step 4 is applied when the team reaches a requirement that can be measured. The team would stop identifying requirements if the requirements are distinctly measurable.
5. Confirm your final requirements with your customers - Step 5 is applied after all the requirements on the CTQ Tree have been defined to a quantifiable degree. Each requirement should be confirmed with the customers.

The CTQ Tree is not the final step in a product or service improvement project. Instead, the tree serves as a good way to determine which improvements need to be made. In that light, the CTQ Tree is just the beginning. It yields a measurable base to compare the service or product to that standard, so a indication can be observed.

Affinity Diagram

The affinity diagram is a visual tool that is utilized to identify patterns and relationships in large amounts of information. It is especially useful when the purp