Managing an ITIL SaaS implementation IT program
a case study
The case study “Managing an ITIL SaaS Implementation IT Program” provides insight into the management of multi-year MSP-programs. Techniques will be shown on how to manage the dynamic complexity of such programs, and how to set up and run in parallel running projects with pre-defined feedback loops to control scope, time, and budget. This paper describes activities carried out during program initiation, program setup, delivery of program benefits, and program closure. On the project-level, activities are described for concept, design, build, and operate SaaS services. This paper concludes that building feedback loops on program and project levels will help to obtain program benefits in a controlled way.
Dynamic complexity is seen by researchers in the project management field as one of the primary causes of project failure. This is especially true for large IT programs with durations of several years. This case study shows how system dynamics of large-scale programs can be managed by setting up feedback loops to preserve program benefits. We investigate in detail the processes, tools, and techniques used in a complex multi-year ITIL SaaS implementation IT program. Interested program managers may adopt these techniques into their own engagements. During the program life cycle, new projects will constantly start within the program. Many projects will also run in parallel with other projects sharing the majority of the project team and using the same shared infrastructure resources. We will look at techniques used to repeatedly generate projects out of the program and how this can be done in an efficient and simplified way based on scope statement and project plan templates. Shared human and infrastructure resources are managed in weekly plans, which impose visible resource constraints on parallel running projects. Project managers of the program monitor the progress and budgets of their projects with pre-defined feedback loops by using, on one hand, the percent complete figure inserted into the project plan and, on the other hand, the actual hours submitted on timesheets from each assigned resource of tasks. With this information, an estimate to complete is calculated on a weekly basis to give an early warning about a deviation from the plan with regard to schedule, efforts, or budget. The presentation concludes with a monthly bird's-eye look at the whole program using accumulated KPIs over all projects compared to the initial plans and budget of the program.
According to The Standard for Program Management (PMI, 2008a, Chapter 1.2, “What is a Program,” Kindle location 1103), “A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.”
This paper is about the experiences of the author gained through managing an ITIL SaaS implementation IT program. IT program management is the process of the management of several related IT projects to obtain the defined utility to the business of the customer. In our case, the target of such a program is to build a shared IT software environment, which is used by more than one end customer as a support tool for several ITIL processes, such as incident or problem management. The customer is providing these services as Software as a Service (SaaS), and the end customers are interacting with their instance or tenant through the web browser or via email. The SaaS environment provides tool support for one or more ITIL processes for one or more end customers. The hosting infrastructure environment is operated by the customer as an SaaS solution (Wikipedia, 2012a) for their end customers accessing this shared environment. After the shared infrastructure environment was built and set up for the first customer who was onboarded as a tenant of the multi-tenanted system, more SaaS customers are added to the same shared environment. To avoid disruption of already productive tenants, this environment consists of the production (PROD) environment of an architecturally identical (DEV) and testing (QA) environment. Activities, changes, and maintenance on any of the environments are managed through a weekly rolling plan. It is a special task schedule to avoid productive outages of already productive tenants during on-boarding of new tenants. (For a detailed description of this, see Exhibit 11.)
This paper shows the processes and techniques of ten projects and how they could be managed in “green state” with regard to the criteria of schedule, budget, scope, and resources (see Exhibit 5).
The Importance of Feedback Loops in Dynamic Systems
According to the ITIL strategy book (Taylor, Iqbal, & Nieves, 2007, p 23), IT organizations can be visualized as dynamic systems with functions and processes. Each process or function can provide to each other feedback toward the goal of meeting the customer objectives. Any delay in negative feedback toward the goal may lead to oscillations in this dynamic system due to intervening corrections. In the end, any delay may have a destabilizing effect on the system. Feedback loops in the forms of reporting and improved measurements can reduce this destabilizing effect.
Grösser (2011) sees the reason for many unsuccessful projects in unmanaged dynamic complexity.
The implementation of a sufficient number of feedback loops is especially important for programs because it involves multiple projects, where each project can be seen as a dynamic system interacting with other projects, with the program itself, with the IT organization, and with the business of the customer.
On the other hand, the effort for program and project managers to define and regularly evaluate feedback loops has to be considered. Probably one of the most challenging tasks for the program manager is to select the correct types and number of feedback loops so that, on one hand, the program is not destabilized; on the other hand, the administrative effort for maintaining feedback loops is in an acceptable range.
General Information about the ITIL SaaS IT Implementation Program
We want to give you a brief general description about the program.
Setup of the Program
The program was set up with a predefined budget and number of days. The size of the program is determined by the sizes of the projects in the pipeline. Additionally, there is a split of the effort among different project roles, such as the project manager, senior consultant, offshore delivery, and architect. According to the planned effort per role, the total program contract value can be calculated.
The project pipeline is defined in a table and lists on the one side all planned projects and on the other side the monthly expected effort. This baseline planning sheet is used to compare it with past project months and the updated project pipeline (see Exhibit 5).
Setup of Projects within the Program
All work performed needs a formal request and approval to set up a new program within the program. Each project requires a detailed work breakdown structure (WBS) and a reviewed estimate by at least one architect. The project manager builds a Microsoft Project plan with a detailed set of tasks, assigns resources; adds dependencies between tasks; adds non-availability in the project team calendar; and verifies that the estimated effort is matching the total work of the plan. After everything is defined, it is important that the project manager schedule a final meeting to walk through all work packages, assumptions, and all documents in a final review meeting. Any changes in any of the defined documents need to be clarified between the supplier and the customer.
Early detection of any cost or effort overruns
Project progress is updated weekly by the project manager by a walkthrough of all tasks to be performed with each assigned project member. Each member is asked about the percentage work complete figure of his or her assigned tasks, which is then updated in the project schedule.
In the resource view of the project plan, actual and remaining work for each task is shown. Additionally, actual work performed by each consultant is collected from weekly timesheets. With this information, the expected total effort and total costs of the project are calculated by using the spreadsheet shown in Exhibit 10. This process is repeated by each project manager for each active project at least on a weekly basis. This indicator delivers an early warning for a possible effort and budget overrun. For IT programs, efforts and budgets are of extreme importance, because the customer is expecting cost savings through the implementation of the program. Often the program benefits are lost if this indicator is ignored and cost overruns occur.
This approach also allows a better detection of scope changes or additional work packages that aren't part of the existing project plan. Whenever this happens, a new change request will be added to the change request register, which then will be analyzed, described, and discussed with the customer if and when it makes sense to be implemented.
It is important to deliver early and regularly benefits to the program. In our program, it is important to reach at least every month a milestone that becomes visible to the business. Good examples are the onboarding and go-live of new tenants (end-customers) into the shared environment and the enrichment of supported ITIL processes, as well as the extension of base functionality (i.e., to add single sign-on and federation for the end-customer to avoid user/password logins in the shared service desk environment).
The implementation of our SaaS environment is based on the concept of the ITIL Service Life Cycle: “Service Design, Service Transition, and Service Operation are progressive phases of the Life Cycle, which represent change and rransformation. Service Strategy represents policies and objectives. Continual Service Improvement represents learning and improvement. Service Strategy (SS) is the axis around which the life cycle rotates. Service Design (SD), Service Transition (ST), and Service Operation (SO) implement strategy. Continual Service Improvement (CSI) helps place and prioritize improvement programs and projects based on strategic objectives.” (Taylor, Iqbal, Nieves, 2007, p 24)
Exhibit 1 illustrates this concept. Program managers interested in ITIL should read the complete ITIL 3-volume book set: Service Design (Lloyd, Rudd, Taylor, 2007), Service Transition (Lacy, MacFarlane, Taylor, 2007), Service Operation (Cannon, Wheeldon, Taylor, 2007), and Continual Service Improvement (Case, Spalding, Taylor, 2007).
This section presents examples that implement feedback loops. These examples show the techniques and tools that have been used in our program and how you, as an interested program manager, might adopt these into your engagement. Please note that for nondisclosure reasons, the numbers shown in the tables are random.
For the success of the program, it is important to introduce a set of feedback loops that are regularly evaluated to see if benefits of the program are achieved and if all projects are in scope, time, and budget.
We distinguish between feedback loops on the program and project levels. If possible, we also like to have more than one view to the same indicator to see if the calculations behind them are correct.
Program Level Feedback Loops
On the program level, it is important to see the status of the whole program and its projects at a glance. This paper will present two views: A bottom-up view from the project level and a top-down view from the program level.
- Bird's eye view to the program with bottom-up reported project information
This view shows the current resource consumption and financial status for each project. Because of space limitations in this paper, Exhibit 2 shows a region of that view — the status of project “Tenant1.” In column F, the estimated hours per role are shown. Column G allows for additional planned efforts coming from change requests (CRs). The total hours in column E are the sum of the corresponding cells in columns F and G. Available hours in column D are the difference between columns E and B. Actual hours in column B are the sum of hours automatically calculated from a tab containing timesheet raw data of all projects of the program. Monthly project revenue in columns I through M is automatically calculated based on the timesheet raw data.
The status of further projects of the program is listed on the same sheet, in the same format, using the same formulas and the same timesheet raw data.
Timesheet raw data are shown in Exhibit 3, whereas only the name, date, project, and hours need to be entered. All other information is calculated with formulas and used for the project status view. These data are the basis for all reports in this view.
The status of the program shown in Exhibit 4 is aggregated from all projects. Actual, available, and total numbers are shown in hours as well as financial values.
- Bird's-eye view on the program level: Actual reported effort versus initial program setup planned effort per month. For future months, the project pipeline is updated and compared with the initial plan.
This view gives quite good status information about the program by using monthly accumulated work in days. The screen shot in Exhibit 5 shows the program status as of 31 March 2012.
The top of the spreadsheet shows planned projects and the distribution of the effort during the duration of the program. The numbers in this view remain the same from report to report.
The bottom of the spreadsheet shows the current status. There is an overlaid transparent box between 08/11 and 03/12. The numbers within this range are the actual performed work per month and per project. Efforts with a date from 04/12 show the actual project pipeline. Please note that the pipeline in the screenshot is the same as during draft planning. In reality, one can expect that the pipeline, the list of projects, and the order of execution of the projects will change over time and will be different than the initial plan.
For the steering committee, three key indicators are important:
- Draft/planned versus actual total days per each month
- Draft/planned versus actual accumulated total days
- Draft/planned versus actual average heads
One goal of the program could be that the accumulated days per month between the initial plan and the actuals should be more or less the same. If there are less actual accumulated days consumed, the steering committee might decide to start additional projects and vice versa.
- Traffic light status overview for each project
The traffic light report as shown in Exhibit 5 is commonly used to report the program status at the steering committee meetings and shows all projects of the program categorized into ongoing, finished, and new projects. To avoid discussions about the color of each status, it is recommended to agree on common reporting categories. In our program, we use the reporting categories Schedule, Budget, Scope, and Resources, as shown in Exhibit 6.
Project Level Feedback Loops
- Estimated final project effort in person-days and estimated final project costs
To successfully manage projects, it is important to first set up the project, including the WBS, reviewed effort estimation, task sequencing, resource assignments, and leveling.
During project execution it is important to set up a feedback loop to enable an estimate to complete.
In our project, we define a project plan that corresponds to the estimated work effort in the statement of work. All our plans use several resources, such as project manager, architect, and senior consultant. We extract the estimated effort from the project plan into the first column “Estimated MD.” Should there be any change request, then we add these efforts to this number, because an approved change request is in the scope of the project.
At the weekly project status meetings, project members assigned to a task are asked about their estimates on the percent work complete (i.e., 0%, 50%, 100% complete). The project manager updates these values for all tasks in the project plan. In the resource view, the “Actual Work” and “Remaining Work” can be seen and copied into the estimate to complete Excel spreadsheet (see Exhibit 8).
Also, on a weekly basis, all project members submit their timesheets with actual hours worked for each task. This effort value is entered into the column “Actual work performed.” By subtracting this work effort from the estimated effort, we get the available person-days that are available on that contract to be used (see Exhibit 9).
Finally, an estimate to complete can be calculated using the previously collected data. Available person-days or an overrun will be shown per resource role. Adding hourly rates for each role also allows for the calculation of cost savings or cost overruns when the project is finished. In the example shown in Exhibit 10, it is possible to have an overrun with regard to the person-days, whereas the financials show available buffer. The explanation for this is that in this example there was a shift of architect work to the cheaper offshore delivery team.
It is important to re-evaluate these numbers and communicate the status per role to all team members on a weekly basis. As the project manager you should give each team member feedback if the efforts he or she is generating are in line with the plan or not. For the project manager, any significant deviation in the estimate complete should be used to start further investigations into how this deviation can be explained.
- Human, hardware, and other shared resources rolling plan
Implementing a shared hardware and software environment requires a more detailed planning of human, hardware, and software resources.
Exhibit 11 shows a weekly rolling plan for project “Tenant1” and project “Tenant2.” Both projects run during this week in parallel. The rolling plan shows that for “Tenant1” there is only design work planned, which does not need any shared resource. For “Tenant 2,” there is a move to QA environment planned where the DEV and QA environments are used.
The complete workbook contains a set of tabs showing the rolling plan for the whole program duration.
Templates for the Generation of New Projects within the Program
Scope statement templates
For the program, it is important to define a simple formal process for the definition of new projects. A new project SOW should refer to the terms and conditions of the program. In other words, the SOW could exist only of the scope statement and it could be contracted via email to minimize administration effort. For requesting new projects, the customer should use a template to create formal requests defining the goals and requirements.
Project plan templates
In our program, project plans are an important planning and feedback tool. It is important to pre-define phases like the creation of design documents, user acceptance testing, and go-live.
Documentation structure of the program
For the program, a document management system is used to store and manage all program-related documents. It is a system that is accessible over the Internet for all project members: supplier, customer, and vendors. For each folder, special permissions were set up to restrict access between members of the program.
The directory structure as shown in the table in Exhibit 12 is used for the program on the program level, and the directory structure shown in Exhibit 13 is used on the project level.
Conclusion and Future Work
By using feedback loops, the dynamic complexity of our ITIL SaaS Implementation IT program could be successfully controlled in an efficient way. We plan to create general work templates, which will include all needed formulas and macros and make these available to interested project and program managers.
Cannon, D., Wheeldon, D., & Taylor, S. (2007). Service Operation; TSO (The Stationery Office). Published for the Office of Government Commerce (OGC).
Case, G., Spalding, G., & Taylor, S. (2007). Continual Service Improvement; TSO (The Stationery Office). Published for the Office of Government Commerce (OGC).
Grösser, S. N. (2011). Projekte scheitern wegen dynamischer Komplexität: Qualitative Feedbackmodellierung zur Komplexitätsbewältigung. Projektmanagement Aktuell, 22(5), 18–25.
Lacy, S., MacFarlane, I., & Taylor, S. (2007). Service Transition; TSO (The Stationery Office). Published for the Office of Government Commerce (OGC).
Lloyd, V., Rudd, C., & Taylor, S. (2007). Service Design; TSO (The Stationery Office). Published for the Office of Government Commerce (OGC).
Project Management Institute. (2008a). The standard for program management—Second edition. Newtown Square, PA: Author.
Project Management Institute. (2008b). A guide to the project management body of knowledge (PMBOK® Guide)—Fourth edition. Newtown Square, PA: Author.
Taylor, S., Iqbal, M., & Nieves, M. (2007): Service Strategy; TSO (The Stationery Office). Published for the Office of Government Commerce (OGC).
Wikipedia (2012a). Software as a service. Retrieved from http://en.wikipedia.org/wiki/Software_as_a_Service
© 2012, Gottfried Rudorfer
Originally published as a part of 2012 PMI Global Congress Proceedings – Vancouver, Canada