Hi everyone, I am Roman Reznikov, I work at Project Management Office at SoftServe. One of my focus areas is the development of the Service Manager competence and company’s approaches to working with service projects (SLA-projects, support, etc.). In this article, I will make a brief comparative overview of two sources of the best practices. It will help you to gain an understanding of what is worthwhile to be added to your own PM toolkit.

The nature of the problem

   For the majority of Project Managers (even Agile), PMBoK is the classic source of the best project management practices. Those, who at least once looked up in PMBoK, remember that project is limited in time, is unique, and has a defined scope. However, if you look at a greater part of IT projects, especially in the field of IT-outsourcing – in most cases it is whether the T&M or Dedicated Team, you will see that this form of cooperation is more like a service.

   In particular, we offer our client a service – software development, while a true project is rather considered as Fixed Price. Hence, if you have a contract with the client that presupposes rendering resources instead of a concrete result, you can safely name it a service. This is not to say that PMBoK is not applicable to this case, but it does mean that you should turn your attention and take a deeper look at one more source of knowledge – ITIL (and especially consider such chapters as Service Level Management, Capacity/Availability Management, Request Fulfilment, and Incident Management).
   PMBoK is the American national standard for managing projects that describes the best project management practices. Namely, it is applicable to the time-limited scope of work that aims at the creation of a unique product, service, or result. According to the PMBoK, service refers to an operational activity (it is not a project), thus, PMBoK practices are not suitable for this case (but nobody prohibits their employment).
   ITIL best practices cover precisely this kind of activity. ITIL (IT Infrastructure Library) is the most widely used and known approach to IT-service management worldwide. ITIL was developed relatively independently of project management, it embodies a few valuable management ideas, and includes verified procedures, which can also be of great use for the project management practice.

   PMBoK depicts the best practices represented by 49 processes, each of them consisting of a series of Inputs, Outputs, Tools and Techniques. PMBoK process example:
   ITIL is developed in a similar way; however, it differs in structure. According to the main books index (Core library), ITIL has 26 processes, but there are also so-called sub-processes that are briefly described in the framework of Capacity management process. These processes do not have a standard for ITIL structure of processes description. For instance, Service capacity management or Component capacity management.
   Moreover, ITIL has some types of activity that are mentioned in the text as processes but have no separate description at all. A general ITIL process structure:
   As we can see, ITIL process structure in some way resembles the process depicted in PMBoK. In general, they both have such common features as inputs, outputs, techniques, and methods, and all of this is actually called a process. However, ITIL presents process performers and process monitoring one by one, while PMBoK unites control and monitoring into a separate group of processes. This is how a general picture of both processes looks like:
   As the table above shows, ITIL processes are grouped into 5 stages of service life-cycle (Service Strategy, Service Design, Service Transition, Service Operation, and Continuous Service Improvement). Apart from 26 processes, there is also a description of 4 functions. PMBoK depicts a few more processes that have a slightly complicated structure: 49 processes are organized into 5 groups of processes (Initiation, Planning, Executing, Monitoring and Controlling, and Closing); moreover, these 49 processes are also classified by areas of expertise. These 5 groups of processes are often confused with the stages of the project lifecycle, but that's all wrong. The given misunderstanding has led to a prejudiced perception that PMBoK=Waterfall, being also a faulty perception.
   Therefore, PMBoK groups all processes into a matrix for the ease of navigation. ITIL and PMBoK have no identical processes, just similar ones. For instance, change management in ITIL and integrated change control in PMBoK.

Integrated change control (PMBoK)

Change management (ITIL)

According to PMBoK, integrated change control is the process of reviewing all change requests, approving and managing changes to deliverables, and communicating their disposition.    This process includes the analysis of all requests for changes to deliverables along with their approval or rejection. The key benefit of this process is that it allows for documented changes within the project and reduces project risks that often arise from changes, introduced without a proper review.    The integrated change control process is conducted from the project inception until its closure and relates to the primary responsibility of the project manager.    Any stakeholder, involved in a project, can submit a change request. Despite changes may be initiated verbally, they must be registered in written form and entered into change management or/and configuration management system. Every written change request must be either approved or declined by a responsible person, usually by a sponsor or project manager.    When required, the Change Control Board – a formally chartered group that is responsible for the review, evaluation, approval, delay, or rejection of changes to a project, and for recording and communication of decisions, joins the Integrated Change Control process.    All approved change requests may require the creation of new or review of old cost estimates, activity sequences, schedule dates, resource requirements, and analysis of alternative responses to risks. All these changes may need adjustments to project management plan or to other project documents.

