Service Management Is Dead

“Service Management is dead.”

That was my first thought when I read McKinsey Querterly’s “Capturing value from IT infrastructure innovation” from October 2012.

That was going to be the point of this blog post.

Then I read it again.

Conclusion 1: Innovation is more than just technology.

Conclusion 3: The path to end-user productivity is still evolving.

Conclusion 5: Proactive Engagement with the business is required.

Conclusion 6: Getting the right talent is increasingly critical

Conclusion 7: Vendor relationships must focus on innovation.

Getting the most from IT infrastructure has never been about technology (though technology is an important capability of IT). Innovating, maximizing productivity, and managing complexity evokes the mundane, at the expense of sexy.

It engages users.

It demands service.

It depends on process and automation.

It focuses on data and knowledge.

It understands and balances the needs of all stakeholders.

Technology is fun. Where technologists hang out are fun places to be. I know this may sound strange to those outside the industry, but the people who move technology are fascinating.

The most boring business events involve Project Managers and Risk and Compliance Officers. I have been to many meetings, and they are yawners, even for me.

That’s because project managers and auditors focus on the boring stuff.

Who are the stakeholders?

Who makes what decisions?

What do they want?

What kind of data do we have?

What kind of data we need?

Where is the data?

How do we use the data most effectively?

What are the risks, and how do we mitigate them?

Yawn.

For better or worse, this is the stuff that underpins business value; the foundation on which innovation is built.

Long live Service Management.

Killing IT Projects (Dead or Alive)

About 10 years ago I was the infrastructure manager for the Tokyo branch of global financial firm. I was involved with 2 projects that had gone wrong.

Project A was an initiative to pull some additional analysis and data from a well-known market data provider. The vendor was unresponsive, even though the project was as much in their interest as ours. The requirements were growing more complex by the day. Overnight the vendor rolled out some new code unannounced that broke our test system. The next day we pulled the plug.

Project B was an ERP system that was to be rolled out globally, to a bunch of independently-managed and funded IT departments. It contained no features or functionality that our users wanted. The global project “manager”, himself a last-minute transplant, announced a minor milestone the day it was due. I asked for a project plan and received an amorphous blob of unintelligible requirements. We tried to comply with their requests for a while, but none of our local users were helping us. I heard tales of the project well after I left.

Project B had too many issues to discuss. There are two I would like to mention here, in the context of both projects A and B. Both concepts are strait from the PRINCE2 method. Let’s start with RACI, an acronym for:

R = Responsible: one or more parties who carry out the work

A = Accountable: one party who is accountable for all activities

C = Consulted: zero or more parties (other than R or A) who may also be consulted on the task, or alternatively on the planning of the task in a process

I = Informed: zero or more parties who may be informed of the results of the task, or alternatively may be informed via reporting of the outputs of the process that performs that task

PRINCE2 is very clear on the accountable party, called the Project Sponsor. The Sponsor is one person (not group, not committee) who owns the Business Case, and who can allocate resources as necessary to achieve the Business Case.

The second concept is the Business Case. It is qualitative and quantitative descriptions of the benefits to be achieved by the project. It is a living, breathing document that is updated throughout the project, more specifically between each phase. Every phase contains a go/no-go decision based on the business case.

In my examples above, Project A had a clear sponsor who understood the business case (as far as I know the business case was never documented, but it may have been). When requirements escalated, and the relationship with the vendor’s project team soured, the sponsor pulled the plug. It was an easy decision, and none of the project participants were tainted. It wasn’t a particularly eventful day.

Project B had no individual sponsor. The sponsor was a committee with a broadly defined goal to improve transparency and accountability. There was no business case, for the organization as a whole or for the individual offices (the latter is a governance issue). The project died a long, slow death, but I am absolutely sure it died. Lacking a sponsor or business case, it should never have started in the first place.

Dying projects should be killed. No remorse. No finger-pointing. No false gestures of “accountability” only meant to take down political enemies (or cover up incompetence). Project requirements change, especially in IT projects. The external environment changes. These affect the business case. If the business case no longer warrants further expenditures, the project should be killed. There is no shame.

