Chapter 2: The Project Management Office Business Model

---

Introduction: Revisiting the IT Organization

The opening sections of this book have set the stage for a review of the information technology organization and the arguments for creating a project management office (PMO). In preparing this ground, the author has stressed the central importance of service and project delivery to the value proposition of any information technology organization. But achieving success in these areas is a challenge for most IT teams who are obliged to balance the at-times conflicting and rapidly changing needs and demands of the parent enterprise with responses constrained by limited financial and human resources. To assist the reader in dealing with these complexities, the author offers a toolkit. But this still begs the question, "Who will wield the tools?" The answer will depend on the organizational context of the reader's IT business, the strengths and weaknesses of its players, and the particulars on its to-do list. This chapter explores the various dimensions of the IT organization, service and project delivery roles and responsibilities, and how the project management office might be positioned within this mix.

I have already suggested perspectives, processes, and tools to better position information technology investments within the internal economy of the enterprise. Similarly, I have provided an overview of IT organization day-to-day service operations and project delivery. Besides the actual planning process and its associated documentation, I have recommended the creation of a customer relationship executive (CRE) role, as well as those of the project director, the project manager and the project management office. Introducing these concepts calls for process changes within the IT organization itself, as well as fairly significant alterations in the ways that IT interacts and communicates with its customers and partner providers.

This is a lot to do, and much of it will come as an added burden to already overtaxed IT management. Furthermore, my integrated management perspective, which is focused on the timely delivery of commitments, does not readily fit within the typical roles and responsibilities of an IT operating unit. Bred by a need for attention to detail and the care and feeding of a 24/7 services utility, the mindset of the typical IT team is linear, transaction-based, and heavily siloed. It is therefore not surprising to find that some of these teams are severely challenged in their attempts to function within the more global operating parameters outlined in the opening sections of this book. Established IT structures, business processes, and ways of thinking work to thwart the development of the very cross-functional, business-oriented capabilities and perspectives required to balance this linear, transaction-based mindset.

Consider for a moment a typical but simplified IT reporting structure and how this design reinforces the behavioral characteristics just mentioned. The average IT organization comprises several groupings of professionals clustered around like activities and technologies. There will be an infrastructure team whose responsibilities encompass data-center operations, network administration, server and storage management, production services, and so forth. In many instances, information security, disaster recovery, and contingency planning also fall under this operations group. Another subset of IT personnel may be assigned to customer support, including such services as help desk and call center operations, desktop and audio/visual support, and end-user training and documentation. To complement these teams, IT organizations will also possess a systems organization, in which specially skilled personnel develop, ^[1] maintain, enhance, and support application software for the business. The systems staff may be organized in any number of ways. In large IT shops, each systems complex (e.g., the applications for finance, manufacturing, distribution and logistics, and so forth) may have its own team, further separated into those who develop versus those who maintain and support products. ^[2] Specialized disciplines, such as data management and Web services, may have their own development and maintenance teams. Quality assurance and release management may be embedded in these systems teams, or they may stand as separate IT departments. Lastly, most IT organizations will have some sort of administration and finance function to oversee budgeting, purchasing, human resources management, administrative support, staff development and training, and the like. ^[3] See Exhibit 1.

Exhibit 1: Typical IT Organization Design

It is easy to understand why IT organizations have evolved into the organism described here. The field of information technology is extremely complex, requiring high levels of specialization. To achieve the critical mass of expertise required to run and service an enterprise's technology complex, IT teams usually align themselves according to their technical competencies around particular hardware or software products, information security, customer servicing, and so on. This arrangement makes a lot of sense and generally serves the needs of both the IT organization and its customers.

Unfortunately, there are several less positive aspects to this operational model. First and foremost, it breeds a siloed mentality around service delivery. When organized around particular technologies, IT team members naturally tend to focus on their own technical and service needs and those of their immediate customers, without considering the implications of their actions on other participants along the IT value chain. For example, a network services team may work rapidly to restore a server that has crashed but may fail to communicate the server's failure or its return to service to those application teams that need to take follow-on actions to restore their respective applications. Second, and as a corollary to the first point, highly specialized teams lose sight of what is happening elsewhere in the organization, leading to disconnects in the coordinated planning of deliverables, in the purchase of product, and in the installation of new services. Indeed, how many times have you observed an instance in which a project launch team failed to communicate fundamental hardware, infrastructure, and even facilities requirements to the upstream providers of those capabilities?

