Techniques to Improve the Probability of Success in Information ...

Burgos APRJ-699 Applied Research Project

Techniques to Improve the Probability of Success in Information Technology Projects

Sheri Burgos

APRJ-699 Applied Research Project

Master of Business Administration Program

Center for Innovative Management

Athabasca University

Project Coach: Dale Bent

Date: March 29, 2010

Word Count: 15,510


Abstract

The IT industry is known for its challenges in achieving project success and this is

expected to continue as businesses experience accelerated and revolutionary change

driven by technological innovation, globalization of business and economic pressures.

Research on project success has found a major reason for failure was the executives

and project team�s failure to appreciate the level of uncertainty and complexity or failed

to communicate this to one another. Innovative thinking is required for an integrative

approach of best practice frameworks, principles and theories to understand how to

increase the ability for organizations to achieve IT project success.

The main research question for this Applied Project is �How can Information Technology

Projects be improved to increase the ability to deliver successful projects?� It includes a

literature review from secondary sources including two popular best practices

frameworks, PMBoK and ITIL.

This research paper evaluates, compares and synthesizes traditional and current best

practices and theories including PMBoK, ITIL Service Transition, Lean, Agile, Theory of

Constraints, Critical Chain Project Management, Organizational Change Management

and Complexity Theory. An evaluation of more traditional project management

approaches show the inadequacy when considering more current and innovative

methods and in the context of a business paradigm shift that we are now facing.

A Project Management methodology needs to be integrated into all areas of an

organization for maximum effectiveness. This includes organizational structure and

culture, portfolio management, resource management, and operations management.

The traditional success criteria of schedule, cost and scope is insufficient. Projects

should be viewed from a complete service lifecycle perspective with performance

measurements that measure projects based on business value. Two globally

recognized frameworks, PMBoK and ITIL, have different perspectives on change as


PMBoK looks at change from a project perspective and ITIL from a service lifecycle

perspective.

Organizational Change Management and the understanding of the psychology of

change is perhaps an area not understood or focused on enough in the context of

project delivery. The collaborative approaches used, people�s attitude and motivation

towards projects are powerful enablers to project success. Conversely, projects lacking

in group dynamics, leadership and people�s motivation can destroy a project.

ITIL�s Service Transition phase is evaluated from a change and release management

perspective as key processes of change in an organization. It is specific to managing

change in an IT environment where PMBoK is a general project management

framework.

The Theory of Constraints focuses on understanding the system as a whole, where the

constraints are and focusing on improving those. The psychology of humans is an

important consideration in achieving success. Schedule and Risk Management are

approached differently from traditional methods.

Critical Chain Project Management (CCPM) based on the Theory of Constraints has

had tremendous success in project delivery. It requires establishing the right

organizational structure and culture to support it. CCPM share common characteristics

with Agile such as collaboration, a focus to complete the project faster, accountability

with people performing the work and maximizing resource usage.

Agile and lean principles integrate very well with complexity theory in being more

adaptable to complexity and uncertainty. Agile and lean principles have not been

integrated with ITIL best practices and therefore this is an area for improvement in

meeting the complexities that businesses face.


Adaptive Project Management is an emerging model to deal with complexity by

providing iterative learning experiences. PMBoK uses a reductionist approach to

planning and control. Leaders in this field recognize a new paradigm is needed for

managing complex projects that require innovative thinking from traditional approaches.


Table of Contents

ABSTRACT........................................................................................................................................... 2

1. INTRODUCTION ............................................................................................................................ 7

2. RESEARCH PURPOSE AND QUESTIONS .................................................................................. 8

3. RESEARCH DESIGN...................................................................................................................... 9

4. STATEMENT OF RESULTS .......................................................................................................... 9

5. LITERATURE REVIEW AND ANALYSIS ................................................................................. 10

HOW DO THE INTERRELATIONSHIPS BETWEEN PMBOK AND ITIL SERVICE TRANSITION FRAMEWORKS

IMPACT PROJECT DELIVERY? ............................................................................................................. 10 Summary....................................................................................................................................... 15

WHAT AGILE AND LEAN PRINCIPLES CAN BE APPLIED TO PMBOK AND ITIL FRAMEWORKS TO

INCREASE THE EFFECTIVENESS OF PROJECT MANAGEMENT AND IT SERVICE MANAGEMENT IN

ORGANIZATIONS? .............................................................................................................................. 16 Summary....................................................................................................................................... 20

WHAT COLLABORATIVE APPROACHES WILL ENHANCE THE EFFECTIVENESS OF IT PROJECT DELIVERY

AND IT RELEASE AND CHANGE MANAGEMENT?................................................................................ 20 Summary....................................................................................................................................... 28

HOW DOES CRITICAL CHAIN PROJECT MANAGEMENT BASED ON THE THEORY OF CONSTRAINTS (TOC)

IMPROVE IT PROJECT SUCCESS?......................................................................................................... 29 Summary....................................................................................................................................... 36

WHAT IMPACTS DO ORGANIZATIONAL CHANGE MANAGEMENT AND PSYCHOLOGY OF CHANGE HAVE ON

DELIVERING SUCCESSFUL IT PROJECTS? ............................................................................................ 38 Summary....................................................................................................................................... 43

WHAT CONSIDERATIONS ARE THERE IN COMPLEXITY THEORY FOR IT PROJECT MANAGEMENT?......... 44 Summary....................................................................................................................................... 50

6. KEY RECOMMENDATIONS....................................................................................................... 50

7. SYNTHESIS AND CONCLUSIONS ............................................................................................. 51

ORGANIZATIONAL STRUCTURE.......................................................................................................... 52 ORGANIZATIONAL CULTURE.............................................................................................................. 53


ORGANIZATIONAL CHANGE............................................................................................................... 53 SCHEDULING ..................................................................................................................................... 53 RISK MANAGEMENT.......................................................................................................................... 54 HUMAN RESOURCES.......................................................................................................................... 55 PERFORMANCE MEASUREMENT......................................................................................................... 56 COLLABORATION .............................................................................................................................. 56 SERVICE LIFECYCLE .......................................................................................................................... 57 BUSINESS VALUE .............................................................................................................................. 57 AGILE................................................................................................................................................ 58

REFERENCES.................................................................................................................................... 59

9. APPENDIX A: AGILE MANIFESTO.......................................................................................... 63

10. APPENDIX B: COMPARISON OF CONVENTIONAL VERSUS ADAPTIVE PROJECT

MANAGEMENT................................................................................................................................. 65

11. APPENDIX C: LINKAGES AMONG FRAMEWORKS AND METHODOLOGIES ............. 66

12. APPENDIX D: COMPARISON OF A CONVENTION AND CCPM SCHEDULE................. 68

13. APPENDIX E: PEOPLE IMPROVEMENT PROCESS............................................................ 69

14. APPENDIX F: SPIDER CHART TO IDENTIFY PROJECT COMPLEXITY......................... 70


1. Introduction

The business world is experiencing accelerating and revolutionary change driven by

rapid technological innovation, globalization of business and global economic

pressures. This is putting pressure on IT organizations to be responsive and innovative

in delivering projects faster at lower costs with a greater dependency in supporting

business products and services. The IT industry is known for its challenges in achieving

project success. The Standish Group U.S. survey found that in 2006, only 35% of

projects were successful; delivering on time, on budget, and with full scope of features

and functions (Hass, 2009). Hass references a book where the authors collected data

for 15 years on more than 600 projects in business, government, and nonprofit sectors

in various countries. They found 85% of projects failed to meet time and budget goals,

with an average overrun of 70% in time and 60% in budget. The primary reason for

these failures was that executives and project teams failed to appreciate up front the

extent of uncertainty and complexity involved or failed to communicate this to one

another. They also failed to adapt their management style to the situation (Hass, 2009).

Project methodologies and frameworks require innovative thinking to support the

business challenges we are currently faced with. IT projects have unique requirements

and challenges.


Projects be improved to increase the ability to deliver successful projects?�

The theories, frameworks and best practices have had success in specific areas and

sectors. The purpose of this research is to identify the successful principles, theories,

frameworks and methodologies, evaluate the synergies among them to understand how

they can be integrated and applied together to increase the probability of IT project

success.

The management domain this research is based on is Project Management and

Operations Management. It is based on the Project Management Institute (PMI) project


management Book of Knowledge (PMBoK) and ITIL�s Service Transition phase specific

to Change and Release Management processes. ITIL is a set of IT Service

Management (ITSM) best practices that originated from the Office of Government

Commerce in the UK. These traditional frameworks will be compared with Agile and

Lean principles. Agile was conceived from the software development world in the early

nineties to improve on the waterfall approach. Lean was primarily used in the

manufacturing production space but has now evolved as a general process

management philosophy of creating more value with less. IT projects depend heavily

on IT operation functional groups; therefore the interdependencies will be included in

this research. Critical Chain Project Management focuses on scheduling and is based

on the theory of constraints, has a lot of success in organizations and therefore

important to evaluate from an ITSM perspective as well. Organizational structure,

culture and collaboration are critical success factors in project success; and therefore

are included in this report. Ultimately, people are what make projects successful so an

understanding of the psychology and motivation of people, culture and established

group norms is relevant in this research.

2. Research purpose and questions

The purpose of this research is to gain an understanding of how frameworks,

methodologies, principles and theories can be applied and integrated to achieve IT

project success. IT projects have unique challenges and the statistics on project

success indicate improvements are required. A comparison of different approaches,

where success has been achieved, and new theories are important research

components in understanding the critical success factors for project management.


Projects be improved to increase the ability to deliver successful projects?�

In support of the main research question, these supporting questions will also be

researched:


• How do the interrelationships between PMBoK and ITIL Service Transition

frameworks impact project delivery?

• What Agile and Lean principles can be applied to PMBoK and ITIL Frameworks

to increase the effectiveness of Project Management and IT Service

Management in organizations?

• What collaborative approaches will enhance the effectiveness of IT Project

Delivery and IT Release and Change Management?

• How does critical chain project management based on the Theory of Constraints

improve IT project success?

• What impacts do organizational change management and psychology of change

have on delivering successful IT projects?

• What considerations are there in complexity theory for IT project management?

3. Research Design

This applied project is a conceptual paper using secondary data sources. A

comprehensive literature review was conducted on IT project success using research in

the management areas of Project Management and Operations Management. The

scope of research includes specialized organizations such as PMI in the USA, the

Office of Government Commerce (OGC) in England, the Agile Alliance, books, AU

library databases, white papers and consulting organization websites. The keywords

used are ITIL, PMBoK, Agile, Lean, Theory of Constraints, Change Management,

Project Management, IT Service Management and Complexity Theory. The literature

review covers secondary sources created over the last 10 years.

4. Statement of Results

A comprehensive literature review was conducted using Secondary data sources. Two

best practice frameworks based on PMI�s PMBoK and OCG�s ITIL will be assessed.

Subject matter experts in the area of The Theory of Constraints and Complexity theory


are included. White papers from consulting websites and alliance member communities

are also a source of subject matter expertise. The research outcome is focused on

synthesizing the frameworks and methodologies to understand how to improve IT

project success.

5. Literature Review and Analysis

This literature review will draw on several disciplines: project management, IT service

