Cramm, Susan. 2010. 8 Things We Hate About I.T. Boston (MA): Harvard Business Press. COinS

by Timothy M. McGeary

Introduction

In 8 Things We Hate About IT Susan Cramm discusses frustrations business leaders have with IT and strategies to remove those frustrations in order to form effective partnerships.  While this book focuses on solving the traditional corporate struggle between business leaders and their IT group, library technologists are in a unique position in this struggle: right in the middle.

The vast majority of academic libraries fall into two categories: libraries that are separate from central IT and libraries that are merged with IT in one organization.

In both of these examples, librarians are the “business leaders” bringing projects, ideas, and requirements to library technologists, the latter of which fit the classic role of IT.  But within the larger organization, library technologists turn around seeking the same support from central IT.  Often this role is a no-win situation, due to lack of power and difficulties in communication.   Even though the examples Susan Cramm offers are focused on the private sector, the principles are just as important to discuss and implement in libraries.  All librarians and library technologists would be wise to heed the lessons in Ms. Cramm’s book, including those from libraries that either completely control or outsource their entire IT infrastructure and support.

Cramm lays out the following battles with IT: Service or Control, Results or Respect, Tactics or Strategy, Expense or Investment, Quickness or Quality, Customization or Standardization, Innovation or Bureaucracy, Goodness or Greatness.  For each battle, I will briefly discuss Ms. Cramm’s descriptions of the battles and suggestions for overcoming these challenges, while providing examples and commentary on their applications to the library.  Before going any further, it is important to define a few key terms that Ms. Cramm repeats frequently:

1) Service or Control

IT leaders want to please business experts because they get excited  solving big problems, but IT leaders answer to both business leaders and the enterprise, which may make it difficult for IT leaders to fully meet the expectations.  Business leaders have a present problem and want a present solution, but the enterprise requires long-term sustainability.

There are four parts to what Cramm describes as a balanced approach for organizations to have successful partnerships between business and IT leadership.  These are: realizing values (investing in projects with highest ROI and holding those investments accountable); serving the business (balancing innovation as an art not a science, thus projects are most successful with clearly defined outcomes, limiting time frame, funding in stages, scope is managed appropriately, and the right resources are assigned); running efficiently (simplifying and standardizing technologies, vendors, operations, and creating efficient automated processes); securing the future (leverage existing IT solutions to support strategic business requirements, thus eliminating the multitude of applications and systems needing support, upgrades, or overhauls in the future).  (p. 18-19)

The corresponding key to finding a balance in libraries is acting in partnership with both business and IT.  It’s not service or control, but service and control.  Partners back each other, and look to work together for a successful venture.  Librarians need to realize solutions must be sustainable, not just fill a need.  Technologists need to realize they can’t solve a problem on their own just because a problem has been stated.  Both groups need to think strategically together about how a potential project benefits their larger organization.

Early in my career, as the lone library technologist in my organization, I made four of the eleven business-leader statements listed in Table 1-1 when communicating with central IT staff about a project.  In fact, I was so entrenched in the library business requirements that I lost sight of both the relationship dependency I had with central IT and the enterprise.  The result was a very vocal argument with their cubicle farm.  Regardless of any shared blame, I was both too naïve and too inexperienced to make such demands on the enterprise.  While the hard knocks experience taught me a great deal, I would have rather been given this advice before that project, rather than spending the greater part of the next year re-building the respect I had lost.

2) Results or Respect

The business leader wants results and generally does not understand the IT requirements those results depend on.  Most frequently the solution has been to go around IT directly to a vendor if the business leader does not believe IT will produce their required results.  But often IT is still required to intervene, at a minimum, or take over entirely.  (p. 29-30)

Cramm urges business leaders, and I believe this is just as true for library leaders, to consider focusing on building connections and relationships with IT instead of merely focusing on the results. (p. 30) Make no mistake – this is hard: personalities clash, experiences vary, and alignments differ.  Consider:

