Integrating project management and service management

Stephanie Iverson, MBA, PMP, PgMP, Sr. Director Work Management, Marriott Vacation Club International

Doug Johnson, PMP, Director Project Management, Marriott Vacation Club International


For many companies, the Information Technology Infrastructure Library (ITIL) framework has been deployed as a major methodology component for managing the operational side of information technology. These same organizations rely on project management methodologies for new capital development and enhancements. A mismatch occurs when the two disciplines work independently. This paper presents an approach for integrating the service management and project management methodologies for IT work, from the most strategic level of a company’s portfolio to the detailed activity level of technology development and operations.

At Marriott Vacation Club International (MVCI), the Information Resources Department (IR) has aligned and implemented 52 percent of the ITIL processes over the past six years, and had been using project management methodologies since the company’s inception in 1984. While we have been successful at deploying project management over the years, more so since incorporating A Guide to the Project Management Book of Knowledge (PMBOK® Guide)—Fourth Edition (Project Management Institute [PMI], 2008) methodological concepts and working towards getting our project managers certified, we were new at using a formal methodology for our operational processes. We felt it was critical, however, to move to ITIL to improve our productivity and to develop the partnership between the business process areas and information technology areas. Without this linkage, the alignment between business strategy and Information Technology would be less effective, at best.

The first step was to begin to integrate the ITIL and project management processes from the top down to obtain buy-in at the strategic executive level. Once this support structure was in place, we worked our way down through the project management processes and knowledge areas, integrating with each of the ITIL processes. This has resulted in a workable, strategic model to take MVCI’s IT organization into the future.

Company Overview

Marriott International, a worldwide leader in the lodging industry operates three business segments. Marriott International is headquartered in Bethesda, MD, USA, has approximately 129,000 associates, and operates more than 3,600 properties in 71 countries and territories. It is rated as the lodging industry’s most admired company, one of the 100 Best Companies to Work For by FORTUNE, and recognized by Newsweek as one of the greenest big companies in America. Marriott brands are recognized worldwide and include: Marriott Hotels and Resorts, The Ritz Carlton, JW Marriott, Renaissance Hotels & Resorts, Residence Inn by Marriott, Courtyard by Marriott, Springhill Suites, and Fairfield Inn & Suites. At the end of fiscal year 2010, Marriott International reported sales from continuing operations of nearly US$12 billion.

The Vacation Ownership division is one of three business segments operated by Marriott International and consists of three brands: Marriott Vacation Club (53 resorts); Grand Residences by Marriott (2 fractional properties/2 private residences); The Ritz-Carlton Destination Club (14 properties). Marriott Vacation Club International has 71 timeshare and fractional resorts with more than 410,000 owners and approximately 9,500 employees. The division manages resorts in North America, the Caribbean, Europe, and Asia. In 2010, Marriott International reported Vacation Ownership segment contract sales revenue of approximately US$705 million.

MVCI Baseline

Getting Started

MVCI Information Resources had its first project management training that incorporated PMBOK® Guide framework back in 1998. Following this, several of our project managers became Project Management Professionals (PMPs)® credential holders. While encouraged, the certification has never been a requirement for the project management discipline at MVCI.

In 2005, MVCI Information Resources began the ITIL journey, implementing our first process in 2006. At that point in time, a limited number of ITIL processes were identified to be aligned and implemented over the next few years, and version 2.0 training was deployed for most IR resources. ITIL Certification was a one-time test, and continued renewal did not carry forward into subsequent years until 2011.

Between 1998 to 2009, little was done to integrate the emerging IR ITIL processes with project management processes. A significant part of the information technology organization and its customers had limited knowledge of both methodologies, the terminology or the process benefits. Furthermore, our project management organization was operating independently from the Service organization; in fact, the majority of project managers had little or no understanding of the ITIL framework. In 2009, IR leadership started to take a fresh look at the two processes to explore how they could be used to provide better service for project management customers.