management, lean and agile principles, theory of constraints and complexity science.

The objective is to provide context to the main research and sub research questions

and examine the underlying concepts and best practices. The analysis is integrated in

this section along with a summary of the question being addressed.

How do the interrelationships between PMBOK and ITIL Service Transition frameworks impact project delivery?

ITIL has five core areas that address an IT Service Lifecycle: Service Strategy, Service

Design, Service Transition, Service Operations and Continuous Service Improvement.

The focus of this research is on Service Transition within the area of Release and

Change Management. These are key processes where interdependencies between

Project and Service Management practices are closely integrated. Service Transition

provides guidelines for the development, improvement and transitioning of new and

changed services into operations. It encompasses the activities that are performed in

the project after the design to the operational touch points of moving it into production

(OGC, 2007).

The PMBoK framework is applicable to all types of projects with a focus on project

initiation, planning, execution and closure of the project. There are no PMBoK best

practices specific to release and change management for IT systems yet there are

many interrelationships with respect to IT projects. PMBoK scope focuses on all the

activities leading up to meeting deliverables. From an IT perspective, this typically

means delivering systems into production. Projects and operations differ primarily in


that operations are ongoing and repetitive, while projects are temporary and unique

(PMI, 2004). Ultimately, it�s the business value of the project deliverables that

determine the success of the project. In ITIL terms, value consists of two primary

elements: utility or fitness for purpose and warranty or fitness for use (OGC, 2007).

The warranty which is typically played out in production is a key component in

identifying the value of the service.

A Service Transition plan describes the tasks and activities required to deploy a release

into the test environments and into production, including:

• Work environment and infrastructure for the Service Transition;

• Schedule of milestones, handover and delivery dates;

• Activities and tasks to be performed;

• Staffing, resource requirements, budgets and timescales at each stage;

• Issues and risks to be managed;

• Lead times and contingency (OGC, 2007, p. 40).

This would appear to be very similar to the Project Management Plan although not as

comprehensive.

Release and change management are major processes within Service Transition.

The goals of Change Management are to:

• Respond to the customer�s changing business requirements while maximizing

value and reducing incidents, disruption and re-work.

• Respond to the business and IT requests for change that will align the services

with the business needs (OGC, 2007, p. 42).

The goal of Release and Deployment Management is to deploy releases into production

and establish effective use of the service in order to deliver value to the customer and

be able to hand over to service operations. (OGC, 2007, p. 84).

The human resource management plan identified in PMBoK implies that you know all of

your team members and can include them in project activities (PMI, 2004). This is


typically not the case when you have operational resources performing tasks and are

typically engaged through the change management system.

Table 1 shows the interrelationships between PMBOK and ITIL frameworks.

Table 1: Comparison of the ITIL and PMBOK framework

ITIL PMBOK Comments 3.2.5 Best practice: Adopt program and project management best practices to plan and manage the resources required to build, test and deploy a release into production successfully within the predicted cost, quality and time estimates.

1.3 Managing a project includes identifying requirements; establishing clear and achievable objectives; balancing the competing demands for quality, scope, time and cost; adapting the specifications, plans, and approach to the different concerns and expectations of the various stakeholders.

Both focus on managing resources for project delivery with consideration for cost, quality and schedule.

3.2.5 Principle: Set user expectations on how the performance and use of the service can be employed.

Communications Management: 10.4 Manage stakeholders: Managing communications to satisfy the requirements and resolve issues with stakeholders

Communications are important to both and emphasize the need to manage stakeholders.

3.2.5 Best practice: Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans.

4.3 The Project Management Plan process includes the definition, integration and coordination of all subsidiary plans in a project management plan.

ITIL states to incorporate the business projects to the service transition plans where PMBOK is specific to whatever is identified in the scope of the project.

3.2.6 Policy: Establish and maintain relationships with customers, customer representatives, users and suppliers throughout Service Transition in order to set their expectations about the new or changed service.

10.1 Communications Planning process determines the information and communication needs of the stakeholders.

Both identify stakeholder management with everyone involved in the changed service or project.

3.2.7 Best practice: Ensure roles and responsibilities are well defined, maintained and understood by those involved and mapped to any relevant processes.

9.1 Human Resource Planning - Identifying and documenting project roles, responsibilities, and reporting relationships, as well as creating the staffing management plan.

Both emphasize the importance of roles and responsibilities. ITIL extends the importance to those involved in relevant processes and not limited to the project.

3.2.10 Best practice: Use project management practices and the Change Management process to manage course corrections.

5.5 Scope Control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes.

Both have best practices in the area of scope management to manage change in the project.

3.2.14 Best practice: Perform an independent evaluation of the new or changed service to identify the risk profile and prioritize the risks that need to be mitigated prior to transition closure.

11.1 Risk Management Planning is the process of deciding how to approach and conduct the risk management activities to ensure the level, type, and visibility are commensurate with both the risk and importance of the project.

Both identify risk management as important to the project or change.


4.1.5.3 Planning and coordinating ST: A Service Transition plan describes the tasks and activities required to release and deploy a release into the test environments and into production, including: - Work environment and infrastructure for the ST - Schedule of milestones, handover and delivery dates - Activities and tasks to be performed - Staffing, resource requirements, budgets and timescales at each stage - Issues and risks to be managed - Lead times and contingency.

4.3 The Project Management Plan is a comprehensive plan that includes schedules, activities, issues, risks, staffing, budgeting, contingencies. The plan will vary depending on the complexity of the project. The plan defines how the project is executed, monitored, controlled and closed.

Both capture similar information. It appears that PMBOK defines the process and structure on how the project will be managed where ST does not indicate this. In PMBOK, Scope Management would identify what's included in a release. It doesn't go into the level of detail that ITIL does to identify best practices for creating releases.

4.2.1 ST depends on the Change Management process. The purpose is to ensure the following: - Standardize methods and procedures are used for efficient and prompt handling of all changes - All changes to service assets and configuration items are recorded in the Configuration Management System Overall business risk is optimized.

Glossary: The Configuration Management System is tool to identify and document the functional and physical characteristics of a product, result, service or component; control any changes to characteristics; record and report each change and its implementation status; and support the audit of the products, results, or components to verify conformance to requirements. It includes the documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes.

ITIL Change Management is a comprehensive process in identifying best practices for moving products and services into production. PMBOK does not go into this level of detail although it identifies that a tool is required to manage changes.

There are many similarities and overlapping processes. In comparing Release

Management, there are several similarities; however PMBOK does not go into the level

of detail required for planning IT service changes and grouping them into a release.

Planning the release would be identified in PMBOK�s scope management; however this

is from a project perspective and not a service perspective. Release Management may

be more akin to Program Management where it needs to evaluate and plan for multiple

services that are impacted by a change.

It�s evident that the two frameworks look at change management from different

perspectives. In PMBOK, change management is about managing project changes as

it relates to changes in scope. Configuration Management is most similar to ITIL�s

Change Management process. Both focus on the product or service and the impact

change is having on them. ITIL Change Management is about how to assess the

change and manage the risk associated with it. It�s integrated with Release

Management where an analogy would be Release as the conductor and Change as the


musicians making it happen at the right time. Change is also integrated with the

Configuration Management System. This tracks all configuration items or products and

services. Where PMBOK is primarily concerned with delivering the scope, ITIL�s

change management is concerned about the impacts the change will have in the

production environment.

ITIL Change Management is intimately related to Service Operations. Because it

focuses on operational impacts, it�s bound to a tactical time frame rather than a strategic

one. Most changes are scheduled a week to two weeks out. Large or complex

changes may be scheduled months in advance. Change Management is concerned

with gaining control over the IT environment. As such, requests for change are

scrutinized for impacts and risk to the production environment. Change Managers could

be considered change auditors or gatekeepers, ensuring change requests are to

standard and reviewed by appropriate stakeholders. The change process could take a

long time and not coincide with the project schedule depending on the complexity of the

change, the size of the organization and its Change Management process (Klosterboer,

2009). As a result of the focus of Change Management from an operations perspective,

many organizations do not have a rigorous change management process for service

planning or design as it does not have a tactical impact to production.

ITIL�s perspective is based on Service Management which is a set of specialized

organizational capabilities for providing value to customers in the form of services

(OGC, 2007). Project Management is the method for introducing new services and

managing those services throughout its lifecycle.

There is clearly a requirement for an integrated methodology that combines PMBOK

and ITIL frameworks within IT environments. The delineation between Project

Management processes and Release Management must be identified to understand the

overlap and the gaps the two frameworks together fill.


When considering a service in a service lifecycle context, service strategy is concerned

about the value delivered and used by the end user. From a customer�s perspective,

value consists of two primary elements: utility or fitness for purpose and warranty or

fitness for use. Utility is what the customer gets, and warranty is how it is delivered

(OGC, 2007).

IT projects typically end when the product or service moves into production. Once it�s in

production, operations take over and different processes are instituted. The objectives

of projects and operations are fundamentally different. The purpose of a project is to

attain its objective and terminate where ongoing operations is to sustain the business

(PMI, 2004).

Projects are typically not measured by customer value or the utility or warranty once it�s

in use. They are measured by cost, schedule and scope. PMBOK�s Scope

Management is concerned about utility and not so much about warranty once it�s in

production. ITIL�s Release Management is primarily concerned about utility and

Change Management is concerned about warranty. An integrated approach would

ensure that the change of services is managed in a holistic and controlled manner;

giving the value that customers expect and need. It would also allow for IT to manage

their assets more efficiently thereby enhancing their resources and capabilities for the

business and their customers.

Summary

ITIL and PMBoK frameworks both provide best practices for Change Management from

different perspectives; ITIL from changes being specific to the deliverables of products

and services for the organization and PMBoK from project scope changes.

The PMBoK framework offers best practices and general guidelines for a variety of

projects across all industries. It�s not prescriptive and left to the project manager or

organization to ensure that the correct methodologies are used in IT projects to increase

project success. The low project success rates as identified by the Standish study

could be attributed to the use of appropriate project methodologies based on the


PMBoK framework. The ITIL Service Transition framework is relatively new with the

publication released in 2007. Previously, ITIL started in the 1980�s and was based on a

series of processes rather than a Service Lifecycle. Although there are many

similarities between ITIL and PMBoK, ITIL Service Transition has a different perspective

in that, it looks at change from a service lifecycle perspective rather than project best

practices. To the author�s knowledge, there are no publications that integrate the two

frameworks for IT project delivery in the context of IT Change and Release

Management. Service Transition mentions Project Management at a superficial high

level; however clearly not with the intent of addressing in the framework or change and

release processes. It�s the author�s conclusion that in order to increase the likelihood of

project success; a methodology is required to integrate these two frameworks together.

This would consider the value that the customer gets from using the service and

establishing appropriate measurements based on both frameworks. Organizations

should also ensure the change management process starts from service strategy and

planning as the organizational impacts needs to be understood and planned by all

stakeholders at an early stage before it impacts production.

What Agile and Lean principles can be applied to PMBOK and ITIL

Frameworks to increase the effectiveness of Project Management and IT Service Management in organizations?

Lawrence Leach (2005) discusses the principles of lean production to include:

• Teamwork;

• Communication;

• Efficient use of resources and elimination of waste;

• Continuous improvement.

