The role of IT is rapidly changing, with many organizations seeking to transform the manner in which they design, develop, and manage the provisioning of IT services to customers. In Ten Steps to ITSM Success, we touched on the importance of applying project management principles and practices to ITSM transformation efforts. In this article, we’ll explore that topic in greater detail and explain why project management is imperative to ITSM success.
In our consulting practice, we’re typically asked why we feel that the application of project management principles is so important. Project management, we’re often told, is more applicable to complex, long-term endeavors—ones with defined start and end dates. Projects are temporary endeavors. ITSM, on the other hand, is a never-ending cycle of implementation, refinement, and change.
If viewed from an academic point of view, there’s some validity to this argument. But organizations don’t exist in the abstract. They exist in the real world, and undertakings as challenging and transformative as ITSM demand a methodology that is well proven and rigorous in its application. The Project Management Body of Knowledge (PMBOK) states that project management is the application of knowledge, skills, tools, and techniques to activities to meet project requirements. Structured project management is the answer to that most-frequently asked question: How can we ensure ITSM transformation success?
Aligning the Lifecycles
In our experience, the four phases of the project management lifecycle—initiation, planning, execution, and closing—align closely with the ITSM lifecycle—strategy, design, transition, and operation. While the detailed activities of the project manager and ITSM staff will evolve within each phase, each party has a particular set of responsibilities that must be carried out.
The flow chart below, based on a client’s implementation, illustrates how the ITSM and project management lifecycles can and should support one another.
The lifecycles phases on the left side of the flowchart should be read from top to bottom. This is the accepted way of moving through each lifecycle, and in our opinion, there’s no valid reason to modify the approach. The high-level activities correspond with the phases in which they naturally occur. Project close activities occur only after Operations has formally accepted the new feature. (The operation phase of the ITSM lifecycle has been omitted from the flow chart, as it’s not germane to the discussion at hand. Likewise, change management, portfolio management, and release and deployment management processes are beyond the scope of this article and are not shown.)
In our example, placing a new service or piece of enhanced functionality into production begins with the service strategy manager. Whatever your organization calls this individual or group, this is the hopper into which all notional requirements are placed. Once received, the strategy manager is responsible for entering the request into the tracking system, giving it a distinctive identifier, placing it into the queue for initial assessment, and assembling the right mix of personnel—the tiger team—to make that initial assessment. The strategy manager is then responsible for approving or denying requests based on the team’s preliminary analysis and recommendations.
It should be noted that a project manager is typically called in to participate in the initial assessment. He or she is tasked with providing a rough order of magnitude (ROM) and estimating an approximate level of effort. The project manager is also responsible for ascertaining potential risks and identifying known constraints. These factors, together with architectural (Is this in line with our technical road map? Is it technically feasible?), security (Will this violate existing protocols?), and financial (Are funds available? Are sustainment costs reasonable?) assessments, comprise the contents of the business case analysis presented to the strategy manager.
The activities in steps 1–3 of the flowchart cover the strategy phase of the ITSM lifecycle, as well as the initiation phase of the project management lifecycle. Step 4 is a decision point. Does the organization give its “thumbs-up” or “thumbs-down”? If the requirement is approved, the now fully-vetted requirement moves into the next phases of the two lifecycles: service design and project planning.
Step 5 is where the value of a good project manager, applying project management practices, becomes apparent. Based upon the analysis prepared by the tiger team, the project manager can calculate the number and types of resources required to successfully bring the project to fruition. They can further refine the preliminary cost and duration estimates. Most importantly, the project manager can lay out the critical path.
ITSM processes work together to enable and support IT service provisioning. Depending upon the planned functionality or service your project is chartered to deliver, any number of processes could ultimately support it once it’s in production. As any ITSM practitioner can tell you, the output of one process is typically the input to another. Trained to understand how all the components of a project fit together, they’re the best qualified to manage dependence complexities and point out potential bottlenecks and obstacles in the ITSM transformation effort. The project planning effort includes mapping out these dependencies against the project management plan. Doing so will identify key stakeholders and highlight areas where roadblocks or bottlenecks may occur. Armed with this information, the project manager can notify team members of their assigned activities and alert participants to the project’s critical path, timeline, and expected deliverables. Superior project managers will also note all factors critical to the success of the initiative.
With these first seven activities completed, the project moves from the planning phase into the execution phase. Not coincidentally, this parallels the transition from strategy to design in the ITSM lifecycle.
The execution phase of the project management lifecycle spans the design and transition phases of the ITSM lifecycle. This confluence of activities enables organizations to reap the benefit of project management administration and oversight while executing the design and transition of an ITSM implementation.
In our example, four major activities comprise the design phase of the ITSM lifecycle: preparing the request for change (RFC), as part of the change management process; conducting design and execution activities; executing the portfolio management process; and completing the systems engineering process. The last two activities—portfolio management and systems engineering—are activities unique to our client. We’ve included them here to illustrate how essential project management is to making it through these two gates. In our environment, both of these design activities are mandatory. No service or functionality—no matter how inconsequential—enters production until approval from their respective owners is obtained. The project manager ensures that all essential tasks and paperwork for each process activity are completed.
Our client’s portfolio management process, for example, is a comprehensive integration of the new service into the overall portfolio. In this process, the client examines the entire portfolio of services, performs a rigorous cost/benefit analysis focused on ensuring the new service will meet the established return on investment (ROI) parameters, and, if necessary, rebalances the allocation of available funds across the portfolio. This activity, made up of roughly fourteen tasks, is an indispensable part of our client’s process for introducing a new service into the environment. Your organization may not have an activity this rigorous, and, in fact, it may not conduct this type of exercise at all. That’s not important. The key is that crucial activities are accounted for, planned for accordingly, and properly overseen to provide assurance that the project has passed through all pertinent “gates.” ITSM staff skilled in developing and producing repeatable processes may not understand the significance or nuance involved in the portfolio management or systems engineering processes, but a well-trained, well-informed project manager will.
It’s essential to note that the project manager in our example will see that all relevant paperwork and signatures are obtained. This is especially critical when preparing to enter the transition phase of the ITSM lifecycle. Once the systems engineering process is complete, the RFC is then submitted to the enterprise change and configuration board (ECCB). Despite all the time, money, and effort thus far expended on the proposed service or capability, the ECCB still has the option to reject the RFC if, in the board’s opinion, the risk of implementing the change is greater than its perceived benefit. The reasons for rejection are myriad, but the most common reason is uncertainty about whether the project has passed through all the applicable gates. This is especially true when the service entails a change to the enterprise architecture. Without assurance from the project manager that all systems engineering tasks have been performed, the board is well within its rights to reject the RFC and stop the project in its tracks. Believe us when we say that you don’t want to be the unfortunate soul who’s called on the carpet to explain why critical checkpoints were missed. Preventing occurrences like this from happening is yet another reason to follow good project management principles.
Our example doesn’t detail any of the activities necessary to formally close out the project, but these activities are essential to ensuring that the new service or capability is well supported and can deliver its expected benefits. The governing project plan, if properly constructed, should have the complete list of activities and tasks necessary to effectuate a seamless, trouble-free evolution from design to transition. Operations staff must be trained in the day-to-day operation of the new service and become intimately familiar with its unique maintenance or troubleshooting procedures. Operations staff must also know how underpinning processes and communication services facilitate (or interfere) with the new service’s flow of data and information. Backup, restoration, and retention of the service’s data are other aspects of the service’s operation that must be communicated to support personnel. The feedback mechanism in the service asset and configuration management and change management processes should be inherent to the respective processes, but it doesn’t hurt (and may be beneficial) to have those “tie up the loose end” activities noted in the project plan to ensure they’re completed.
In addition to the close-out activities endemic to the ITSM lifecycle, there are also close-out activities the project manager will perform as part of the project management lifecycle. Among other things, this includes conducting a postmortem analysis, documenting the lessons learned, preparing and submitting the final budget figures to the business sponsor, and releasing the project team members back to their day-to-day responsibilities.
None of these activities happen by themselves. They’re only executed under the administration of a diligent project manager. This is the person, acting as conductor, who carefully orchestrates all the separate moving parts to form one unified and cohesive whole.
Developing an Integrated Model
In order to make all of this work, we recommend investing in the development of an integrated model. An integrated model enumerates the touchpoints and dependencies between the ITSM lifecycle, the project management lifecycle, and the key organizational capabilities that enable managers and staff to provision services and execute projects in a standardized and repeatable manner.
The figure below depicts a high-level example of a layered model. The top layer represents the ITSM lifecycle, consisting of the myriad processes and activities required to provision IT services to customers. The middle layer represents the project management lifecycle, which supports the achievement of ITSM objectives by executing the defined processes and activities required to develop a new or changed product or service. Finally, the bottom layer represents the key organizational capabilities that must be in place to enable and support consistent execution of both ITSM and project management activities.
While the relationship between the top two layers is the primary focus of this article, the bottom layer is critically important. In our client’s environment, these capabilities include an agreed-upon and documented governance model, a set of controlling activities, and an established continual improvement practice. These may differ somewhat for your organization, but in working with many organizations across many industries, we’ve found these are inevitable variations on a theme. A word to the wise: Define these in the manner best suited for your organization, but ignore them at your peril.
It’s well-known that many IT programs fail due to poor requirements management. However, this failure is often a symptom of an underlying inability of key organizational stakeholders to agree on desired outcomes. This is where governance comes in. Governance—and its components (e.g., decision rights, audit controls, assurance practices)—is so critical to ITSM and project management success that it should be viewed as its own lifecycle process. Governance works best when there’s a single, transparent reporting relationship from a program manager to an oversight (program-level) governance board. The function of the governance board is not to usurp the authority of the program manager, but rather to provide an empowered stakeholder forum for raising important issues and making trade-off decisions.
Given compressed timelines and the widespread use of Agile methodologies, the governance board should meet biweekly (at a minimum, monthly) to enforce accountability and foster transparency. Whenever possible, decisions should be consensus-driven and not reduced to a vote-counting exercise. If consensus can’t be reached on a key decision, it should be escalated to the next highest level, possibly an IT steering committee or investment review board. This action should be rare; in an organization with mature governance, boards will force themselves to make the tough decisions.
Controlling activities and continual improvement practices are important pieces of governance that directly influence ITSM and project management outcomes. Both the PMBOK and the COBIT framework strongly emphasize the need to define appropriate controls for your environment and to systematically evaluate, direct, and monitor those control activities to ensure that organizational objectives are being achieved. Likewise, various frameworks and standards, such as ITIL and ISO/IEC 20000, recommend establishing a standardized, data-driven, cross-organizational approach to continual improvement, using tools like CSI Register to identify and analyze ITSM opportunities and prioritize, approve, and fund specific project management initiatives.
Conclusion
In response to budget pressures, strategic competition, and advancements in technology (e.g., the cloud, virtualization, mobility), the traditional role of the IT organization is changing. The emergence of new models of IT—service broker, service integrator, service innovator, etc.—is leading many organizations to transform how they design and deliver IT services to their customers. Yet many organizations fail to achieve their ITSM transformation objectives. In our experience, project management principles and practices are the missing ingredient.
In this article, we’ve provided a framework for aligning the project management and ITSM lifecycles, taking advantage of natural synergies and complementary processes and roles. We’ve also discussed the importance of developing an integrated model that draws support from key enabling capabilities, such as good governance and control practices. Taken together, this approach—used wisely and with proper oversight—will go a long way toward executing a transparent and cost-effective ITSM implementation, regardless of size or budget.
Angelo Esposito, a program manager with Jacobs Technology, is currently advising the US Navy on its enterprise ITSM transformation initiative. A former CIO with more than twenty-five years of experience, Angelo’s worked in the commercial, nonprofit, and government sectors, and he holds certifications in ITIL, IS auditing and management, and governance.
Tim Rogers is an ITSM consultant at Booz Allen Hamilton, where he specializes in enterprise service management, governance, and continual improvement. A former CTO with more than fifteen years of experience, he’s worked with high-tech startups, financial services firms, and large government clients. Tim holds certifications in ITIL, ISO, and Lean Six Sigma, and he currently serves on the board for the San Diego LIG and the itSMF USA social media team.
Angelo and Tim are the coauthors of Ten Steps to ITSM Success: A Practitioner’s Guide to Enterprise IT Transformation (2013).