In fact I would reward the project sponsors who kill the most projects for lack of business case. If they save $200,000 in bungled projects, they deserve a $20,000 vacation package. On the company. Most IT departments would agree they deserve it.

McKinsey on Automating Service Operations

Good article from McKinsey about automating customer service with IT. Some key takeaways: make pilots, do field tests,  don’t over-plan or over-build, and try to change processes and mindsets in conjunction with the technology roll out. These are common recommendations in consultant circles, but it illustrates with some good and original examples. Plus here is a new one (for me): new applications allow for full-scale simulations of business process changes. Cool stuff that might warrant some additional research.

http://www.mckinseyquarterly.com/A_better_way_to_automate_service_operations_2648

Project Management Systems: Moving Project Management From an Operational to a Strategic Discipline

Abstract: This article illustrates one aspect of the concept of “fit” between an organization’s implementation of project management and its organizational context by exploring how the underlying drivers of an organization’s strategy might influence not only the nature of the projects that it undertakes, but also the appropriateness of the arrangements that it makes to manage those projects. Using a model conceptualized from the literature on strategic management, an analysis of four organizations that have made significant investments in project management over the past 5 years supports the hypothesis that the degree of “fit” between an organization’s strategic drivers of value and the configuration of its project management system influences the value it obtains from project management.

Reference: Project Management Journal, March 2009, Volume 40, Number 1

Authors: Terence J. Cooke-Davies, Lynn H. Crawford, Thomas G. Lechler

Link: http://doi.wiley.com/10.1002/pmj.20106

This article, though primarily theoretical, is nevertheless fascinating. The primary purpose is to explore the extent to which value is created or destroyed depending on the level of “fit” or “misfit” between the organization’s Project Management System (or PMS) and its strategic drivers of value. In order to get there, they explore each topic.

A PMS is defined as system of management structures, standards, and procedures. The characteristics of a PMS are grouped, as derived from the previous work “Value of Project Management (Thomas & Mullaly, 2008), into 4 groups: Policy, People, Structure, and Processes. Strategic drivers are derived from Porter’s (1985) work and are hereby simplified into two axes: the degree to which differentiation is required, and the need to improve process efficiency in order to create a quadrant:

Context 1: Low process economics driver, low differentiation driver (ad hoc)

Context 2: High process economics driver, low differentiation driver (classic project management)

Context 3: Low process economics driver, high differentiation driver (innovation)

Context 4: High process economics driver, high differentiation driver (entrepreneurship, intrapreneurship)

I have to admit that context 4 was most interesting to me, not the least because the word “intrapreneurship” was new to me. Project managers in organizations in this context need to act like business leaders, and need to be empowered to be entrepreneurial in exploiting market opportunities. The paper claims this is not easily done, and in fact I have known only a couple project managers who were successful in this context, and they were not generally popular with their subordinates. An important source of tension is (it is better to quote here):

Firms need both diversity and structure so that there is an inevitable tension between individual initiative and corporate attempts to impose uniformity

Well said. The paper raises more questions than answers, and although it discusses 4 specific firms within their respective strategic contexts, it does not seriously answer many questions about what specific PMS characteristics are suitable to organizations in each quadrant. Nevertheless the paper is an interesting read.

Exploring the Role of Steering Committees in Realizing Value From Project Management

Abstract: The impact of steering committees on project performance and their role in creating value from project management capabilities is not well understood. A case study analysis was chosen to analyze the configurations and specific functions of project steering committees. A measurement model for steering committee configurations was developed to enable further survey-based studies. One of the major insights resulting from the authors’ interviews with project managers and senior managers was that they perceived the existence of a project steering committee only when the context was defined and clarified. Furthermore, a large variety of committee involvements was identified, concluding that steering committees per se are very rare. On the project level, the cases clearly demonstrate that committees with project steering functions play an important role in the selection, initiation, definition, and control of projects. On the organizational level, they are important to implement and maintain project management standards. Finally, the results clearly indicate that steering committees directly support project success and are instrumental for attaining value from an organization’s investments in its project management system.