• IT people are more aligned and/or affiliated with IT and their technology than their library organization at large.
• IT staff have different backgrounds or experiences within libraries and library business that makes communication difficult.
• Business and Library leaders focus on getting a project done now; IT leaders focus on getting the project done right, to sustain and support it. (p. 31)

But it is important to realize that both business and IT staff hate the control of bureaucracy.  This common point of pain can often be a jumping point in starting to build a sustainable, and respectful, relationship between library leaders and IT.

Another consideration for library leaders in building respect with library IT is this statistic: on average, 55% of IT human resources are required to maintain, support, or operate IT solutions.  10% are typically dedicated to planning, with 35% left over for new development. (p. 34) Mileage will vary, but my opinion is that within the library, IT technologists spend closer to 70% on maintenance, operation, and support, leaving 30% for planning and new development.  Often planning gets an even shorter stick, or maybe no allocation at all, to the detriment of both future development and especially the inevitable, and more difficult, support, thus straining the next cycle of new development.

Library business leaders can change the rate of results by changing their focus from results to respect.  Add an IT leader on your team, elevate IT to a true partner status, and develop interpersonal connections with IT members who are working on your projects.  These are excellent ways to ensure greater rates of success for your projects.  Last, seek their input about what they expect a library business leader (you) to accomplish. (p. 38-40)

3) Tactics or Strategy

Strategies are not goals, annual objectives, or key initiatives.  Strategy is also not about meeting short-term demands that overwhelm our time and resources.  Strategy, as Cramm defines it, is the foundation used to make daily, monthly, quarterly, and annual decisions, and the tactics concerning goals, objectives, and initiatives. (p. 43-45)

Because of short staffing in many, if not most, libraries, strategic planning tends to lose out to demands, objectives, and goals.  Library leaders decide that demand for applications, and the innate desire to fulfill that demand, suffices for IT strategy.  What is often not realized is that building strategy is an ongoing process, and not finite events that occur every three to five years. (p. 60) Annual goals lists, while effective for planning, should be checked against and prioritized by your IT strategy.  If your library doesn’t have one, now is the time to start making one.

But who initiates strategy?  Typically both business and IT wait for the other, as shown in the following table.

The key is to work together.  IT will often not know the business problem, especially in the library, which needs to be solved with an IT-based strategy.  Likewise ordering IT solutions, as one-off applications, will reveal your ineffective IT-based strategy and, likely, an unwilling IT participant. (p. 46)

While this chapter deals with complex strategic positioning, librarians and technologists should follow a similar path when developing IT-enabled business strategy, as Cramm describes in the figure below:

The key to all this is gaining quality commitment to the strategy beyond the quality of the idea. (p. 60) Ideas come and go; yet even good ideas require strong commitment for a project to become successful.  Without commitment from both the library leader and IT, a good idea could easily become a failed project.  By building a strong strategic foundation based on respectful communication of both IT and library/business initiatives, projects will have a much better chance for successful implementation and on-going support.

4) Expense or Investment

Of the 8 Things We Hate About IT, this might be the most complicated to translate to library land because it has such a corporate feel to it.  But in reality, the pieces of demand management, which is the focus of deciding if a project is an expense or an investment, is just as important within library technology projects.  Whether demand management is actually performed or not will likely vary based on the size and IT-maturity of the library.  Whatever level of demand management is implemented plays an important, if not vital, role in successful technology ventures.

So what is demand management?  Cramm defines it as the “process of allocating limited resources to the overall benefit of the enterprise.” (p. 64) Continuing in the definition, demand management is a cycle and a process involving the following steps:

• Strategic planning – as addressed above, this provides the context for prioritization of investing in IT-enabled projects
• Portfolio management – provides an on-going guidance on project investment decision and project review
• Decision rights – the principle that business leaders have authority to decide what IT is needed and IT leaders have authority to decide how IT is delivered
• Financial planning determines amount of funding or price IT costs for business to find external funding
• Prioritization – occurs parallel to and in conjunction with the four above steps
• Value management – accountability for defined business value and monitoring of actual results (p. 64-65)