Third, when IT personnel work in organizational and mental silos and when a full appreciation of the value chain of IT team activities is missing, IT products and services break more readily. At the very least, they may come to market without having everything necessary in place to ensure customer satisfaction with the deliverables, such as end-user training, documentation, and call center support. Fourth, when things go bad in a siloed environment, finger pointing is rampant. Each work group is confident that it has delivered as required and blames its internal (or external) partner providers for product or service delivery problems. Fifth, given this context, it is difficult to measure and report on end-to-end customer delivery or even to coordinate communications between IT and the customer. From the customer's standpoint, this symptom manifests itself in the need to make many calls across the IT organization to find the right person to address a particular performance issue. Lastly, without a holistic view of IT deliverables it is difficult, if not impossible, to forecast customer needs, to proactively address problems, to allocate resources, and to coordinate IT responses to crises.

How do these aspects of IT organizational design manifest themselves in the real world of IT operations and delivery? Consider the following scenarios. Do they resonate? Have you experienced them yourself, and if so, why?

• Mainframe or a server bank goes down overnight, and the infrastructure team comes in to restore services. The team gets all the computer hardware back online but fails to contact its systems colleagues, who must in turn reboot and reconfigure their applications so that IT's customers can access the services that matter to them. As a result, IT service levels to end customers are severely impacted.

• Through heroic effort, a systems development team brings its product to market on time, only to realize that the team has neglected to purchase enough server hardware for the production instance of the application. Operations indicates that it will now take six to eight weeks to bring the necessary hardware online. The product launch is delayed; systems and operations are angry with one another.

• An application is launched and announced to the community, but the help desk is never notified before the release. End users access the system and experience problems. The help desk is inundated with calls, but without the training and documentation to address user needs, help desk personnel are themselves helpless in this situation. In the end, all of IT looks ill prepared and unprofessional. Again, IT teams play the blame game.

• Customers contact the call center with their IT problem and service requests. Call center personnel log these issues into the organization's problem management system. Unfortunately, there is no consistent practice for problem ticket handoffs or overall process monitoring. As a result, tickets sit in abeyance for weeks on end, leaving customer issues unresolved and customers highly dissatisfied.

• Although the IT leadership has committed to several large and complex projects for delivery within the current fiscal year, the team is understaffed and underskilled to deliver on these commitments. To close this gap, the project teams would like to proceed with the hiring of temporary contractors and the outsourcing of some work. To proceed, however, they must run any contractual arrangements by the legal department and follow the business's hiring and affirmative action procedures. They face months of delays before coming up to appropriate staffing levels. Thus out of the gate, their approved project is seriously behind schedule. The IT leadership is unhappy with the delivery team for underperforming, and the team is unhappy with management for overcommitting.

• IT proudly delivers a new system only to discover that the product was never properly tested and that it cannot scale once placed in a real-world production setting. The team must go to the sponsor for more money and time. Again, IT looks bad in the eyes of the customer.

• IT development team schedules a launch meeting with a key customer. At the final product review, the sponsor and the working clients for the project indicate that the product as delivered does not meet their minimal requirements. Although the customer blames IT for not listening, the fact is that there was no change management process in place. The project must now be restarted with additional resources.

Such scenarios occur commonly within some IT shops, due in part to the lack of coordination and communication among operating unit silos and in part to a breakdown in understanding between the customer and the IT team. To compensate for these process shortfalls, many resort to last-minute heroics to salvage bad situations and turn around misdirected projects. Effective in the short term, such efforts do little to address the dysfunctional behaviors and processes within the IT team and the larger organization. In the long term, they further tarnish the reputation of IT, diminish its perceived value, and contribute to the overburdening of personnel. Last but not least, such experiences waste enterprise resources and make it more difficult to win executive support for the next major IT undertaking.

To close this performance gap, IT organizations could reorganize along cross-functional lines. Unfortunately, this approach carries with it other shortcomings, including the fragmentation of centers of technical competency and excellence and the loss of in-depth staff expertise in critical areas of delivery. Practically speaking, the reason most IT organizations structure themselves around areas of competency (e.g., hardware, software, networking, customer service, and so on) is that this approach makes operational sense. To improve overall results, however, this model requires an added function, one that focuses first and foremost on the process side of IT delivery. This service layer would also concern itself with customer relationship management, the documentation of IT best practices, performance measurement and reporting, and IT staff training and development: in short, a layer that focuses on all of those vital support services that would otherwise fall below the radar screen of the typical, siloed information technology organization.

The Hands-On Project Office therefore recommends an approach whereby a project management office (PMO) is layered into the existing IT organization. As envisioned, the PMO would operate independently of other IT operating units, report directly to the chief information officer (CIO) or some other senior IT executive, and offer a series of support services across IT. See Exhibit 2.

Exhibit 2: An IT Organizational Design Positioning the PMO