These principles were further expanded to emphasize the lean focus on waste:

• Specify value;

• Identify the value stream;

• Focus on flow of work;

• Implement customer pull;


• Strive for perfection.

Lean and agile principles have many commonalities between them where this list could

be applied to agile principles as well. Agile methods evolved in IT in the 1990�s as a

response to bureaucratic, slow processes that contradicted the ways software

development engineers worked. Software development methodologies evolved for

information technology projects to include such methods as

• Rapid application development;

• Joint application development;

• Extreme programming;

• SCRUM (Leach, 2005).

The traditional project management model focuses on locking the scope for a project

and negotiating or varying the budget (including people and resources) and the delivery

date. Leach observes that information technology organizations struggle with applying

conventional project management practices such as poorly defined initial scope and

using ineffective change management processes. The agile alternative is related to an

iterative rapid prototyping type approach that complements IT projects with the inability

to deal with requirements that cannot be explicitly defined at the outset. The rolling

wave planning approach is exemplified in Lean by eliminating the waste of planning that

will change as the project progresses. Change management is an essential part of

agile project management as scope creep is a major issue in IT projects with a focus is

to complete projects as soon as possible to reduce overall waste (Leach, 2005).

On empirical research into Scrum, it�s stated that Scrum is more a philosophy or set of

values that defines culture of empowerment and participation within the team and of

collaboration and transparency. The Project Manager role does not exist in Scrum. The

role is replaced by the ScrumMaster who is responsible for ensuring the values,

practices and rules are enacted and who lead by coaching, facilitating, teaching and

supporting the team rather than command and control. Many of the practices in agile

methods are mechanisms for managing risk effectively. Requirements changes are

intrinsically addressed in agile methods through short iterations. Cross-functional


teams, a focus on the customer and concurrent engineering are a source of competitive

advantage in agile methods. Agile methods are designed for highly dynamic

environments and are well adapted for cultures with many degrees of freedom.

Appendix A identifies the Agile Manifesto which is gaining a broader following not only

in IT but other functional areas as the principles can be applied across many sectors.

Lean evolved out of a manufacturing process popularized by Toyota�s Production

System (TPS). The key Lean concept means moving towards the elimination of all

waste in order to develop an operation that is faster, more dependable, produces

higher-quality products and services and, above all, operates at low cost (Slack, N., et

al., 2007). Lean plays a key role in IT project delivery by lowering costs, efficiency in

processes, improving quality, predictability in moving systems into production and

continuous improvement.

Figure 1 depicts the main focus of PMBOK, ITIL and Agile as it relates to a Project

Management System.

Agile: Iterative processes

Focus Collaboration

Business inclusion Speed of delivery

PMBOK: System definition Knowledge areas

Framework Processes

ITIL: Service Lifecycle Service Transition

Release Management Change Management

Project Management

System:


Figure 1: Project Management System based on PMBoK, ITIL and Agile.

Agile complements Release Management very well as release management provides

the framework for identified iterations or releases to be deployed. The development

team and business would identify what needs to be included in a release. Release and

Deployment Management aims to build, test and deliver the capability to provide the

services specified by Service Design and that will accomplish the stakeholders�

requirements and deliver the intended objectives (OGC, 2007). It�s not specific as what

should be included in a release.

There are two primary PMLC models in Agile: Iterative and Adaptive. Iterative PMLC

models are appropriate for projects where most of the solution has been discovered.

Adaptive PMLC models are appropriate for projects where very little of the solution is

known. Understanding and integrating major functions into the solution are integral to

the learning and discovery part of Adaptive PMLC models. Where most agile models

have been geared towards software development projects, the Adaptive Project

Framework (APF) is also for non-software development projects. It is based on an

adaptive PMLC model that consists of a number of phases that are repeated in cycles,

with a feedback loop after each cycle is completed. It�s meant for solutions where

uncertainty and complexity are present. It�s a discovery and learning paradigm through

a continuous change process from cycle to cycle. The scope phase is high level as not

much is known about the solution. The cycle is timeboxed in 2-4 weeks and gates

ensure what is learned and developed is reviewed and approved (Wysocki, 2009). This

is more effective than a linear model in terms of cost, schedule and deliverables.

Project resources are not spent in the planning phase in trying to solution a deliverable

that lacks requirements or will change afterwards, and resources are not wasted in

change management activities.

PMBoK uses progression elaboration as means of developing in steps, and continuing

by increments. The project scope may be broadly defined and become more detailed


as the project progresses. This allows for processes to be iterative throughout the

project�s lifecycle (PMI, 2004).

Lean and ITIL share a common goal to improve the processes involved in developing

and providing IT services within an organization. The future of effective IT management

lies in a deliberate combination of process refinement approaches that unites the

strengths of Lean and ITIL. This Lean IT Service Management (Lean ITSM) represents

an important step toward the future of IT services. Together, they improve and

streamline processes and reduce costs associated with the IT function. A distinctive

characteristic of this approach is accomplished by a rapid improvement team made of

people who actually do the work. It�s a continuous process improvement model where

people are empowered to improve their work (White & Chaiken, 2008).

Summary

There are differences in Agile and Lean principles when compared to how organizations

use PMBoK as a basis for their project methodologies. PMBoK is traditionally used in

linear, command and control type methodologies. Although progressive elaboration and

rolling wave planning is included in PMBoK, many organizations do not practice this.

Agile and Lean principles are complementary to PMBoK and ITIL given they are

frameworks and the methodologies developed are unique to the project or

organization�s requirements. Appendix C shows the linkages among the frameworks

and methodologies.

What collaborative approaches will enhance the effectiveness of IT Project

Delivery and IT Release and Change Management? An organization should understand their underlying values and drivers that enable

effective management of change. Each organization will have a different approach to

change, in part, by the culture of the organization. Organizational culture is the


combination of ideas, corporate values, beliefs, practices, and expectations about

behaviours and customers. It could support change or be a source of resistance to it.

Interfaces to projects and operations should be clearly defined. Project Management

should have clear interactions and understanding of the service management lifecycle

including service design, transition and operations requirements. Project and

operations teams often work in isolation believing the other area is not in their scope.

This is short sighted approach and one that should be considered in methodology

development (OGC, 2007).

It�s important to understand that underlying policies and processes that support change

management when considering how collaboration fits in. Change management policies

include:

• Creating a culture of Change Management across the organization where there

is zero tolerance for unauthorized change;

• Aligning the service Change Management process with business, project and

stakeholder Change Management processes;

• Prioritization of change, e.g. innovation vs preventive vs detective vs corrective

change;

• Establishing accountability and responsibilities for changes through the service

lifecycle;

• Segregation of duty controls primarily for the prevention of fraud and errors;

• Establishing a single focal point for changes in order to minimize the probability

of conflicting changes and potential disruption to the production environment;

• Change windows � enforcement (OGC, 2007).

In assessing requests for change (RFC) and depending on the type of change, there

are typically a number of groups involved in the assessment including change

management, corporate advisory board (CAB), executive corporate advisory board

(ECAB) and other involved in the change. Relevant items they would be assessing may

include:


• The impact that the change will make on the customer�s business operation;

• The effect on the infrastructure and customer service, as defined in the service

requirements baselines, service model, SLA, and on the capacity and

performance, reliability and resilience, contingency plans, and security;

• The impact on other services that run on the same infrastructure;

• The impact on non IT infrastructures within the organization;

• The IT, business and other resources required to implement the change,

covering the likely costs, the number and availability of people required, the

elapsed time, and any new infrastructure elements required;

• The current change schedule and projected service outage;

• Additional ongoing resources required if the change is implemented;

• Impact on the continuity plan, capacity plan, security plan, regression test scripts

and data and test environment, Service Operations practices (OGC, 2007).

In large organizations where there are many stakeholders, they are evaluating changes

from different perspectives than the project team. This may impact the project with

scheduling delays, increased scope or additional costs. As such, this presents a risk to

the project.

Changes are assessed from a risk perspective and the impact the change will have

from an organizational perspective. Requests for change could be anything from

Service Portfolios to Services to project to user access to operational. It includes the

full spectrum of a service lifecycle.

Table 2 shows a change impact/risk categorization matrix that is typical in assessing

changes.


Table 2: Example of a change impact and risk categorization matrix

Change impact/risk categorization matrix

High impact High impact Low probability High probability Risk category: 2 Risk category: 1 Low impact Low impact Low probability High probability Risk category: 4 Risk category: 3

Change impact

Probability

(OGC, 2007)

All members of the change authority should evaluate the change based on impact,

urgency, risks, benefits and costs.

Many groups throughout the organization are involved in change management;

assessing and approving changes. A collaborative approach would be beneficial to this

process. Tools also play a key role in how collaborative change management

processes are within an organization.

The Change Advisory Board (CAB) is a body that exists to support the authorization of

changes and to assist Change Management in the assessment and prioritization of

changes. It includes people with a clear understanding across a whole range of

stakeholders. They require a collaborative approach to discuss and understand the

nature of the changes. Many organizations run these meetings via teleconference

rather than face to face. In larger organizations, this can be a long and large meeting

as the high volume of changes is discussed. CAB meetings represent potentially a

large overhead on the time of members; therefore it�s recommended to have RFC�s

distributed in advance and the ability to review and comment. RFC�s are requests for

change that identify the details of the change and its associated attributes. Practical

experience shows that regular meetings combined with electronic automation are a


viable approach. The meeting can be used to provide formal review and signoff of

authorized changes, review outstanding changes and impending major changes (OGC,

2007).

Change and release management should not only be integrated with processes used

for programs and projects but also integrated with suppliers� processes and procedures.

Outsourcing adds a level of complexity as changes may impact both organizations and

collaborative processes are essential for effective change management (OGC, 2007).

Electronic collaboration (e-collaboration) is defined as using electronic technologies

among different individuals to accomplish a common task (Kock, 2008). The

importance of e-collaboration with more recent technologies such as web 2.0 should be

understood to create efficient and lean processes in using ITIL.

The ITIL framework is �process heavy� with nearly 30 defined processes and functions

in version 3. It�s imperative that organizations apply them in such a way as to maximize

their benefit on the services delivered. Version 3 is less infrastructure-oriented and

takes a wider view across IT and the business it supports. ITIL V3 is more challenging

since a greater level of acceptance to work at that wide level is needed. Managing the

services requires application developers, infrastructure operations, and IT architects to

work together to support the business in a more cohesive fashion than has been typical

in the past. In conjunction with the business, this brings true business service

management (Orr, et. al., 2008).

In ITIL version 2, it was process centric rather than service lifecycle centric. Because of

the costs and impact of these processes to organizations, they are often implemented

one at a time. They are often autonomous processes and not integrated into external

organizational processes such as project management. Integrated processes consider

the collaboration and communication requirements across the various functional areas

and business processes. Although ITIL version 2 recommended the integration of

processes, in practice this has been difficult to achieve.


ITIL (OGC, 2007) states that Collaboration is the process of sharing tacit knowledge

and working together to accomplish stated goals and objectives. The following is a list

of knowledge services widely available today, which, when properly implemented, can

significantly improve the productivity of people by streamlining and improving the way

they collaborate:

• Shared calendars and tasks

• Threaded discussions

• Instant messaging