Reference: Project Management Journal, Vol. 40, No. 1, 42-54.

Authors: Thomas G. Lechler, Stevens Institute of Technology; Martin Cohen, Stevens Institute of Technology

Link: http://www3.interscience.wiley.com/journal/122217097/abstract

Comments: My first reaction was: I wonder what relevance this research has to Change Advisory Boards in a Change Management process. However, beyond the superficiality they are not very similar. Projects, and hence project steering committees, are more strategic. Project steering committees consist mostly of executive management; the CAB may consist of representatives of management, users, partners, and vendors among others.

What surprised me the most of the research is how little research has been performed this area. Lechler and Cohen sought to address the questions of project steering committees: 1) what are the various configurations and responsibilities, 2) which project decisions are made, 3) how are they organizations, and 4) do they increase project management value? In order to do this they examined four companies in depth, as part of a larger PMI-sponsored study.

They found wide variety in steering committee composition, which is consistent with my observations of CABs in organizations implementing Change Management. In general they found steering committees are perceived to improve project management performance with minimal detrimental elements, such as political infighting or delayed decision-making. I wonder what would have resulted from the study of project-oriented organizations that lack the element of a structured steering committee–would they perceive lack of a steering committee hinders project management success?

What is the dividing line between a Project and a Change?

When is a Change really a Project? ITIL simply says the following are not changes:

  • Changes with significantly wider impacts than service changes, e.g. departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes
  • Changes at an operational level such as repair to printers or other routine service components.

It isn’t clear to me that the natural agency—PMI—offers any clear guidance. PMBOK defines a project as a temporary endeavor undertaken to create a unique product, service, or result. Temporary endeavor implies a definite beginning and end.  Unfortunately, this definition is not inconsistent with a Change.

PMBOK offers little guidance about how big or how little a project needs to be in order to become a “Project” except to say the PMO exists to support project managers including developing a methodology, best practices, and standards. I would say a project is a “Project” when the benefits of managing it as a “Project” outweigh the overheads of the PM method. Hence the answer is organizationally dependent. If the organization’s PM methods are non-existent, then you can call anything a “Project” and send it off the secretary masquerading as a PM.

If the PMO’s PM method is detailed and rigorous, then projects would be greater than 80 hours at a minimum. However, in order to avoid the tendency of middle managers to “break up” projects in order to avoid PMO oversight, PMO’s will generally make the PM method scalable, requiring less overhead and oversight for smaller projects and more for larger projects.

In general time alone is a poor indicator for defining the boundaries of a project. A PMO should also look at factors such as strategic alignment, whether the Change supports or endangers the company’s strategy, and the project’s risk profile. Riskier projects should be overseen by the PMO in order to ensure the risk profile is in line with its support of the strategy.

In most organizations the PMO is more strategic and is independent of the IT operational processes. The Change Manager may hear about projects a few days before they are expected to go live (as a Change). In other words, the Project usually precedes the Change, not the other way.

Building Value Through Sustainable Project Management Offices

Abstract: Organizations’ attempts to implement and gain value from investments in project management have resulted in rapid growth and, in some cases, demise of project management offices (PMOs). The recent research literature on PMOs provides an ambiguous picture of the value case for PMOs and suggests the tenuous nature of their current position in many organizations. In studying project management implementations for the Value of Project Management project, we chose to use three detailed cases and comparisons with the remaining 62 organizations in the value project to study how PMOs are connected to value realization for organizations investing in project management. Specifically, we sought to understand how PMOs deliver sustained value to organizations. Using the theories of Jim Collins (Collins, 2001; Collins & Porras, 1994)) as an interpretive framework, we explore these cases to understand how to create and sustain project management value through investments in PMOs.

Reference: Project Management Journal, Vol. 40, No. 1, 55-72.

Link: http://www3.interscience.wiley.com/journal/122217098/abstract?CRETRY=1&SRETRY=0