Each of the MVCI Work Management process frameworks, PMBOK® Guide and ITIL, had its own governance structure by which work was approved. Information Technology Project Requests were submitted through the project management office (PMO), estimated, and sent to an executive group (called the Technology Executive Committee [TEC]) for approval to proceed. Enhancements and defects were called in to the service desk and/or were identified and discussed in Service Review Boards, which were groups made up of IR analysts, IR managers, and business customers. In these forums, it was determined which work requests would move forward and in roughly what priority order autonomously within each group. Infrastructure work requests were discussed and approved only within the Infrastructure group (Exhibit 1).

Work request submission processes

Exhibit 1. Work request submission processes

Problem Statement

We easily identified two key issues with the approach we were using. First, IR resources were often shared among projects, enhancements, defects, and infrastructure work. Since these types of work requests were being reviewed and approved independently and assigned independently, there could be no work prioritization across shared resources. This kept us from being able to most effectively plan start and end dates for any type of work. Furthermore, work could be approved without a formal business case. Although project work often required a business case and financial assessment, most other work was performed simply by customer request and mapped back to business strategy.

Since not all work was funneled through a common pipeline, it was hard to identify where functionality overlapped between project work and operational work. This had the potential for causing duplication of effort and associated costs.

One of our goals in 2010 was to further align to the ITIL processes, so that the ITIL framework and the IT Service Management approach would become fully integrated within our IR organization. Alignment in the first few years had been primarily focused on the ITIL service support processes: incident management, problem management, change management, and release and deployment management. We realized that along with aligning to additional ITIL processes and continued integration of the processes, to really gain the maximum benefits from ITIL, the overall delivery of IT services needed to be our central focus for doing business with our customers. After all, it is not just these support process areas that provide services to customers; every functional area of IR strives to deliver some level of service to a customer. The ITIL

Version 3 framework validated this with a broader approach to Service Management. Lastly, if we could gain efficiencies by integrating our Service Management and Project Management organizations within IR, we believed we could better meet the overall strategic needs of the MVCI organization. Our first task to integrate the Service Management and Project Management processes was to establish definitions and benefits for each discipline.

Discipline Overview

Project Management