Of all enterprises, libraries can surely understand the definition, and impact, of limited resources; therefore it is even more critical for libraries to implement demand management.  Without using pieces like strategic planning and portfolio management, libraries can become easily overwhelmed with too many projects on-going or too many applications to support long-term.  At the same time, it is important that each side, library business leaders and IT leaders, be responsible for their areas of expertise.  Not only does this maintain balance within project-planning relationships, but it also keeps accountabilities balanced when evaluating outcomes.

Of all areas, value management is the step most often ignored or implemented poorly in all businesses that use IT.  We easily attempt to predict or define the value of a project beforehand, but do we honestly seek to evaluate whether that value was returned?  Libraries rarely have a financial return on investment, so usage statistics are often the most reliable return, albeit sometimes misleading.  Regardless of the metric used to rate the return on investment, it is prudent for libraries to take the time to evaluate whether existing projects are as valuable in operation as they were predicted during planning.

5) Quickness or Quality

Only half of IT projects deliver successfully or on time, on budget, and on spec.  12% deliver too little or are canceled, 33% too late (and by an average of 71% longer than scheduled), and more than one-third are over budget (by an average of 41%). (p. 85-86) The biggest reason is that defining specifications and requirements is very hard, and iterations take time to get it right.  This naturally results in a frustration between “done” and “done enough.”  (p. 86)

The balance is between getting it done and getting it done right.  Otherwise, an organization may find that being out of balance results in standalone solutions that are difficult to integrate or over-engineered solutions that miss the business requirements.  Cramm suggests, however, that project success can be increased through these steps (p. 89):

1. Define a clear objective for the business and people on the front lines
2. Engage the intellectual, emotional, and tangible aspects of the people affected by this new project
3. Integrate and streamline business processes
4. Leverage existing technology to the fullest
5. Use fast-cycle approaches, using best human resources and delivering every 3-6 months

Beyond Cramm’s suggestion of delivering every 3-6 months, there is an increase in investment within higher education on Agile (also known as Scrum) project methodology.  Some colleges and universities have joined together to create an organization called ScrumU (http://www.scrumu.edu) to support implementations of Scrum project management.  I have implemented Agile project management at Lehigh with some initial success. [1] Agile allows both a quick delivery of solutions with the ability to revise requirements and specifications before going too far down the wrong path.  As always, results will vary based on the implementation, but it can provide a jumpstart to solving the dilemma Cramm is describing in this section.

6) Customization or Standardization

Cramm compares moving a software solution into production to moving into an exclusive community – it must measure up to the existing standards. (p. 108) How “gated” the higher education and library production environments are varies widely.  Much commentary has been made recently about enterprise versus toy projects in the Code4Lib community (see [2] Hellman, 2010, for example), but in reality a production environment there are existing standards that must be met.  These existing standards usually (and should) contain requirements to provide adequate documentation on how the application was built, proves the application was thoroughly tested, and that it meets the organization’s requirements of compliance, security, and service.  The benefit of such scrutiny, once accepted, is that your project acquires security, backup, performance monitoring, and detailed support. (p. 108)

But Cramm adds that you still need to do some more work (p. 109-110):

• Train users thoroughly to use the full application
• Resolve technical issues quickly
• Maintain and enhance the application
• Secure funding/resources to support all of the above

The rest of the chapter Cramm focuses on the need to reduce the total cost of running technology.  It is important, as the business leaders in the relationship between the Library and Central IT, to consider the impact our new project has on the IT enterprise.  Do we really need a separate server?  Can an existing database server be leveraged?  Can we piggyback on a storage solution?  Are we utilizing enough of the servers and storage already provisioned for us?  Libraries should think carefully about these questions and their respective answers when considering the deployment of our new technology.

7) Innovation or Bureaucracy