The paper reviews three companies’ PMOs in depth and compares them against some principles derived from Collins’ work, including:

  • Build a core ideology for the long term
  • Pick the right PMO leadership.
  • Staff the PMO carefully.
  • Create a culture of discipline.
  • Confront the brutal facts, but keep the faith.

While I have tremendous respect for Collins and his contributions, I am not persuaded his research results are intended to be applied to departments, or even divisions or business units, inside an organization. Thus I find the this research method very curious. I don’t think you can compare PMO leadership with organizational leadership at the top level. In addition, I question how were these three companies chosen (at random, or because they illustrated the conclusions the authors wanted to convey), and how were these particular principles from Collins’ works chosen?

The authors conclude that “we think effective PMOs continue to add value specifically by changing and reinventing themselves–as long as they stay focused on the principle of improving project management in the organization.” There is too little data to have confidence in this conclusion.

McKinsey Survey: IT Potential Unmet

In a December 2008 survey of C-level executives titled IT’s unmet potential: McKinsey Global Survey Results (free registration required), McKinsey Global Institute documents the discrepancy between the desired and actual business results of IT. It also demonstrates some differences between the expectations among IT and non-IT executives. Of particular interest:

  • Nearly two-thirds of executives believe their organizations are at risk of information or technology-related disruptions, and less than half believe they are prepared to manage these disruptions. Concern is greater among IT executives.
  • IT efforts are concentrated on improving the efficiency of business processes, but there exists stronger desire to improve the effectiveness of these processes. An even stronger gap exists between the ability and desire for IT to help create new products or services.
  • An even stronger discrepancy exists in the alignment of IT and business strategies. Whereas 67 percent of C-level executives desire strong alignment (“Business and IT strategy tightly integrated, influence each other”) only 22 percent said they actually are. Twice as many organizations said their corporate strategies are developed first.

The discrepancies between IT and non-IT executive responses were even more interesting:

  • IT managers were more likely to emphasize improving the talent of their IT staff (57 percent) than their non-IT counterparts (42 percent).
  • IT managers want to consolidate IT functions to a centralized IT (21 percent) than their non-IT counterparts (14 percent).
  • IT managers are more concerned about reallocating budgets to focus on value drivers and improving IT governance and oversight.
  • On the other hand, non-IT managers were more interested in outsourcing IT functions (22 percent) than were IT managers (18 percent).
  • Whereas more managers expect to reduce IT operating costs in 2009 versus increase them (43 percent versus 23 percent), the numbers are almost perfectly inverted when they look at new IT investments (26 percent versus 41 percent).

The final point suggests 2009 may become a turnaround year for IT executives, in which IT is able to influence organizational strategy in order to capitalize on strengthening their positions during this global recession. This final point is important: change begets opportunity, and those organizations who strengthen their positions during the downturn will benefit during the next recovery. Often the ability to seize the opportunities is inversely related to debt carried, so look for cash-strong companies to become stronger.

By the way, the outlook for IT project managers also remains relatively strong.

Researching the Value of Project Management

On Tuesday I attended the monthly dinner meeting of Portland Chapter of the Project Management Institute, where Dr. Janice Thomas presented some results of her three year study that PMI will sell this year in a paper called Research on the Value of Project Management. The research team studied over 60 organizations over a year and a half in a variety of industries. They gained access to senior managers and detailed project records in order to corroborate interview statements with actual findings.

I initially skeptical of the research. Imagine this: research sponsored by the Project Management Institute finds that organizations always find value in Project Management. The research sponsor proclaims “I can definitively say that project management will bring value to companies”. However, the presentation by Dr. Janice Thomas showed she was very intelligent and thoughtful, and she was aware of the implicit biases.

Some interesting observations:

  1. Companies who focus on project management to control costs find a strong correlation with customer satisfaction, and that correlation is negative.
  2. No company in the sample could deliver ROI numbers for their project management programs. In other words, there was no ROI for calculating ROI.
  3. Companies who benefit from project management cannot simply make a one-time investment and then let it go. They must continually adjust, improve, and invest in the project management program for it to continue to succeed.

The full research paper will be available at PMI.org for $50 for non-members and $40 for members.