The book Service Transition, one of featured in the ITIL library readings, defines change management as a change control process that is concerned with the life-cycle of all changes and their adoption with the minimal negative outcomes for IT-services.    The key benefit of this process is that it allows for changes within ITIL services so that they meet the business needs. All changes must be estimated, documented, and approved. Change management does not cover changes to business processes.    ITIL defines a change as the modification or removal of any component that may affect an IT service. As usual, change request has a standard and previously approved form (RFC).    ITIL outlines 3 change types:    Normal changes – they require estimation and approval before implementation.    Emergency changes – they have to be implemented as soon as possible. Such changes usually pass a specific accelerated procedure and do not require a detailed estimation of outcomes.    Standard changes – as a rule, they come up frequently, have a low risk level, and do not require any additional approvals and agreements. They tend to pass a pre-approved scenario.    The Change Advisory Board is a special group convened to authorize changes and to help a manager with their estimation, prioritization, and approval. All group members must have the authority and proper experience to estimate changes.    Moreover, there is also a separately convened Emergency Change Advisory Board. This group frequently gathers on an urgent basis for a quick estimation of emergency changes.

   As is evident from the description, taken from the official sources, both processes have a lot in common. They both require a preliminary estimation before the implementation of any change along with its profound documentation; they suggest the approval procedure that can be implemented either by a specially organized group of people (CCB in PMBoK or CAB and ECAB in ITIL) or by a specially selected person (project manager, sponsor in PMBoK, or change manager in ITIL).
   Integrated change control in PMBoK:
   Thus, we can make a point that PMBoK and ITIL approaches are very similar.

Differences

   Let’s look at a few approaches that differentiate these two standards. It will help us to consider some things from a different perspective.

User vs Customer

   ITIL differentiates clients from users: clients define requirements, order a project, pay for its implementation, and approve (accept) project results, while users utilize project result on a daily basis, having no real authority for decision-making (but they can have some impact on a client). Usually, the client is a leader of an organization, while users are its members. Both clients and users may have different interests. Currently, PMBoK guidance does not differentiate these roles. In real life, they are frequently confused with each other and considered under a common approach, which is wrong.

Incident Management & Request Fulfillment

   The project, in its nature, does not suppose getting new portions of requirements or requests somewhere in the middle of its execution. Actually, it may happen, but each request of such type has to undergo the Integrated Change Control – a process, which results in modified project baselines (scope baseline, quality baseline, schedule baseline, and cost baseline). In general, this procedure is quite complicated. So, what should we do if we use Scrum or Kanban? We get new portions of work each iteration, if not more frequently. In this case, both an action plan and instructions on managing such requests can be found in ITIL in the chapters Incident Management and Request Fulfillment.