Cramm states that 37% of IT leaders and 50% of business leaders agree: “IT is overly bureaucratic and control oriented.” (p. 125) Technologists would rather have business leaders marvel at a successful project than complain about why IT says it can’t be done.  But IT struggles daily with an overwhelming amount of project requests, on top of supporting existing enterprise solutions. (p. 126)

Three key areas bog down IT (p. 126-127):

• Dealing with existing complexity of mixed and matched solutions, unstandardized legacy systems, and standalone applications.  Reducing this complexity would significantly reduce cost.
• Promoting enterprise interest – once IT finds and implements standardized technology, it becomes a strategic initiative to leverage it where possible, often at the frustration of business leaders looking for new innovations.
• Lack of resources – IT is often not proactive in supporting the organization or driving business decisions because it lacks resources to be proactive while standardizing and supporting the current enterprise.

To create more innovation, library leaders need to take more responsibility to be innovative themselves.  This requires a more hands-on approach in partnership with IT.  This removes the “reading of the mind” aspect of the business-IT relationship.  Requirements documents do not do this – person-to-person activity does. (p. 129)

Secondly, ask IT to create a solution that allows you to do more without their need to intervene. Gain their trust by asking them to build the functionality for you to do more on your own, while admitting that any harm you do will have serious consequences in a system clean-up.  Take accountability for that privilege and power. (p. 129-130)

Finally, forge a new partnership, as Cramm shows in Table 7-1 from page 139:

8) Goodness or Greatness

Cramm hopes that by addressing the first seven issues, business leaders can promote IT from being just good to great.  This will happen from encouraging more IT-smart business leadership to treating IT as a partner, not as a service, as well as following the entire organizational strategic chain of planning, investing, innovating, delivering, and operating. (p. 141-143)

Confronting the difficult facts of supporting the entire enterprise, Cramm asks us, as business leaders to our IT, to answer these questions (p. 143-144):

1. What have I learned?
2. What frustrates me about IT?
3. How am I contributing to my frustrations with IT?
4. What am I going to do about IT?

But while we may think we know what we need to change, Cramm advises that it is important to do a reality check with our IT partners.  Get feedback and own up to it. (p. 146) Cramm gives excellent examples about how good IT can be, and realistic examples of how bad IT can get without the proper leadership and partnership.

Conclusion

It is the responsibility of library leaders to set the tone of partnership with IT, and our role as library technologists to see both sides of the coin.  Library technologists have a unique opportunity to serve library organizations as both IT providers to librarians and business leaders to the larger supporting IT organization.  Susan Cramm offers excellent advice, strategy, and most importantly examples that can be used to position library technology in effective partnerships within our organizations.  It is not an exaggeration, in the ever-increasing technological era we live in, to describe library technology as a keystone for our organizations.  But in taking on that position, it is even more important to heed the strategic advice of leading effectively between the business of libraries and the enterprise of IT.

References:

[1] McGeary, Timothy M.  January 2011. Implementing Agile at Lehigh University. Team DynamixHE Community Column [Internet]; Available from: http://community.teamdynamix.com/columns/73/implementing-agile-at-lehigh-university

[2] Hellman, Eric. February 8, 2011. Toys and Tools vs. the Enterprise at Code4Lib. Go To Hellman [Internet]; Available from: http://go-to-hellman.blogspot.com/2011/02/toys-and-tools-vs-enterprise-at.html

About the Author

Tim McGeary serves as the Team Leader of Library Technology at Lehigh University Libraries, and is responsible for the technology infrastructure, specifically focusing on leading the development of efficient and dynamic solutions to connect library collections to users.  Tim has presented nationally and regionally on library technology development, managing electronic resources, open source solutions, and the Kuali Open Library Environment (OLE).  Tim currently serves as Kuali OLE Functional Council member for Lehigh University, the Code4Lib Journal Editorial Committee, the LYRASIS Advisory Panel for Open Source Initiatives, and the NISO ERM Data Standards & Best Practices Review Committee.