• White-boarding

• Video or teleconferencing

• E-mail

Communities are becoming the method of choice for groups of people spread across

time zones and countries to communicate, collaborate and share knowledge. These

communities are typically facilitated through an online medium such as an intranet or

extranet and often acts as the integration point for all knowledge services provided to its

members. Well-run communities will have a leader to manage and run the community

and a group of subject matter experts to contribute and evaluate knowledge assets.

Examples of services and functions provided within the online community are:

• Community Portals

• E-mail alias management

• Focus groups

• Intellectual property, best practice, work examples and template repository

• Online events and net shows.

Successful communities often implement a reward and recognition program for their

members to acknowledge and reward the contribution of valuable knowledge assets.

This is a highly effective way to encourage members to share their knowledge and

move past the old paradigm that knowledge is power and job security and therefore

needs to be hoarded. Senior management should actively participate in these


communities to foster a culture and environment that rewards knowledge sharing and

collaboration (OGC, 2007, p. 194).

Klosterboer states one of the greatest benefits of a full implementation of change and

release management is how it improves communications and collaboration among IT

professionals as it provides more consistent planning between groups. For example,

the release management process has determined that the next release of the marketing

promotions application will be available in the third quarter of next year. The server

administrators can determine when they�ll need more capacity to respond to new

promotions that are made possible by the new application. The network team can gear

up to provide the necessary bandwidth. The application support team can schedule their

vacations earlier in the year to be on hand to support the new application. This kind of

collaboration simply isn�t possible without the foresight provided by active release

management plans (Klosterboer, 2009).

Release planning no doubt improves long-range goal planning, but ITIL change and

release management helps daily communications as well. The main purpose of change

management is to facilitate communications before changes adversely impact the

environment. The change requester needs to work with the team implementing the

change to agree on the details of what needs to be accomplished. The change

approvers need to communicate with the technical team to be sure they really

understand the technical and business impacts of a change. When change

management is implemented and working well, the volume and quality of

communications increase dramatically. This communication may initially be seen as

bureaucratic, but it is really a significant business advantage (Klosterboer, 2009).

Manyika, Sprague and Yee reinforce the increasing importance of collaboration as they

estimate by 2011, 47% of the U.S. workforce will be collaboration type workers. This is

defined as requiring interpersonal exchanges involving complex problem solving and/or

tacit knowledge, experience, or context. Improving collaboration is dependant on

selecting the right technology to support their interactions. Technology solutions may


vary substantially as it depends on the number of individuals, which way information is

flowing, and whether the interactions cross functional or corporate borders (Manyika, et.

al, 2009)

Agile supports collaborative approaches as the principles dictate business and technical

people working closely together on a regular basis (Beck, K, et. al, 2001). Agile Scrum

methodology bring cross functional groups together with an emphasis on physical

proximity and having daily meetings to facilitate rapid communication.

Sarker, Munson, Sarker and Chatraborty look at collaborative challenges by assessing

the relative contribution of the facets of agility to distributed systems development

success. Distributed Software Development projects are where two or more subteams

are working together to accomplish project goals from dispersed geographical locations.

There are varying definitions on agility from ranging from the sense and response to

change capabilities to the use of different lightweight methodologies and practices.

They stress the importance of not only measuring the technical aspects of project such

as cost and time but the people aspects such as user satisfaction and project

stakeholder satisfaction. Projects suffer from several challenges such as time and

culture differences, distance between team members, and reliance on computer

mediated communication technologies for communication, coordination and knowledge

sharing problems. Success should be assessed on how the project teams were able to

rise above the challenges and experience successful collaboration. (Sarker, et. al.,

2009).

Group dynamics and teams play an important role in IT project success. Lencioni

addresses this from looking at the negative or dysfunctional perspective and how to

address it. The five dysfunctions that can negatively impact a project are as follows:

1. Absence of trust. This occurs when team members are reluctant to be vulnerable

with one another and admit their mistakes, weaknesses, or need for help.

Without a certain comfort level among team members, a foundation of trust is

impossible.


2. Fear of conflict. Teams that lack trust won't engage in unfiltered, passionate

debate about key issues, causing situations where team conflict can easily turn

into veiled discussions and back-channel comments. Where team members do

not openly air their opinions, inferior decisions result.

3. Lack of commitment. Without conflict, it is difficult for team members to commit to

decisions, creating an environment where ambiguity prevails. Lack of direction

and commitment can make people disgruntled.

4. Avoidance of accountability. When teams don't commit to a clear plan of action,

even the most engaged individuals hesitate to call their peers on

counterproductive actions and behaviours.

5. Inattention to results. Team members tend to put their own needs (ego, career,

recognition) ahead of the goals of the team when individuals aren't held

accountable. If a team has lost sight of the need for achievement, the business

suffers.

A functional and cohesive team is very powerful in projects with higher quality decisions,

accomplishing more in less time with less distraction and frustration (Lencioni, 2008).

Summary

Organizations need to understand their culture in order to effectively manage change.

The interrelationships and interfaces between Project Management and Service

Management should be clearly defined and communicated throughout the organization

to ensure the effective delivery of services. Change Management is a highly

collaborative process of interactions from multiple groups within an organization

including its external partners. E-collaboration methods with a focus on web 2.0

technologies should be considered for effective use of tools and methods. With the

release of ITIL version 3, collaboration is even more important as groups across the

organization are involved in the Service Lifecycle. OGC discuss the types of

collaboration that can be used in sharing information and the use of communities.

Klosterboer emphasizes the value of collaboration in bringing together multiple groups

for release planning and daily communications. As we move to a more collaborative

work style, Manyika emphasizes the importance of using the right tools. Agile principles


are based on collaborative work styles where team member work closely together and

there is transparency in their communications. Sarker research suggests that

collaboration should be a key measure of project success as it tends to have significant

challenges in achieving project success. The value of effective collaboration can�t be

underestimated and should be considered as a critical success factor in project

success. Group dynamics in teams can be very powerful. The dysfunctions in teams

can lead to project failure while highly cohesive and functional team can be very

effective in project delivery.

How does critical chain project management based on the Theory of

Constraints (TOC) improve IT project success?

The successful implementation of Critical Chain has resulted in major improvements in

organizations. Kerzner has identified that executives often describe three major

challenges in project management:

• Choosing the right projects from among a large pool; • Getting each project to completion more quickly; • Funnelling more projects through the organization without adding resources.

Critical chain is a project management methodology designed to address the latter two

goals. Critical Chain is based upon a general improvement methodology called the

Theory of Constraints, which addresses the first executive goal of choosing the right

projects (Kerzner, 2006).

Critical Chain implements major behavioural changes in project managers, resource

managers, team members and executives. People accept fundamental changes

through deep understanding of the current behaviours, the new behaviours required,

and the benefits. These changes include:

• An end to the practice of measuring people on the accuracy of their estimates

and meeting due dates for individual project tasks; replaced with �the relay

runner work ethic;�;


• A system allows all new projects to start only when strategic resources are

available with the significant reduction of the practice of multitasking by moving

toward dedicated work on project tasks;

• The implementation of multiproject software with the data actually being used by

executives, resource managers, and project managers;

• The implementation of buffer management as a key management and executive

process for identifying task time variations and project problems during execution

(Kerzner, 2006).

Leach outlines the benefits of using critical chain over critical path theory with

improvements of 50%. The benefits he identifies are as follows:

• Improved project success:

o Project are completed on time, under budget, deliver full scope and

improve market position and business growth;

• Reduced project duration:

o Projects complete in one half the time (or less) of previous similar projects;

• Increased project team satisfaction:

o There is reduced confusion from multitasking, more focus, reduced

rework, improved project measurements;

• Simplified project management:

o Clear focus with simplified project plans and improved measurements;

• Increased project throughput with same resource:

o Resource-demand conflicts are reduced, ability to complete projects

faster, improve cash flow and return on investment (Leach, 2005).

W. Edwards Deming maintained that real quality improvement wasn�t possible without

profound knowledge. This coming from :

• An understanding of the theory of knowledge

• Knowledge of variation

• An understanding of psychology

• Appreciation of systems (Dettmer, 2007).


The Logical Thinking Process Goldratt developed to apply TOC provides a solid

foundation of understanding the theory of knowledge. Goldratt�s Theory of Constraints

is about change; applying principles and tools to answer four basic questions:

• What�s the desired standard or performance?

• What must be changed? (Where is the constraint?)

• What is the appropriate change? (What should we do with the constraint?)

• How is the change best accomplished? (How do we implement the change?)

(Dettmer, 2007).

Goldratt developed five sequential steps to concentrate improvement efforts on the

component that is capable of producing the most positive impact on the system.

1. Identify the system constraint

a. Identify the weakest link

2. Decide how to exploit the constraint

a. How can we get more capabilities out of the component?

3. Subordinate everything else

a. Adjust the system to enable maximum effectiveness of the constraint

4. Elevate the constraint

a. Take action to eliminate the constraint

5. Go back to step 1, beware of inertia

a. Look for the next constraint (Dettmer, 2007).

Many organizations share resources across multiple projects. The practice of

multitasking is a common occurrence as the demands of new projects are in continuous

cycle throughout the organization. Typically organizations do not formally measure the

load on the various resources coming from the combination of projects. While some

project plans show resource loading, enterprise resource planning is not performed.

Prioritization of projects across the enterprise is typically not performed as silos

compete for resources to meet their own objectives. A simple solution is to schedule

multiple projects according to one resource; the most heavily loaded resource across all


projects. This resource is called the �drum�. The capacity of the organization�s critical

resource sets the pace of all projects. The following lists how critical chain adds value

to projects:

1. Team members dedicate themselves to a project task with estimates based on

effort rather than duration mixed with multitasking.

2. Bad multitasking is significantly reduced and tasks are completed before starting

new ones.

3. People are measured on the relay runner ethic or how quickly they pass their

outputs to the next resource and not completing their task on time.

4. By reviewing resource dependency and logical task dependency, the longest

sequence of dependant tasks is clearer.

5. Buffers strategically placed in the schedule allow for common cause variations

and the ability to increase the certainty of project completion dates.

6. Critical path used in PMBoK uses slack time or float to determine flexibility in

schedule. Critical chain groups tasks on each noncritical path and protects the

critical chain with a feeding buffer.

7. The buffering allows for noncritical tasks to be scheduled at their latest start time

to discourage costly early investment of work.

8. The critical path in PMBoK changes during execution because there is no buffer

to absorb the variation in task times.

9. Critical chain recognizes that there are multiproject environments where projects

have resource based interdependencies.

10. The critical chain approach identified the critical resource called a drum resource

across a collection of projects. This identifies the impact on cycle time of

projects.

11. The staggered introduction of projects into the system is used to improve the flow

of projects, increase the predictability in each project outcome, and to increase

the effectiveness of critical resources (Kerzner, 2006).

Leach indicates there are several perspectives on issues of undefined requirements and

agile approaches. Standards such as PMBoK are not intended to be followed


prescriptively in their entirety for all projects in all organizations. Frameworks are meant

to choose from and adapt to specific organizational needs. Although there is a natural

tendency to apply such standards prescriptively and get bogged down in detail, that is

not a fault in the standard; it is a problem with the application of the standard (Leach,

2005).