The primary focus of the PMO is to oversee the internal coordination of IT service and project delivery. To do this, the PMO would draw upon IT subject-matter experts operating within their respective operational silos. Serving above the fray, the PMO team remains divorced from the parochial interests of individual IT teams while encouraging common best practices, an end-to-end delivery process perspective, and overall better communication within IT teams and between IT teams and their customers and partner providers. To be sure, this is a tough assignment that must balance objectivity and discernment in service and project delivery with respect for the traditions and needs of established IT operating units. A detailed exploration of the character, roles, and responsibilities of the PMO follows. But first, here are a few additional observations about the PMO's positioning within the greater IT organization.

No one in the information technology organization will contemplate the PMO, as described here, with indifference. Some will immediately recognize the potential benefits afforded by its creation, but most will remain suspicious or hostile. From the outset, it is essential to position the PMO as a support organization with the rest of the IT organization as its customer base. The PMO team must exemplify the operating principles and best practices espoused by IT management. More importantly, the team must behave even-handedly in its interactions with project and service delivery teams, appearing consistent in its adherence to operating unit standards while behaving flexibly in light of particular business or technology circumstances. To be sure, the team must sell its ideas and practices to encourage adherence and to avoid policing and blaming. In all instances, the PMO must take the high road in its own use of agreed-upon procedures, setting an exemplary standard for the greater IT team without lording over or overloading that team. ^[4]

At a more substantive level, the PMO should offer support services that might not otherwise be available within the IT organization, such as the administration of planning and budgeting processes, project management and business analysis, benchmarking and performance measurement, customer relationship management, and operational reporting. By offering services that have recognized value but are somewhat neglected by the IT unit today, the PMO may win friends without treading on the territory of other IT departments.

Let the IT management team as a whole define and charter the PMO's scope of activities. This approach will provide the PMO from the outset with a sense of legitimacy and broad-based support. If possible, the office should report to the chief operating or executive officer within the IT organization accountable for customer delivery, and thus, one hopes, without affiliation to any particular IT operating unit. In this manner, the PMO may retain its objective position within IT while carrying the endorsement of the organization's executive leadership. Even so, for the PMO to succeed, it must have the recognition and acknowledged support of IT's rank and file. For this to occur, the office will need to demonstrate valuable contributions to the day-to-day operations of the greater team. Positive results will speak much more loudly than endorsements and policy statements.

Large IT organizations may already have a number of people in PMO-like roles and need only bring them together to create a center of excellence in the disciplines cited. The next two sections of this chapter will itemize the competencies required to staff a PMO in this fashion. However, many smaller IT groups will not have the luxury of a dedicated PMO staff. These teams will need to operate a more virtual PMO, in which individual members of staff, including the CIO himself or herself, take on the roles and responsibilities of the PMO without incurring the added expense of specialized personnel. In fact, IT organizations that have successfully deployed PMOs combine both operational constructs in their business model. On the one hand, they dedicate some of the day-to-day aspects of PMO functionality to a dedicated band of workers, while taking on more ubiquitous activities, such as customer relationship management, reporting, and performance measurement, as general management responsibilities. These they share across the IT management team. What is important here is not how the PMO is structured within IT, but that its service functions are available to the entire organization and that it is recognized as an internal service organization dedicated to raising the quality of the IT organization's service and project delivery.

The remainder of this chapter will explore some of the key roles and responsibilities in IT service and project delivery as these relate to the PMO model. Within this framework, the author will identify where the PMO might best add value in support of the IT organization. I will also provide a more detailed description of PMO roles and a functional business model for PMO operations. Lastly, I will consider the return on investment (ROI) to the information technology organization in establishing and operating a PMO.

^[1]Increasingly, many enterprises are turning to packaged software provided by third-party vendors rather than in-house, home-grown software applications. Although there are always exceptions to this rule and although the uniqueness of certain businesses will sometimes require custom-coded systems, many IT teams today buy their software off the shelf and then work with their vendors (i.e., external partner providers) to adapt these products to the needs of their line-of-business customers.

^[2]No matter the size of your IT organization, keep application development, maintenance, and support for a given product suite within the same team and rotate your people through these various roles and responsibilities. The two primary benefits to this approach are that developers will take greater care in their work if they know they will be saddled with ongoing maintenance of the product, and that sharing the more creative aspects of the work among team members means these same team members will feel less dissatisfaction when they are occasionally assigned more mundane maintenance and support work.

^[3]See The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt2~1~IT Organization~model, for adaptable electronic versions of the IT organization model.

^[4]I must confess that as a PMO director, I have been guilty in the past of overloading my IT colleagues with new processes, procedures, and best practices, many more than they could possibly absorb, digest, and apply at any one time. A word to the wise: focus on those areas that need the most attention and work in small increments, moving from one successful application of process change to the next. Do not assume that your audience has the same capacity for or interest in process change that you may have.

---