Problem Management

   Both ITIL and PMBoK suggest a toolset for problem identification and resolution (even though both standards perceive the term “problem" a bit differently). PMBoK is rich in a toolset of techniques and instruments that help to work with project problems in very effective ways. Some examples of such instruments are as follows:

• Control chart
• Pareto chart
• Histogram
• Control sheet
• Ishikawa diagram
• Stratification
• Scatter diagram

   In practice, I often use the Ishikawa diagram (Fishbone Diagram) to analyze a problem (mostly, during retrospectives).
   The image above visualizes the example with two levels of bones. A red color marks the first level – main (core): a, b, c, d, while the blue one marks the second level – deeper (more detailed) causes (factors) of an examined impact on a result (among 2nd level factors are those that amplify the 2nd level effect: e, f, g, h, I, l, m, n, o, p, and the ones that weaken it: k, n).
   The division of all defined factors is further expanded according to their increasing specificity until all problem branches can be subjected to further division (while doing so, it is necessary to detect true causes, not symptoms).
   The work with the Ishikawa diagram presupposes several stages:

1. Detection and collection of all factors and causes that for some reason affect an analyzed result;
2. Grouping of all factors into conceptual and cause-effect blocks;
3. Categorization of factors inside each block;
4. Analysis of an obtained picture;
5. “Dismissal” of those factors that we cannot affect;
6. Disregarding of insignificant and nonessential factors;

   One more useful instrument for working with problems, which you can find on PMBoK pages, is the Affinity diagram or KJ Method. In fact, it is an addition to brainstorming, when all gathered facts and ideas are organized into clusters depending on their interconnection. This technique is well suited for workshops: you need to gather all necessary stakeholders who have some relation to the given problem and to stock up with a big amount of colorful stickers, which are the “atoms” of facts and people whom you are going to split into different groups.
   Further on, there are a few simple steps to follow:

Step	Phase	Description
1	Identify a problem	Define your problem or a common topic. Example: Why does the client satisfaction level decrease?
2	Collect ideas	Enlist all appropriate facts, data, ideas, subject-related opinions, write them on stickers, and pin them to a board
3	Find connections between ideas	Pay attention to similar notes or cards, and divide them in accordance with samples, based on these similarities
4	Group ideas into clusters	Mark each group of similar notes or cards by a tag for each Affinity group. These can be some aspects of an examined problem. Prioritize all detected problems.
5	Analyze a result	Look at the created groups and facts that are related to each idea. What ideas does it raise in terms of the initially defined problem? Does it suggest some potential decision?
6	Share results	Share your results with all parties interested

   In PMBoK, all instruments that allow for effective work with problems are not separated into distinctive processes or knowledge areas, instead, they are divided into other areas of expertise (most of them belong to the Quality Management). ITIL depicts all this as a separate process.
   Problem management is one more important chapter, presented in ITIL in the Service Support section. The main goal of this process is to minimize the negative impact of incidents and problems on a business, caused by errors in IT infrastructure and to prevent the reoccurring of all incidents, which stem from such errors.
   The problem appears to be the main unknown reason for one or more incident. A very common mistake is a successfully detected problem (the main cause is known), which was addressed by a temporary workaround or a permanent decision.
   Problem control as a part of ITIL aims to turn problems into known errors to detect the causes of incidents, while error control presupposes the elimination of known mistakes using the change management process.
   Problem control stages:

1. Identification and recording of a problem;
2. Problem classification;
3. Examination, diagnosis, and root cause analysis of a problem (to define the main unknown cause of the problem);

   Functions of error control:

• Identification and recording of all errors;
• Estimation of errors;
• Elimination of recording errors (at this point, a change request for a permanent approval will be submitted);
• Resolution of errors and screen resolution progress;

Conclusion

   To sum up, it stands to mention that both PMBoK and ITIL have a similar approach to some questions, but they have different areas of application. PMBoK is an appropriate source of the best practices for projects with fixed price and scope. In turn, ITIL will be more relevant to those projects that have SLA, support, and maintenance.
   For most projects that use Kanban, the Service Operations book (it is included in the ITIL library) will be of great use. Moreover, ITIL is widely used by IT-Departments of big companies; thus, Service Design and Service Strategy books are good for launching new IT services.
   On the other hand, the development and implementation of a new service can be facilitated within the project scope, where PMBoK practices will be effectively applied. Meanwhile, the transition of this service from the development to support, its direct maintenance, and improvement are also described in ITIL.
   Thus, depending on project specifics, you can use both PMBoK and ITIL practices. On IT projects, which often follow Agile approaches to resolve standalone solutions that are described neither in Scrum nor in Kanban, both ITIL and PMBoK processes can be easily applied, depending on what fits best. For instance, the risk management process can be set up according to PMBoK recommendations, while incidents management can be facilitated in compliance with ITIL. It is worth having both toolsets of the best practices in own arsenal so each of them can be used at the right time.
   I hope that this article will prompt you to generate new ideas for managing your projects.