Variation and uncertainty are used interchangeably. Leach uses variation as relating to

getting different outputs from repeated application of the same process and uncertainty

as relating to our knowledge about the result, as a measure of the predictability of the

variation. Deming emphasized the importance of distinguishing between common-

cause variation and special-cause variation. This is necessary in order to get a system

under statistical control and predict its performance. Common-cause variation is

variation within the capability of a system to repeatedly produce results. Special-cause

variation extends beyond that range, usually due to causes outside the system.

Estimates of tasks in a project plan are uncertain and therefore impossible to predict the

outcome with accuracy better than the common cause variation of the system.

Statistical techniques enable us to predict with known precision the likely results and to

separate out the special causes of variation requiring corrective action. While

knowledge of variation has been used to great profit in production operations, it has not

been used to improve project performance. PMBoK fails to differentiate between

common-cause variation and special-cause variation and is a major oversight in the

current theory (Leach, 2005).

PMBoK does not deal directly with psychology as a knowledge area. The project

system must integrate with the human subsystem through the psychology of individuals

and groups (Leach, 2005). The notion of culture and organizational behaviour as it

relates to group dynamics is a behavioural factor related to project outcomes.

Padding or safety time in project estimates typically contain a large amount when

compared to the median completion time. The problem is the use of padding to


individual tasks to stay on schedule typically doesn�t work. Goldratt argues that this

contingency padding induces three behaviours that waste most of the safety time:

1. The student syndrome (leaving things to the last minute).

2. Multitasking (chopping and changing between different jobs).

3. Delays accumulate; advances do not (Pinto, Cleland, Slevin, 2003).

Parkinson�s Law is universally regarded as truism where the work will automatically

expand to fill the time available (Whittaker, 2010). This needs to be considered when

adding safety time to estimates. Appendix D gives a comparison of how padding or

buffers are used in traditional project management and critical chain project

management. In CCPM, buffers are not added to individual tasks but placed at the end

of the project.

The key focus areas and benefits CCPM offers as a methodology are as follows:

• Accounts for duration uncertainty by making buffers explicit, sharing the

knowledge of buffer sizes and placement with workers, managers and sponsors;

• Considers resource availability;

• Focuses on key tasks and resources;

• Constantly monitors the amount of buffer in your schedule;

• Provides advance notice of upcoming work to critical resources;

• Does not split your attention across numerous tasks (Raz, Barnes, Dvir, 2003).

CCPM focuses on a single aspect of project management of meeting the schedule

goals. It focuses on uncertainty inherent in the schedule rather than addressing the root

cause by using buffer management. In contrast, PMBoK addresses risk management

by identifying and reducing the sources of uncertainty or estimating methodologies that

improve the quality of duration estimates. CCPM is a departure from traditional project

management and requires a cultural change within the organization (Raz, Barnes, Dvir,

2003).


Agile also ensures the team is focusing on one project or a specific group of tasks at

one time. They are involved in the estimation process and the team determines their

velocity or capacity of work that they can take on. The team works closely with the

business designate to ensure they are working on priority activities. Both have a high

satisfaction and performance level of the team. For the Scrum methodology, daily

scrums are the norm where the scrummaster tracks the schedule and burn down of the

activities. For CCPM, buffer management is the primary method of managing the

schedule.

Kerzner identifies the Lucent case study and their experience implementing critical

chain. Lucent is a $33 billion manufacturer and service provider in the communications

industry and Optical Fiber Solutions group was the first to employ critical chain. In order

to implement critical chain successfully, it was 99% culture and 1% theory. Buffer

management and the understanding of it was a critical success factor. Initially, their

drum revolved around an incoming material used in development projects. They found

they were still experiencing logjams and changed their drum to later in the development

process. After two years of implementation, the following results were achieved:

• In the Premise Cable Products group, 100% of the sixteen projects scheduled

using critical chain were completed on time. Cycle times were reduced by 50%

in the first year.

• Outside Plant Cable Products group development capacity tripled with no

increase in staffing. Cycle times were also reduced by 50%.

• Over the two year period, over 95% of all projects were delivered on time

(Kerzner, 2003).

The Service Pipeline is introduced in Service Strategy as a method of tracking services

phased into operation by Service Transition after completion of design, development,

and testing. It�s a database or structured document listing all IT Services under

consideration or development. It provides a business view of possible IT Services and

is part of the Service Portfolio not normally published to customers (OGC, 2007). It

does not identify how to manage the pipeline holistically from a scheduling perspective.


Change and Release Management play an important part in scheduling and delivery of

projects. Change Management is concerned about the capacity of functional areas of

the change and impact of multiple changes occurring in the same timeframe. It also

considers the impact to the business. There are external considerations when creating

a schedule for a task that�s impacting production or goes through the change

management process. In large organizations, many groups can be involved and

several changes are in scope for review.

The Service Transition strategy defines the approach and considers the scope, how

often releases are implemented, and change windows. Requests for change (RFC)

identify the requested implementation date and it�s typically the change manager role

that evaluates changes on a holistic level. Careful attention is required to the durations

of the various types of changes as changes and releases are typically reviewed by

many stakeholders and are in queues throughout the process. Stakeholders in change

management roles view changes from an operational and process perspective rather

than meeting project timelines. It�s up to the project manager to manage the project

schedule and work with change and release management to ensure activities are

moved through the process according to schedule. Change and release management

can be complex processes in organizations where many stakeholders are involved and

vary depending on the change. Project managers often spend time following up with

reviewers to assess or approve tasks in an RFC. Organizations vary on their policies

on who reviews and approves RFCs. The time to go through this process not only

increases the project schedule but costs as well. Project schedules can be at risk when

the estimates for change and release management are not clearly understood.

Summary

The theory of constraints focuses on the weakest link in a system, improving it and

scheduling tasks according to its capabilities. It�s based on Deming�s quality

improvement principles of understanding the system as a whole, understanding

variation and the psychology of humans. Human performance is improved as people


are able to focus on their tasks; they are measured fairly and given lead time of

upcoming tasks. It also considers the negative outcomes in scheduling such as student

syndrome or procrastination and Parkinson�s Law. Common-cause and special-cause

variation should be planned for separately as statistical analysis can be applied to

common-cause and is taking into consideration when estimating and buffer

management. Special-cause variation requires risk management approaches to

manage the project effectively.

Critical Chain Project Management has empirical evidence for delivering successful

projects when compared to traditional critical path project methodologies. Critical Chain

focuses on behavioural change and people benefits that motivate and allow people to

perform at greater levels than traditional methods. This is very much in line with Agile�s

philosophical concepts of self organization that enhances group motivation and

collective buy-in to project objectives. Leach and Kerzner articulate the simplification of

project plans and measurements that impact the speed of delivery and reduced cost of

projects.

Agile and CCPM require significant shifts in the culture of organizations. It requires a

prioritization method of projects across the organization where the utilization of common

resources is required. It focuses on one project or work package at a time to minimize

multitasking and enables an understanding of the real effort required in completing

tasks. The schedule for both Agile and CCPM are constantly monitored and action

taken as required.

Change and release management has a major impact on the project schedule. It�s not

managed holistically from a project portfolio perspective as the scope is often specific to

the project or a change. Change and release management can be complex processes

in organizations and not understood by project managers. As such, project schedules

are at risk as time allocations and queuing involving multiple stakeholders to move

systems into production may take longer than expected.


What impacts do organizational change management and psychology of change have on delivering successful IT projects?

Bill Dettmer in his Logical Thinking Process (Dettmer, 2007), which is about facilitating

change, suggests the psychology of change goes far beyond logic. Some estimates of

failures run as high as 80% of major systemic changes as theories and frameworks fail

to address the psychology of change. He discusses the difference between

management and leadership where it could be defined as �You lead people; you

manage things.� Leadership has been defined as �the ability of an individual to

influence, motivate, and enable others to contribute toward the effectiveness and

success of the organizations of which they are members.� Real leadership requires you

to be emotionally bonded, attached, connected, or linked with those whom you lead and

that followers are similarly bonded with one another. He compares leadership with the

infamous blitzkrieg of World War II. The rapid manoeuvre warfare using small, fast

moving units was a big element of surprise to their opponents and the well coordinated

actions of autonomous units were a great contributor to its success. The four basic

principles learned that could be applied to any leadership in organizations are mutual

trust, personal professional skill, integrity, and focus (Dettmer, 2007).

Trust refers to certain knowledge of what to expect from one another that develops after

working together. It�s earned over time through two way communication. Trust is

challenging in the corporate world as many structures and policies do not reinforce

developing trust with colleagues. This can be found in the competitive nature of

�climbing the corporate ladder�, individual performance measurements, geographical

dispersion and lack of social contact with team members.

Professional skills in IT are becoming ever more challenging as systems become more

complex with the rapid technological change. The rate of technological change is

increasing and may surpass what Moore�s Law states where transistors on a chip will