The definition of project management from the PMBOK® Guide—Fourth Edition (2008, p. 434 is “An endeavor with a definitive beginning and end, undertaken to create a unique product, service, or result.” Project management is “the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.” “Project Portfolio Management is the centralized management of one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling projects, programs and other related work to achieve specific strategic business objectives” (PMI, 2006, p. 5).

Service Management

“Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services. A Service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Service Portfolio Management (a new process in ITIL V3) is a dynamic method for governing investments in Service Management across the enterprise and managing them for value” (ITIL Service Strategy, Office of Government Commerce, 2007, p. 15 & 16).

Not surprisingly, both Service Portfolio Management and Project Portfolio Management have the same strategic goal: to maximize value for the business. As stated previously, Service Portfolio Management provides a method for governing “investments,” and programs and projects are also “investments.” At MVCI, this meant providing value to the customer in other words, providing value-added services.

So how do programs and projects fit into the concept of Service Portfolio Management? At MVCI, we determined that project management is another IT service offering, following parts of the Transition Planning and Support ITIL process (even though we have not yet aligned to this process), and a program/project is really another type of request for a larger change to an existing IT service or to create a new service. Just like defects, enhancements, urgent changes, etc., a project can be requested through the ITIL support processes, specifically, Change Management. Once a project is approved, it is designed, managed, and deployed during the Service Design and Service Transition phases of the service life cycle. The nonfunctional requirements that need to be incorporated into project plans are also generated in these two life cycle phases. Once a project is “operational,” it is no longer a project, but the capabilities delivered are part of a Service Offering. As part of this theory, the Systems Development Life Cycle (SDLC) processes and activities would need to be considered within the Service Life Cycle to ensure that all project work is considered. Exhibits 2 and 3 show a version of the ITIL V3 model (Pizzo, 2007) versus the customized version of the model we developed to show the integration of project management into the Service Management framework. This was part of our baseline moving forward.

ITIL V3.0 Processes and Functions (Pizzo, 2007, slide 7)

Exhibit 2. ITIL V3.0 Processes and Functions (Pizzo, 2007, slide 7)


Resolving the Problem: Adding New Roles

Next, to expand our vision of ITIL across the IR organization, it became clear a leadership role had to be established. The leader had to understand the Service Management perspective AND the Project Management perspective to transform the entire IR organization into a service delivery organization. We started by implementing the roles of Vice President of Global Service Delivery and Service Line Director. The VP role would lead Service Line Delivery and Project Delivery. Although the two organizations operated separately, having single oversight would be the initial step in bringing the two perspectives together as one. The purpose of the Service Line Director role would be to provide a single point of contact for each Service Line (just as a project manager is the single point of contact for a project). Service Line Directors would be responsible for these:

  • Completion and consistent delivery of the Service Portfolio Management process within their Service Line;
  • Service Partnership Agreements (SPAs) for their assigned Service Line (a section of this document follows the ITIL Service Level Management process);
  • Three-year rolling IT plans for each Service Line, including participation in the development of technology strategy for the IR three-year IT investment plan;
  • Involvement in the Annual Budgeting and Long Range Planning Processes;
  • Leadership in development of the IR Business Service Line, establishing management routines, keeping aware of changing business needs in both IR and the areas of IR Services support, and regular reporting /communication of IR Service Line strategies; and
  • Business Case development and submission for project requests from their Service Line.

MVCI’s three-year rolling IT plans by service line include three categories of work include these:

  • Capital Projects (new functionality-strategically aligned);
  • Expense Projects (software/hardware enhancements, maintenance); and
  • Operational work (upgrades to existing hardware/software, defect repair, ongoing daily routine tuning and maintenance, standard changes).

If a project in the three-year plan needs to move forward, the Service Line Director works with the Service Line business leads to develop the business case for submission to the PMO and eventually to the Technology Executive Committee for approval or denial. In this way, we ensure that the project work originates in the same place as all other IT work: in the Service Line with the Service Line Director in the lead.

This process solved the problem of work origination and submission; however, we were still not approving work from a single pipeline, nor were we prioritizing work outside of the project work. In addition, the operational work continued to be performed separately without oversight outside of the service line.

Our next step was to design the Service Portfolio Management Process for MVCI, while maintaining alignment with ITIL. This work included solidifying the governance structure around submission of all work through a common process and ensuring that strategic planning for future work was continuously reviewed. Steps that were put into place because of this work included the following:

  1. ✓ Annual alignment of all three-year rolling service line IT plans to the corporate Strategy, Long Range Plan, and Budgeting process;
  2. ✓ Determination of new, enhanced, and/or retired services for the coming year as well as operational service improvements;
  3. ✓ Yearly review and update of Service Partnership Agreements (SPAs); and
  4. ✓ Quarterly service line review of three-year rolling service line IT plan (for current year), including progress on work in process;
  5. ✓ Alignment of rolling three-year service line plans with Enterprise IT Investment Plan (quarterly and annually); and
  6. ✓ Submission of Business Cases by Service Lines for technology investments to the Technology Executive Committee.

At this point, we had work coming in centrally through Service Lines and managed by a single executive for continuity; we had a formal governance process for approving and prioritizing projects.


The objectives of deploying Service Portfolio Management as an integration of Project and Service Management would provide MVCI with several benefits:

  • Ability to have a consolidated list of services that Information Resources provides, including projects to change these services, create new services, or retire services;
  • Ability to provide complete transparency of all services;
  • Ability to provide a consistent tracking and management mechanism for all services, which will lead to better strategic planning for the organization as well as more accurate cost management;
  • Ability to better understand when specific services need to be added and others can be retired;
  • Ability to execute only work as it applies to strategic business services;
  • Ability to view and manage capacity of all resources across all IT work; and
  • Ability to better manage overall demand and an on-going forecast.

Next Steps

Demand Planning

At the beginning of 2011, our pipeline of IT work was bursting at the seams, we had the extra burden of the new company structure, we were supporting an exciting new product form, and we were still recovering from the economic turndown, like most other businesses. These events created a new sense of urgency for our organization.

Although we were not a department providing IT products and services directly to the end customer, we faced the same challenges with our internal customers. If we did not manage the internal IT pipeline effectively, the end customer would suffer, leading to the overall negative impact on our business.

Our existing processes required us taking all project work to our Technology Executive Committee for approval, and we realized the executive level of an organization should not need to approve every technology effort. They wanted visibility to the work and preferred that their operational executives deal with the day-to-day work that needed to be approved. We also realized that within Service Portfolio Management, we implemented the handling of all IT work requests but we did not implement the governance in place to handle it. Something was still missing. There was no “objective” governance group to ensure that work coming through was prioritized across service lines to meet the corporate strategy. Individual service lines would naturally be working towards the goals of the individual service line, which sometimes is in conflict with the greater good of the company. Furthermore, we needed to prioritize all work, not just project work, to optimize and balance our resources and ensure efficiencies in our IT pipeline.

We needed to put the governance and management controls in place to regulate a single pipeline of all IT work. We were going from managing at an operational level within the Service Lines to a strategic level with the TEC. There was no linkage between the two to tie our work together into a single pipeline with common resources and a single set of priorities.

We mitigated the linkage issues by implementing “Demand Planning.” ITIL refers to Demand Management as “the activities that understand and influence customer demand for services and the provision of capacity to meet these demands.” To better accommodate our business needs, we implemented a modified Demand Planning process to refer to the demand for IT work and IT’s capacity to fulfill these requests. This would also include putting the governance in place to ensure that work requests were only approved if they were part of our strategic business direction.

By the end of 2010, we had a significant portion of our Service Line Directors in place and a majority of Service Agreements were approved or in process. Part of the Service Line Director’s job is to maintain a pipeline of “demand items” for their Service Line. This is also referred to as the Demand Backlog. These items can be considered the “wish list” for the Service Line and, at a minimum, the top 20 to 30 items on the list require numerical prioritization. This prioritization would be aligned with the overall business strategy or be required in order to comply with various legal or financial regulations.

In late 2010, we started having weekly Demand Planning meetings. These meetings were meant to provide a weekly discussion of priority IT requests, both project and operational, from Service Lines. Out of this meeting came an updated list of IT work that was in process or needed discussion. Work was initiated based on priorities set by this governance group. Over the course of the next several months, the participants and agenda for this meeting were gradually ironed out until we had a successful process for managing our IT pipeline.

The key opportunities that the Demand Planning addresses include (Exhibit 4):

  • Total work demand, centralized and managed against the strategic imperatives and objectives of the enterprise;
  • Organizational shift from assessing requests to driving work that provides maximum benefit in support of the enterprise strategies;
  • Establish, define and link work processes to more effectively and consistently manage how work is navigated through the organization;
  • Provide a centralized technology demand planning capability to balance requests and better forecast and optimize resources capacity—helping bread down organizational silos and avoid unnecessary resources constraints; and
  • Benefits from a high level of process maturity to reduce costs.

The IT Demand Planning cycle promotes collaboration and alignment between all disciplines in the enterprise.

IT demand planning cycle

Exhibit 4. IT demand planning cycle

The purpose of the Demand Planning group is the following:

  • To ratify and establish work request priorities and release plans based on business priority and the IT Investment Plan
  • To challenge and establish the priority of work requests based on benefit, risks and capacity
  • To manage change, conflicts, risks and issues as appropriate
  • To seek approval from TEC for proposed release plans inclusive of business case and funding requests

The participation in the weekly meetings is limited to these:

  • Process Leaders (optional)
  • Service Line Directors
  • IR Leadership
  • Process Subject Matter Experts

Those who participate in the meeting are responsible for following:

  • Representing respective business lines and process areas;
  • Providing specific direction regarding tactical work that aligns with strategic objectives;
  • Mitigating or escalating risks, constraints and conflicts as appropriate;
  • Establishing a recommended technology release plan by IT service;
  • Authorizing/approving recommended technology release plans for TEC/Enterprise;
  • Ensuring approved release plans have approved funding sources; and
  • Providing process oversight and visibility of technology delivery and performance.

Deliverables from the Demand Planning meeting include:

  • Proposed Enterprise Technology Release Plan;
  • List of legitimate and prioritized requests that align with enterprise strategies; and
  • Appropriate supporting business rationale for requests including business problem, benefit and proposed funding source.

In summary, the Demand Planning group operates at a tactical level in the organization (Exhibit 5) allowing the Technology Executive Committee to focus on and drive the strategic needs of the business. Although the TEC still has visibility to all work that comes through the Demand Planning pipeline, they no longer are consumed with planning at the tactical and sometimes operational day-to-day level. The TEC performs strategic duties, Demand Planning fills the gap between strategic alignment and prioritization of all work in the pipeline considered tactical, and the Service Lines themselves perform the operational day-to-day monitoring of their individual pipelines.

While this process is seemingly straightforward and makes business sense, it takes many steps to put it into place; arduous business discussions with all disciplines, agreement on membership levels in the various committees and senior leadership sponsorship are the steps that must take place in order to well establish Demand Planning. Demand Planning is chaired by the Vice President of Global Service Delivery but facilitated by a business leader role.

Strategic, tactical, operational vie

Exhibit 5. Strategic, tactical, operational view

Exhibit 6 explains the weekly process that was used (at a high level) at the peak of our process.

Demand Request Process Flow

Exhibit 6. Demand Request Process Flow

  1. All Demand Requests are submitted via the Service Line Directors (projects, enhancements, defects, urgent changes, etc.).
  2. Service Line Directors bring all submissions to the Demand Planning meeting.
  3. Demand Planning reviews all submissions for strategy alignment and determines one of the following actions:
    1. Approve to develop Rough Order of Magnitude (ROM)
    2. Approve to develop Detailed Estimate
    3. Approve to deploy and slot on Release Schedule (after estimates come back)
    4. Deny Request
  4. If a request for a project exceeds pre-determined thresholds, it must be approved by TEC.
  5. Note: All ROMs and detailed estimates go to the PMO; also, all TEC document preparation goes through the PMO.
  6. The Demand Management Release Plan goes to TEC monthly for visibility, and it is also used to updated the Enterprise three-year IT investment plan.
  7. Demand Planning prioritizes all requests in the Estimating Pipeline and Release Plan across Service Lines and in alignment with the strategy as defined by the TEC.

While we still have work to do, because continuous improvement will always be a road well traveled, we feel that our progress in the Service Management and Project Management areas over the past year and a half has been substantial. Our key accomplishment was communicating the common understanding that IT work does not operate in two distinct methodological disciplines, but rather is an integrated, prioritized effort that must align completely with the overall business strategic direction and priorities.


Another area of improvement is to implement a single repository for all demand requests. Although we use MS Project Server on the project side and Infra on the Service Management side, we do not utilize one automated entry point for all requests. To address this issue, we have created a single entry portal in Infra for all requests, including projects, and we are in the process of getting all data entered in the system. From a project perspective, this will allow us to manage the request process, estimating processes, approval processes, and overall progress in Infra for reporting and tracking purposes, while still utilizing MS Project for project planning and scheduling.

Service Portfolio Management Process Improvement

Of course, now that we have incorporated the Demand Planning process into our Service Portfolio Management process, we will need to formally update the Service Portfolio Management Process along with the development of strategic measures.


The last item on our “To Do” list for 2011 is to ensure that the entire Project Management and Service organizations are trained and certified in ITIL V3.0. As of the writing of this paper, the training is in progress and the certification is scheduled for completion by September 2011. From a project management certification perspective, we are working towards mandatory certification requirements for all program and project managers. While this career path development is still in process, we hope to solidify the results sometime in 2012.

Of course, we also continue to align additional ITIL processes and project management methodologies as well as work to continuously improve those we have in place. We are currently establishing our version of an agile methodology for project development and are continuing to align our next set of ITIL V3.0 processes. With much hard work and our ongoing drive to reshape and rebuild our company, we are planning for new growth and continued success in the service management arena!!!


Office of Government Commerce. (2007). ITIL Service Strategy. Norwich, UK: TSO.

Marriott International, Inc. (2010a). Corporate profile. Retrieved from

Marriott International, Inc. (2010b). Marriott International 2010 Annual Report.

Project Management Institute. (2006). The standard for portfolio management. Newtown Square, PA: Project Management Institute.

Pizzo, K. (2007, June 26) Core Practive Book 5: Continual Service Improvement Retrieved from

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide—Fourth Edition. Newtown Square, PA: Project Management Institute.

© 2010, Marriott Vacation Club International, Tracy Wilson, Stephanie Iverson, Doug Johnson
Originally published as a part of 2011 PMI Global Congress Proceedings – Dallas, Texas, United States



Related Content