double every two years (http://www.intel.com/technology/mooreslaw/). This is indicative

of the future change velocity with information technology. In large and complex IT

projects, it�s highly unlikely that any given individual would understand the system from


end to end. This will reinforce collaboration as a critical success factor as systems are

developed with the integration of the various components fitting together as one

cohesive system. For larger organizations, this will require close working relationships

from many groups across functional areas and external partners.

Integrity relates to the accountability of an individual and trust to get their activity done.

Accountability and trust are often hidden behind processes in organizations and the

process dictates the level efficiency or lack of in completing tasks. Project activities that

are hidden or behind processes in functional areas pose a risk to the project if the

accountability is not there to complete the required deliverable in the expected

timeframe. Operational activities are often not bound to the project delivery dates.

Many organizations do not have operational level agreements that indicate the timelines

that they can get the work done. If the queue is long for an operational functional area,

this will impact project timelines as duration and effort need to be considered.

Focus is more and more difficult in organizations as people are required to multitask

across many projects. The demands on IT and velocity of change make it difficult for

individuals to focus on their tasks for the required length of time. Personal

characteristics vary as to how well individuals can multitask. Some people are much

more effective in focusing on one task as a time while others find it easy to multitask.

For the people that require more focus, multitasking can be very frustrating for them.

In some cases, Project Managers are not in positions of authority so they need to

depend more on their leadership ability to lead human resources in a cohesive and

progressive fashion. Although traditional project management job descriptions often

request leadership skills, the organizational and project structure is not conducive to this

requirement; for example, accountability without authority. In the case of Agile, the

project manager, identified as a ScrumMaster, must have facilitative and leadership

capabilities as a key success factor. Matrix organizational structures are common in

larger organizations where project managers draw on resources across functional

groups throughout the organization. They typically deal and negotiate with functional


managers for resources. This could lead to conflicting priorities as individuals balance

work between projects and their manager�s directives. Project manager influence is

very important not just for working with the individual performing the task but with the

functional manager as well.

Unlike leaders, subordinates are less likely to be operating at Maslow�s level 5. It�s

more likely that they�re at level 3 (social, affiliation needs) and reaching for level 4

(esteem). In the uncertain world of globalization and outsourcing, a great many

subordinates have been forced down into concern about level 2 (security) (Dettmer,

2007).

In most organizations, behaviour is directed by the �carrot or stick� approach. In

psychology circles, it�s referred to as reinforcement theory. Reinforcement theory

suggests that some policy directive prompts some kind of behaviour. The behaviour

produces some outcome for the one doing the behaviour. The degree to which that

consequence is pleasing or displeasing to the person behaving determines the

reinforcement or repetition effectiveness of that behaviour. Reinforcement can be either

positive or negative. The problem lies in organizations being good at negative

consequences and fail to understand that positive reinforcement is more effective.

Behaviour is a function of its consequences (Dettmer, 2007).

In Appendix E, Dettmer identifies through the thinking process, a system improvement

cause and effect with mutually dependent factors including effective methods, the

potential to apply them, and the self-discipline to act using the methods. The potential

and self-discipline factors depend on the following:

• The state of our knowledge about our system

• Authority (including resources) to do something about it

• Motivation to improve

• Willingness to accept accountability for action (Dettmer, 2007).


Successful system improvement positively reinforces both system knowledge

(technical) and motivation (psychological). The latter requires an added leadership

injection to effect the reinforcement. Any absence of one of the five contributors

(method, content knowledge, potential, authority, self-discipline, accountability,

motivation) can reduce the potential of system improvement. Motivation is an internal

personal characteristic where the individual must want to improve. To maximize the

benefit to the system, the right combination of organizational framework including

processes and access to information, along with an individual�s level of motivation and

accountability are key to system improvement (Dettmer, 2007).

Dettmer synthesizes a number of thought leaders in psychology and organizational

change. In applying these conclusions to successful project management, the following

should be considered:

• People behave according to their mental models which provide a comfort zone.

Forcing people to do something outside of their model could reduce their

motivation within the project. Understanding and assigning tasks according their

mental model will maximize their motivational level.

• People�s behaviour is �hard-wired� and largely emotional where logical

persuasion is likely to have little impact, in spite of what it might seem like at the

time. A project may make logical sense but if there are negative emotions with

the team or stakeholders, it could have an adverse affect on the project. Project

managers and sponsors need to pay attention to people�s emotional indicators

related to the project. This includes customers, internal and external

stakeholders and the direct project team.

• Relatively few people whose need for satisfaction outweighs their need for

security will risk changing on their own, and of those that do, most will do so only

cautiously or reluctantly. For larger impacting changes, people who may agree

with the change will not risk their career to see it through. They do their own

internal risk assessment of what the change means to them. The higher the risk,

the more inclined people are to make decisions at a group level to reduce the


level of accountability for the change. Careful attention is required on how

organizations measure performance as this has a high impact on behaviours

within a project.

• People�s actions often don�t reflect their words about a change. Although people

are performing project activities, it doesn�t mean they support it or are motivated

to do it. By understanding people�s mental models and motivations, activities can

be assigned effectively with the leadership required.

• True behavioural change occurs naturally at a more evolutionary rate, not a

revolutionary one. Smaller, low risk projects are much more palatable than the

large big bang approach. Leaders should not expect their stakeholders to

change immediately. Depending on the impact of the change, consideration to

what it means for individuals is necessary for them to be positive and accepting

of the change or project (Dettmer, 2009).

Kerber and Buono state that the type of Change Management required in organizations

is dependant on business complexity and socio-technical uncertainty. Business

complexity refers to the intricacies of the system, the number of different components

and the extent of differentiation in the organizational system being implemented.

Indicators include factors such as organizational size and geographical dispersion, the

nature of interdependencies and related technology, the number of products and

services, and the array of critical stakeholders. Socio-technical uncertainty refers to the

amount and nature of information processing and decision making required for the

change based on the extent to which the tasks involved are determined, established, or

exactly known (Kerber, Buono, 2005).

Depending on the two parameters of business complexity and socio-technical

uncertainty, the change management process is broken down into three areas: directed

change; planned change; and guided change (Kerber, et al., 2005).

Effectively and appropriately engaging people in the planning process can reduce

implementation problems and generate buy-in for the current and more complex


changes. This is especially important when commitment to the decision is critical for

successful implementation. If the future state is unknown, managers must draw on tacit

knowledge of organization members. The iterative nature of the guiding change

process encourages the type of improvisation and experimentation needed to identify

the most effective actions, solutions and outcomes. Guided change is an attempt to

break through the constraints imposed by hierarchy and closely manage change

processes, dispersing awareness much more broadly throughout the organization and

ensuring that the right talent and appropriate resources are applied to continuous

change. Change Capacity and Urgency are also influencing factors as to the change

approach taken. The change capacity of the organization refers to (a) the willingness

and ability of change makers to assume responsibility for the change, (b) the existence

of a supportive infrastructure that facilitates change, and (c) sufficient resources

appropriate for the change. The urgency of the change situation refers to the risks

associated with no or slow change, such as when changes are needed to ensure the

personal safety of organizational members to protect customers, or to increase the

probability of organizational survival. Within this framework, resistance to change can

be thought of, in part, as a function of the mismatch between the demands of the

situation and the selected approach to change. As the pace of change in our business

environment continues to accelerate, organizational success will be increasingly

dependent on our capacity for continuous adaptation (Kerber, et al., 2005).

Summary

Organization Change Management and the psychology of change have a high impact

on the success of projects. The type of change as it relates to business complexity and

socio-technical uncertainty determines the level of management and framework

required to manage the project. Stakeholder�s attitudes and beliefs about the project

must be understood to effectively manage people. Leadership is important in

understanding people�s motivations, reinforcing positive behaviours and securing

people�s commitment in achieving the deliverables at hand. Collaboration is important

in drawing on tacit knowledge and using agile principles as iterations are used in

guiding more complex changes. Project managers must gain buy in and commitment of


stakeholders for maximum benefit to the project. They do this through influence and

understanding their mental models. Organizational structure should be reviewed as it

relates to matrix organizations as issues occur in conflicting priorities and power

between project and functional managers.

What considerations are there in complexity theory for IT project

management?

Complexity science is a domain starting to appear in project and multi-project

management. It�s significant because of the interdependencies in the project, program

and portfolio success. Interdependencies in the areas of knowledge, technology or

strategic interdependencies are underestimated. The level of complexity depends on

the number of interdependencies and their variation over time. Project risk

management methodologies need to consider all of them because their interaction is a

major source of uncertainty (Sanchez, Benoit, Pellerin, 2009).

Project, programs and project portfolios are interdependent and consequences of

events do not affect them separately, but collectively. There is a gap between risk

management approaches applied at the project level and at the organizational level.

It is understood that uncertainty of a project is higher at the beginning and diminishes as

the project progresses due to proactive planning and decision making; however this is

not always the case. Complex projects in changing environments are an example in

which uncertainly remains high throughout the project. The process of risk

management should continually verify the project�s variances and adjust accordingly.

The project must quickly adapt to changing circumstances (Sanchez, et al., 2009).

Hass�s book �Managing Complex Projects: A New Model�, states that change has

become the dominant theme of modern management and the nature of change itself is

changing. It�s happening faster than ever with more turbulence and less predictability.

The acceleration of the flow of information and the exponential increase in the number

of connections within and between organizations is having a dramatic impact. Twenty-


first century projects are referred to as �wicked problems� when dealing with behaviours

arising from the interdependence of users, technology, and context. A complex system

can be described as one in which many different components interact in multiple ways.

Because complex systems are largely unpredictable, thinking about business systems

as complex requires a paradigm shift from long established business models (Hass,

2009). IT projects have an additional level of complexity as technology is in a

continuous stream of change.

The current paradigm to manage projects says if we can decompose the work effort into

manageable chunks of work applying reductionism, we can reduce the complexity and

risk and control the plan. Traditional project methodologies such as PMBoK ignore the

reality of organizations as non linear feedback systems where slight variations amplify

into unpredictable results and the long term future is unknowable. The skill is not to

predict the future but to see patterns. Leaders in the this field realize a new paradigm is

needed for managing complex projects that employ an adaptive method versus the

more conventional reductionist approach that emphasizes planning and control. The

issue with project management is that external forces on the project demand flexibility

and high performance. Projects today need to deal with technology that changes

constantly, global markets that are complex and evolving, ambiguous corporate

strategies and poorly understood business requirements. Although adaptive project

management is still emerging, Hass suggests providing iterative learning experiences,

adapting and evolving as more is learned. Hass contends that as the project

management discipline matures, the realization of meeting project goals on time, on

budget and with a full scope is not enough. Sometimes the most creative solutions

emerge from teams operating on the edge of chaos (Hass, 2009). Appendix B outlines

the difference between conventional project management and adaptive project

management.

Highly complex IT projects could be characterized as a solution that requires innovation,

using immature, unproven, or complex technologies provided by outside vendors, IT

complexity and legacy integration are high. Quite often, IT teams are unable to manage


the dependencies and risks resulting in schedule and cost overruns, defects discovered

by the customer, and erosion of business benefits from the solution. IT organizations

are structured so that different teams are providing different components of the system

leading to bandwidth, performance and compatibility issues. The complexity of

business solutions and innovative products is growing faster than IT organization�s

ability to develop radical new approaches for replacing software development

technologies. Hass quotes Jim Highsmith that today�s development teams must strive

to adopt the objectives of reliable innovation:

• Continuous innovation: to deliver on current customer requirements

• Product adaptability: to deliver on future customer requirements

• Reduced delivery schedules: to meet market windows and improve return on

investment

• People and process adaptability: to respond rapidly to product and business

change

• Reliable results: to support business growth and profitability (Hass, 2009).

In highly complex projects, the design should be separate from construction. The goal

is to have the experts experiment, keep their options open before making design

decisions. Two emerging adaptive project management models are evolutionary

prototyping model and the extreme project management model. They include practices

such as late design freeze, built-in redundancy, lots of experimentation, and designing

and building prototypes for multiple parallel solutions. The figure below show the

models based on the type of project (Hass, 2009).


Figure 2: Models based on Project Complexity (Hass, 2009).

Appendix F is a spider chart that communicates the nature of the complexities for an IT

project. This chart depicts a project that is highly complex based the team composition,

urgent need, requirements volatility, political sensitivity, and level of organizational

change.

In Whitty and Maylor�s paper from the IPMA World Congress on Project Management

they discuss the nature of Complex Project Management. They indicate a complex

system is a system formed out of many components whose behaviour is emergent.

That is to say that the behaviour of a complex system cannot be simply inferred from

the behaviour of its components (Whitty, Maylor, 2009).

Project Complexity comes not only from individual structural elements categorized as

being external stakeholders, task characteristics and organizational complexity and their

interaction, but also from the dynamic effects of each of these changing and then

interacting as they change, causing further change in other parts of the system. They

also indicate that projects are socially construed entities; therefore, can be described as


complex adaptive systems. The characteristics of complex projects include open,

dynamic, recursive, non-linear feedback, and emergent. Activities can be very

complicated as they have many components, many interactions; have well defined

boundaries with predictable interactions across them. Some activities are complex

where there is an inherent limitation in our ability to predict the long-term or emergent

behaviour they create. The lack of predictability arises from the nature of the

interactions between the components and inability to measure the state of the system at

any time with sufficient precision. More research is required as approaches away from

the mainstream methodologies are not well developed (Whitty, et al., 2009).

In DeCarlo�s book �Extreme Project Management�, he indicates that current and

traditional best practices must be reformed because it is inadequate and performance

will continue to decline as projects become more uncertain, complex and pressed for

speed. He asserts project management is failing because of flawed assumptions and

idealized theory. A paradigm shift is required on two levels: we need to change the

model of what project management is all about; we need to change our own perception

of reality and our relationship to it. Management theory is based on a mind set that

reality is stable, predictable, and knowable. The quantum mind set is based on the

reality that change is normal and unpredictable. Extreme project management

recognizes although goals are achievable, how we get there is unpredictable; hence,

adaptability is more important than predictability (DeCarlo, 2004).

DeCarlo has identified 5 critical success factors for complex projects. They are as

follows:

1. Self-mastery and the ability to control the project rather than it control you by the

ability to manage the stress associated with these types of projects.

2. Leadership by commitment with the ability to unleash the motivation, innovation,

establish trust and confidence to succeed in the face of volatility.

3. Flexible project model that is iterative and consists of four cycles including:

a. Visionate: The What - Initial scoping, setting priorities and measurements


b. Speculate: The How � High level planning to sequence the deliverables

and identify milestones with the expectation it will change.

c. Innovate: The Doing � Experimenting and Rapid development, real time

feedback within predefined timeframes.

d. Reevaluate: The reviewing � Review results and repeat the speculate-

innovate-reevaluate sequence until desired results are achieved.

e. Disseminate: The Harvesting � Turning over the deliverables to the

customers and begin the benefits realization plan.

4. Real-Time Communication � Share information and have access to tools to self

organize and make decisions, a forum for discussion and debate so best options

are surfaced and addressed.

5. Agile Organization � Establishing a change tolerant project friendly culture that

recognizes and supports the special needs of different projects from traditional to

complex (DeCarlo, 2004).

In Bruna�s article on the Agile leader (Martinuzzi, 2009), she discusses the challenges

that people have with adaptability. Adaptability is seen as key trait in leaders and

project managers and as a competitive advantage for organizations. People have

mental scripts or models where the brain automatically processes information based on

experience resulting in being unresponsive to change, unwilling to learn and adopt new

ways. Developing an adaptive mindset includes the following:

• Challenge your mental models which are influencing your behaviour;

• Distinguish between observation and inference, between fact and conjecture as

inference and conjecture may not have a bearing on reality;

• Review your management style in how much you go by the book versus

flexibility;

• Continually evolve and grow by stepping outside of our comfort zone (Martinuzzi,

2009).


Summary

A paradigm shift is required to change our model regarding project management

considering the reality that the type of IT projects we are faced with today are more

complex where traditional project management practices are inadequate for successful

project delivery in many cases. Conventional project management methods fall short in

managing projects effectively where uncertainty and unpredictability is high in the

project.

Adaptability as the ability to change to new circumstances is key to complex projects as

requirements change and external factors impact the project. Creating an adaptable

model allows projects to change rapidly and allow for shifts or changes to the plan. It

allows for experimentation and prototyping before making design decisions. It�s closely

aligned with Risk Management in managing those variations from plan. It�s a mindset

that the plan will change rather than trying to stay with the original plan.

Particularly with larger projects, they shouldn�t be managed in isolation as there are too

many organizational interdependencies and external factors impacting them. Projects

should be managed at the Program and Portfolio levels with a focus on dependencies

and the interrelationships across the organization.

6. Key Recommendations

1. A methodology is required that integrates PMBoK and ITIL best practices. IT

Projects should be planned from a service lifecycle perspective. This is a more

holistic and integrative approach to managing the change of services. This

should include clear interfaces, roles and responsibilities between operations and

project intersects. Separate out project resources from operational resources

where possible to ensure availability of resources and ensure the project

management methodology considers how work will be completed with outsource

and external partners.


2. Create a Change Management framework that integrates strategic to operational

level changes with a leadership support structure in place. This should be

integrated with knowledge management by creating a learning based culture of

continuous improvement and collaboration.

3. A portfolio management system should be used to assist in prioritization and

workload management. Schedule projects based on critical chain and buffer

management with a focus on reducing constraints and managing workload

according to the largest constraint. Risk Management should differentiate

common cause and special cause variation where common cause is included in

the buffer management and special cause is risk managed throughout the

project.

4. People should be given the accountability and responsibility to do their work with

a support structure established to motivate and support them in successfully

completing their work. Collaborative approaches should be used to establish

positive group dynamics and to communicate effectively with all stakeholders.

5. Performance measurements should be established for both project and

operational resources involved in projects. Individual and team metrics are

important in developing the cohesiveness and trust within a team. Performances

measurements should also be expanded to include the business value of a

project such as ROI, customer satisfaction and quality of the production system.

6. Simplicity in project planning and delivery is a paradox to managing complex

change. It�s essential to keep a project as simple as possible.

7. A more adaptive project management approach should be used in managing

complex projects.

7. Synthesis and Conclusions

The main research question for this paper is �How can Information Technology Projects

be improved to increase the ability to deliver successful projects?� It�s a question that

organizations have been struggling with for many years as the statistics continue to

show a failing grade in project delivery. Despite this discouraging outlook, there has

been a high level of success in project methodologies and principles that are not as


ubiquitous as some of the more traditional approaches are. Some of the reasons are

that they are relatively new in the project management discipline within the last 10 to 15

years; they require an organizational cultural change and they go against traditional

management principles used over the last 50 years. The purpose of this research is to

identify the successful principles, theories, frameworks and methodologies, evaluate the

synergies among them to understand how they can be integrated and applied together

to increase the probability of IT project success. To that end the following lists the

results of the analysis that identifies the key areas that should be considered for

successful project delivery.

Organizational Structure

Organizational structure is important is bringing IT functional groups together to work on

projects. Clear interfaces and roles and responsibilities are required for operations and

project intersects. When departments are segregated by functional areas and report to

functional managers, conflicting priorities arise particularly when the workload varies

from one group to another. Operational activities are a higher priority than project

activities particularly with production impacting incidents that can cause delays in

completing project tasks. Organizations should consider having dedicated project

resources separate from operational resources. Project resources should also have

accountability for the production system for a given period of time to resolve production

issues as this is where the business value of the project is validated and used.

Operations groups often are a key stakeholder in project delivery and should be

involved in the project in early stages. Rotating resources between operations and

project delivery for specific roles would give people an appreciation of the full service

lifecycle. Agile stresses the importance of close physical proximity of teams. This is

more difficult as organizations are global and often distributed in several locations. E-

collaboration is important in breaking down those functional silos and bringing together

virtual teams. Outsourcing continues to have a large impact on IT organizations and

challenges arise from the integration of external processes, information sharing and


group dynamics. These areas need careful planning when outsourcing is a part of an IT

organization in delivering services.

Organizational culture

The organizational attitudes and beliefs about project delivery and change establish the

methodologies and practices put into place to manage the delivery of projects. Agile

practices question the traditional management principles with supporting self organizing

teams, placing accountability with the team. Agile, Lean, Theory of Constraints, ITIL all

reinforce the importance of continuous improvement. This should not only be a process

but a mindset built into the culture of the organization. It�s in developing a learning

culture based on knowledge management and knowledge sharing where organizations

get the value of continual system improvements. This is particularly important where IT

organizational goals and objectives are changing to meet business needs. It also

allows for people to become more adaptable and comfortable with organizational

changes.

Organizational Change

Not only does culture play a key role in the success of organizational change, but strong

leadership is a critical success factor. Management support is important for changes

impacting people so that their buy in and support of the change is also there. Change

management should be looked at holistically from a strategic perspective as well as

tactical or operational. ITIL V3 made this clear in the focus of managing services from a

full lifecycle perspective.

Scheduling

Critical Chain Project Management (CCPM) has had much success in the methodology

used for scheduling. Critical Chain has many benefits over PMBoK�s critical path using

buffer management more effectively and performance improvements in the area of


50%. It also considers how people work and allows them to better focus on their tasks,

removes excess multitasking and schedules based on the overall resource capacity

used in all projects. CCPM requires a commitment at the organizational level as project

tasks are managed at the portfolio level, functional managers are more engaged in

managing their queue and resource capacity, and a system is required that has an

overview of the project activities and workload across the various groups. Critical Chain

Project Management (CCPM) manages the workload of the various groups involved in

project delivery across the organization through multiproject software. It focuses on

managing workload accordingly to capacity constraints at a portfolio level. This is

important as resources in matrix organizations typically work on multiple projects and

project mangers don�t have a view of the workload in a functional department as this is

managed by the functional manager. Prioritization is important as the scheduling

criteria are established on how departments will queue and perform their tasks. The

implementation of buffer management as a key management and executive process for

identifying task time variations and project problems during execution allows for better

management of the resources and project schedules. The primary benefits gained from

using CCPM are projects completed on time, within budget, delivering full scope. There

is a clear focus with a simplified project plan and increased throughput.

Risk Management

Theory of Constraints distinguishes between common cause variation and special

cause variation. Common cause variations are known variances that can be expected

for a given task. Special cause variations are those uncertainties that impact the project

and need to be risk managed. CCPM manages these differently where PMBoK does

not distinguish them. In using CCPM, buffer should be used in specific areas

throughout the project rather than linked to individual tasks to manage common cause

variation. Risk Management as an ongoing activity throughout the project as it is

necessary in adapting and quickly changing the plan to align with special cause

variations. Change management is closely linked with Risk Management, particularly at

the tactical and operational level where production systems are impacted. The


procedures established for change management should be in line with the level of risk

associated with the change and the accountability for the change should be carefully

considered with the roles in the organization.

Human Resources

People are the greatest critical success factor in project success. Managing people is

more of an art than a science that is based on building relationships, understanding

personal characteristics, aligning skill sets, group dynamics and team building,

organizational culture, and adaptability to change. The ability to motivate and influence

stakeholders including project team members to gain commitment to the project has a

high impact on the success of the project. Agile and Theory of Constraints stress the

importance of a person being in control of their work and taking accountability for it.

Their ability and motivation to improve their work is important not only for the individual

but the organization. As IT systems become more complex, the ability to collaborate

effectively will be a key skill set. Information Technology is on an evolving continuum

where professionals have always had to learn and keep up with new technologies. The

soft skills were not seen as important; however, are becoming increasingly important as

different methods of communication are used and the use of technology in e-

collaboration is increasing the efficiencies and value for projects. In building powerful

teams, the project manager should work on establishing group dynamics based on the

following:

• Trust among the project members where they can dependent on one another.

• Open to positive debate to come up with best solutions where there is not fear of

conflict. Those in positions of authority should not make decisions where the

group should have the responsibility.

• Commitment of the group by establishing clear direction and setting expectations

with aligned performance measurements.

• Accountability at the team and individual level where people can not hide behind

processes.


• Establishing team goals and reinforcing those throughout the project where the

team is results oriented.

Performance Measurement

People often prioritize and perform their work according to how they are rewarded and

measured by it. Performance metrics not aligned with project success factors will likely

lead to conflicts and inefficiencies in project delivery. For example, an operational

resource that has no project metrics to deliver the work based on schedule, has no

incentive to ensure the work gets done according to the project schedule. Operational

roles should have project measurements if they are required to meet project

deliverables. Project resources should have measurements based on the performance

of the system in production. Team measurements should be established in addition to

individual measurements to develop dependencies and trust among the team.

Collaboration

Collaboration has always existed among groups but is increasingly important as

projects become larger and complex and the options increase. For IT projects, there is

a requirement for diverse groups to work together to design and build solutions. Agile

stresses the important of groups working closely together including the business

sponsor for software development projects. Quite often, these groups have to get

infrastructure and operational groups involved in building the system. For distributed

and functionally diverse teams, having the right tools and a culture of participation is

important in delivering a quality system. Project manager build up teams by

understanding the group dynamics and applying proper communication channels.

Communities are becoming more popular as a method of information sharing as

organizations implement reward and recognition programs to encourage collaboration

and information sharing. Keeping information to oneself is common as people believe

they have job security and power. These attitudes need to be broken down by rewards


for information sharing and creating a knowledge management system for the

organization where individuals see the benefits.

Service Lifecycle

Although IT Service Management (ITSM) based on ITIL best practices is not a project

methodology, it has a significant impact on project delivery as it includes best practices

for the end to end service lifecycle that IT organizations provide. Often ITSM and

project delivery processes are developed in isolation even though there are many

integration points. Organizations should consider an IT project methodology that

integrates the two frameworks. The Service Pipeline is introduced in Service Strategy

as a method of tracking services phased into operation by Service Transition after

completion of design, development, and testing. This pipeline could be integrated with

CCPM in having visibility of work in the early planning stages and establishing service

priorities for queuing and effective resource management. This should also be linked to

the Change Management system to understand the impacts of changes to services.

Release Management is included in the bundling of deliverables for specific services

that would be identified in the service pipeline.

Business Value

The definition of project success varies; however many companies have based it on the

three pillars of cost, schedule and scope. ITIL has a service lifecycle perspective and

looks at the business value of an IT service. Perhaps organizations have been too

myopic and should focus on the business value that a project is giving. Success factors

would include return on investment, customer and stakeholder satisfaction, and the

quality of the production system. As businesses depend more on IT, they need to

develop a partnership role where they are involved in making key decisions rather than

a supplier role where they have little influence in planning their organization.


Agile

Agile principles that started off in the software development area, is gaining momentum

in all areas in business and outside of the business domain. It�s comparable to lean

which has dominated the manufacturing sector for many years. Agile uses Iterative

techniques that allow for reduced project timelines resulting in faster throughput, met

requirements and lower costs. Working closely with the business sponsor usually

results in higher quality deliverables and high customer satisfaction. Simplicity is an

agile principle that states it as the art of maximizing the amount of work not done as

essential. This is very insightful as organization, systems and processes become more

complex. Organizations need to strive to keep projects simple.


References

Beck, K & Beedle, M & Bennekum, A & Cockburn, A & Cunningham, W & Fowler, M &

et. al. (2001). Agile Manifesto. Retrieved November 21, 2009, from

http://agilemanifesto.org/principles.html

DeCarlo, D. (2004). Extreme Project Management. San Francisco: Jossey-Bass.

Dettmer, W. (2007). The Logical Thinking Process, Wisconsin: Quality Press.

Dettmer, W. (2007). Changing the Status Quo. Retrieved March 6, 2010, from

http://www.goalsys.com/books/papers.htm#ChangeStatQuo

Hass, K. (2009). Managing Complex Projects: A New Model. Management Concepts.

Books24x7. Retrieved November 14, 2009, from

http://ezproxy.athabascau.ca:2051/book/id_28584/book.asp

http://www.intel.com/technology/mooreslaw/ (n.d.). Retrieved February 27, 2010.

Leach, L. (2005). Critical Chain Project Management, Second Edition. Artech House.

Books24x7. Retrieved November 14, 2009, from


Kerzner, H. (2006). Project Management: A Systems Approach to Planning,

Scheduling, and Controlling, 9th ed. New Jersey: John Wiley & Sons.

Kerzner, H. (2003). Project Management: A Systems Approach to Planning,

Scheduling, and Controlling, Eighth Edition. John Wiley & Sons. Books24x7.

Retrieved March 13, 2010, from


Kerber, K. & Buoni, A. (2005). Rethinking Organizational Change: Reframing the

Challenge of Change Management. Organization Development


Journal, 23(3), 23-38. Retrieved November 22, 2009, from ABI/INFORM Global.

(Document ID: 883540011).

Klosterboer, L. (2009). Implementing ITIL Change and Release Management. IBM

Press. Books24x7. Retrieved November 14, 2009, from


Kock N. (2008). Encyclopedia of E-Collaboration. IGI Global. Books24x7. Retrieved

February 7, 2010 from


Martinuzzi, B. (2009). The Agile Leader: Adaptability. Retrieved March 20, 2010, from

http://www.mindtools.com/pages/article/newLDR_49.htm

Office of Government Commerce (OGC), 2007. ITIL Service Strategy, TSO, United

Kingdom.

Office of Government Commerce (OGC), 2007. ITIL Service Transition, TSO, United

Kingdom.

Patrick L. (2006). Team Dysfunction. Leadership Excellence. Retrieved March 6, 2010,

from ABI/INFORM Global. (Document ID: 1190701401).

Sanchez, R. & Benoit, B. & Pellerin, R. (2009). Risk management applied to projects,

programs, and portfolios. International Journal of Managing Projects in

Business, 2(1), 14-35. Retrieved November 21, 2009, from ABI/INFORM Global.

(Document ID: 1628617881).

Slack, N. & Chambers, S. & Johnston, R. (2007). Operations Management, 5th ed.

England: Pearson Education Limited.


Orr, A. & Turner, J. & Oryst, K & Bullen, G. (2008). Harnessing the Power of ITIL ".

Harnessing the Power of ITIL. Books24x7. Retrieved February 7, 2010 from


Pinto, J. & David C. & Slevin, D. (2003). The Frontiers of Project Management

Research. Project Management Institute. Books24x7. Retrieved February 13,

2010 from http://ezproxy.athabascau.ca:2051/book/id_5612/book.asp

Project Management Institute (PMI) (2004). A guide to the project management

body of knowledge, Third Ed. Newtown Square, PA: Project Management

Institute.

Whitty, S & Maylor, H. (2009). And then came Complex Project Management (revised),

International Journal of Project Management, Volume 27, Issue 3, Pages 304-

310, ISSN 0263-7863, DOI: 10.1016/j.ijproman.2008.03.004. Retrieved March

28, 2010, from http://www.sciencedirect.com/science/article/B6V9V-4S9NGDD-

2/2/7a5261fcb883b724b248baa743e82469

Raz, T. & Barnes, R. &, Dvir, D. (2003). A Critical Look At Critical Chain Project

Management. Project Management Journal, 34(4), 24-32. Retrieved February

13, 2010, from ABI/INFORM Global. (Document ID: 522998801).

Wysocki, R. (2009). Effective Project Management: Traditional, Agile, Extreme, Fifth

Edition. John Wiley & Sons. Books24x7. Retrieved January 24, 2010 from


White, J. & Chaiken, S. (2008). Lean Information Technology Service Management:

Bottom-Up Process Improvement That Addresses The Bottom Line. Contract


Management, 48(5), 22-24,26,28. Retrieved January 31, 2010, from

ABI/INFORM Global. (Document ID: 1482525841).

Whitaker, K. (2010). Principles of Software Development Leadership: Applying Project

Management Principles to Agile Software Development. Cengage Learning.

Books24x7. Retrieved February 13, 2010 from



9. Appendix A: Agile Manifesto

(http://agilemanifesto.org/principles.html, 2001)

We follow these principles:

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.

Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.

Business people and developers must work

together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.

The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.

Continuous attention to technical excellence

and good design enhances agility.


Simplicity--the art of maximizing the amount

of work not done--is essential.

The best architectures, requirements, and designs

emerge from self-organizing teams.

At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts

its behavior accordingly.


10. Appendix B: Comparison of Conventional versus Adaptive Project Management

Characteristics of Conventional versus Adaptive Project Management Conventional Project Management Adaptive Project Management

Structured, orderly, disciplined Spontaneous, disorganized

Relies heavily on plans Evolves as more information is known

Predictable, well-defined, repeatable Surprising, ambiguous, unique,

unstable

Unwavering environment Volatile and chaotic environment

Proven technologies Unproven technologies

Realistic schedule Aggressive schedule, urgent need

(Hass, 2009)


11. Appendix C: Linkages among frameworks and methodologies

The theories and frameworks analyzed in this paper are assessed against the PMBoK

knowledge areas and Critical Chain features to identify common activities. For

example, in TOC, the activity of identifying the constraint could be found in Integration,

human resources and critical chain. In ITIL, aligning the service transition plans with

customer and business requirements could be found in PMBoK�s scope knowledge

area.

PMBOK Knowledge Areas

Critical Chain Features

Inte

grat

ion

Sco

pe

Tim

e

Cos

t

Qua

lity

Hum

an R

esou

rces

Com

mun

icat

ions

Ris

k

Pro

cure

men

t

Mea

n es

timat

es

Crit

ical

cha

in

Buf

fers

Rel

ay-r

acer

Buf

fer m

anag

emen

t

Pro

ject

prio

rity

Pip

elin

ing

TOC (Theory of Constraints) Identify constraint x x x Exploit constraint x x x x x x Subordinate to constraint x x x Elevate constraint x Do not let inertia impact x ITIL Align ST plans with customer and business requirements x Establish and maintain relationships x x Establish controls for transition of services and releases x x x

Release packages that are built, tested and x x x


deployed into production that are traceable, cost-effective and efficient. Provide and manage shared and specialist resources across ST activities to eliminate delays. x x Assure the quality of the new or changed service. x Agile Interative development x x x x Faster delivery x x x Collaborative teams x High quality deliverables x x Simplicity Self organizing teams x Retrospectives x LEAN Value x x x Value Stream x x x x x x x x x Flow x x x x x x x x x x Pull x x x x x x Perfection x Six Sigma Customer focus x x x x Data driven x x x x x x x Management process focus x x x x x x x x x Proactive management x x x x Boundaryless collaboration x x x Perfection x


12. Appendix D: Comparison of a convention and CCPM schedule

(Raz, Barnes & Dvir., 2003).


13. Appendix E: People Improvement Process

I have more and more sufficient understanding of my

system, or access to it.(CONTENT KNOWLEDGE)

I am (more and more) determined to act.(SELF-DISCIPLINE)

My system improves.[DESIRED EFFECT]

I have, and know how to

use tools, procedures to improve the system.(METHOD)

I am (more and more) empowered to improve

the system.(POTENTIAL)

I accept responsibility for

action.(ACCOUNTABILITY)

I have influence in

changing my system.

(AUTHORITY)

I desire (more and more) to improve

my system.(MOTIVATION)

INJECTIONSuccess is

reinforced/rewarded

Positve reinforcing Loop #1 Positve

reinforcing Loop #2

Adapted from Dettmer, Breaking the Constraints to World-Class Performance (1998)

(Dettmer, 2007)


14. Appendix F: Spider Chart to identify project complexity

(Hass, 2009)

Techniques to Improve the Probability of Success in Information ...

Documents

Transcript of Techniques to Improve the Probability of Success in Information ...