Avoiding Failure with Higher Education Technology Projects

I am frequently asked for a definition of a “successful” technology project. As a career senior technology executive, university educator, and now university chief executive, I have a deceptively simple answer. A successful technology project is one that is delivered on time, that comes within budget, and that meets or exceeds stakeholders’ expectations. Yet according to a study conducted by McKinsey & Company in collaboration with the University of Oxford: “On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.”1 When I look around higher education, I would say these numbers are optimistic.

Why Higher Ed Technology Projects Fail
The easy answer to explain why technology projects in higher education fail is to place blame on ineffective project management and lack of communication. Technology project postmortems generally fail to get to the root causes of project failure—probably because true reflection means having to deal with the painful realization that the institution was ill-equipped to undertake the project in the first place. From nearly four decades of technology project-management experience, I see five main risk factors that lead to technology project failure. These risk factors are interrelated, and a failed project typically exhibits two or more of these factors.

Inadequate or Incomplete Definition of Requirements
In this age of agile project management, we seem to have lost appreciation for having a requirements document that details such items as the purpose for the technology project (including financial ROI), mandatory and desired functionality, and data conversion and retention requirements. In essence, what are the institutional, functional, and/or programmatic outcomes that the technology project must achieve? These outcomes form the basis for a project rubric, which can be used to evaluate aspects such as competing technologies (or systems), mode of implementation (e.g., “build versus buy” or a local server-based solution versus a cloud-based one), conversion schemes, documentation, and training. Without this rubric, how does one know whether or not this technology project has a chance of succeeding?

Lack of Stakeholder Involvement
I cannot overemphasize the importance of stakeholder involvement in a technology project. All too often, the technology department of a college or university initiates a technology project—and obtains funding for it—without involving administration, faculty, staff, students, and others who will potentially be affected by the outcomes of the technology project. Collaboration and cooperation between stakeholders and the technology organization are keys to project success.

Two decades ago, I was engaged by a college to “rescue” a student information system (SIS) conversion that was late and over budget. It was in month eight of what was supposed to be a nine-month project, yet no academic or cocurricular departments knew anything about the project. They were not involved in the selection of the new system, were never scheduled for training, were never asked to validate the student data being converted, and were never included in any other aspect of the project. The technology organization’s rationale for this lack of stakeholder involvement went something like this: “They are too busy to be involved. We will train them when the technology team is ready to deliver the new SIS.”

In another, more recent SIS implementation, the institution’s technology organization proceeded with a “dry conversion” from a legacy homegrown system to an integrated vendor-supplied system. Thirty months later, and eighteen months after “completing” the SIS implementation, the institution is still struggling with the new system. Why? Without stakeholder involvement up front and during the project, the new SIS was made to mimic inefficient workflows based on the legacy system, data interrelationships were not understood by the technology folks (resulting in numerous data-related issues), and stakeholders again received “just in time” training that was ineffective.

Unrealistic Schedule
Higher education is not alone in its tendency to set schedules at the top of the organization. Some schedules reflect the reasonable constraints of a semester or term systemfor example, upgrading computer lab equipment over spring break, implementing a new financial system based on the fiscal year, or deploying a new admissions system over a semester break. Fitting implementation into the first available break in the academic or operating schedule is not a valid reason to rush a technology project.

Many higher education administrators (like their counterparts in the private sector) are unfamiliar with what it takes to deliver a technology project, especially the time needed to perform data quality control and to train faculty and staff to a level of proficiency with the new technology. Yes, taking longer to correctly complete a technology project has an associated cost, but so does delivering one that is doomed to fail. As I used to tell my software engineering students: Spending $1 to catch and correct an issue in the requirements stage of a project will avoid the $1,000 that will be required if the issue is left undetected until after implementation.

Scope Creep and Inadequate Change Control
Without a project rubric, it is difficult to contain the scope of a technology project. With overactive stakeholder involvement, there is a tendency to add functions and features—or to turn on options—that at best are a marginal improvement to the system being delivered. The results are cost overruns, missed project deliverables, and schedule changes. Every technology project should have a formal change-control process to handle implementation realities and stakeholder requests. One reasonable way to deal with requested changes is to create a priority list of those requests that can be accommodated in the initial implementation and those that will come later.

Ineffective Documentation and Training
The project rubric should be the foundation for ensuring the adequacy and effectiveness of documentation and training. Vendor documentation and training should be examined for every function and feature listed in the project rubric; institution-developed documentation and training should emanate from the project rubric. It’s never too early to start scheduling training for stakeholders based on their need to know or use the new technology. Here again, collaboration is essential.

Honing a Successful Technology Project Team
Mitigating project risk factors is a major part of avoiding technology project failures, but doing so will not be enough. A successful project requires strong project-management skills, frequent and clear communications with stakeholders, and a well-functioning project team. Honing a successful team to undertake a technology project requires preparation, leadership, and internal communication.

A technology project team brings together people who may or may not have worked together before. Some come from the technology organization, some are stakeholders, and still others are consultants or vendor representatives. It is extremely important that every member of the team knows his or her role and responsibilities and how to communicate within the team and has received an overview of the project itself, including goals, assumptions, limitations, constraints, deliverables, and deadlines. Conveying this information is the job of the project manager. Regardless of how many times these team members have worked together, this orientation is absolutely necessary.

Also key to preparing the project team is providing team members with the resources they will need to undertake the project—for example, hardware, software, Internet access, documentation, and training. Too often, higher education technology projects launch with insufficient resources, in part due to budgetary constraints. Time is another needed resource. Team members must have the dedicated release time necessary to spend on the project. This is extremely important for faculty and staff stakeholders, who will find it difficult to juggle project duties with everyday teaching or office responsibilities.

When a problem arises with the project—and it will—the team members and the project manager need to know about it and work together to get the project back on course. The project manager must anticipate problems, take corrective action, and help the team learn from the problems and issues encountered. Protecting the team from untoward external influence or pressure is also a key role for the project manager.

Continuous, positive reinforcement for team members can go a long way to moving the project forward successfully. There can be a lot of excitement and enjoyment in achieving the smallest of outcomes on a technology project. Acknowledgment of hitting project milestones helps build team morale, especially when the final deliverable is not yet in sight.

Takeaway
So what is the best way to avoid technology project failures in higher education?

  • Have a strong project rubric based on stakeholder involvement. It will be the foundation for the project plan, documentation, and training, as well as ongoing communication with the stakeholders.
  • Create a realistic schedule for the project and equip the project team with the necessary resources for success, including dedicated release time for this project.
  • Commit stakeholder resources for testing and training.
  • Empower the project manager to move the project forward without untoward pressure to change project scope or deliverables.

Finally, communicate … communicate … communicate!

 

Note

  1. Michael Bloch, Sven Blumberg, and Jürgen Laartz, “Delivering Large-Scale IT Projects on Time, on Budget, and on Value,” McKinsey & Company, October 2012.

 

© 2016 Norbert J. Kubilus. The text of this article is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

 

 

 

5 Team Leadership Lessons from the Savegre River

There is no better place to watch effective team leadership in action than on a white water rafting trip.

I had the opportunity to go rafting on the Savegre River in Costa Rica in late February.   There were five of us in the raft plus our guide.  We were all new to this team that was going down river for the next two hours.  Two of us had rafted together before, but each river, each team is different.

Our guide (“team leader”) had over a decade of experience on the Savegre with its Class I, II and III rapids.  His job was to get us down river safely to our final landing point (“the project”) by steering the raft with his paddle from the stern of the raft, assessing the river and rapids ahead, directing the team to take action with voice commands, and pulling team members out of the racing water should we fall out of the raft.

What better metaphor for effective team leadership than five simple lessons from observing our white water rafting guide.

Equip Your Team

When we arrived at the mustering location for the rafting trip, we received the appropriate equipment for the project — helmet, life vest and paddle — and an introduction to our raft and guide.

How often do we ask people to take on a project with insufficient resources?

Train Your Team

After an equipment check — chin strap tightly fastened on the helmet, life vest right sized to close completely — our guide explained his role and our roles.  He showed us how to sit in the raft and how to handle the paddle correctly … and how to avoid injuring other team members by mishandling our paddles.   Then came the command instructions — “Paddle forward”, “Left forward”, “Right forward”, “Back”, “Lean …”, “HANG ON!” — followed by a demonstration of the correct way to paddle.  It didn’t matter how many times any of us had rafted, this orientation was absolutely necessary.

Probably the most important training was on what to do if one of us went into the river.  First rule of the river is “Don’t fight it!”  Get on your back, point your feet downstream and float … toward the project goal.  Why?  Simply, you don’t want your head slamming into rocks, and you don’t want to drown.  Your guide will maneuver the raft to you, bring you close to the raft, and literally yank you back into the raft by your life vest.

Set the expectations for the team and provide instruction on how to meet them.

Guide Your Team

Reading the river ahead, our guide issued commands to propel the raft forward, turn it left or right, slow it down, or literally “HANG ON!”  Some direction has to be ad hoc, like telling us how to help him free our raft when we bottomed in some shallow water.  In the calm stretches of the river, our guide provided a commentary on the river itself, as well as the flora and fauna surrounding us … continually sharing his knowledge of the river.

Set the context of the project in addition to directing the actions of the team.  Share experience.

Assess Risks and Protect Your Team

Despite the skills of the guide and the efforts of the team, the swift river and rocks can upset a raft, sending one or more team members into the river.  I took a dunking when we spun in a Category II rapid.  Our guide had me back in the raft in less than a minute.  So it is with projects.

Lesson here: “When you have a problem with a project, rely on your team leader and team members …  and don’t bang your head into the rocks!”

Celebrate Successes

There is a lot of excitement and enjoyment in white water rafting.  And there is a great sense of accomplishment after each rapid.  Our guide gave positive verbal feedback all along the trip, and called for a “High Five!” at various times when we achieved a milestone like clearing one of the more difficult rapids.  What’s a “High Five!”?  Team members raise their paddles high over the center of the raft and click them together.  Seemingly silly?  Hardly.  It symbolizes the team work inherent in white water rafting.

Acknowledging even small project accomplishment can go a long way to building team morale and keeping a project on course.

The Right Stuff For IT Projects

Twelve years ago I was interviewed for an article on the right stuff for leading successful IT projects [1] that focused on three questions:

  • What skills and competencies really matter most for the people who lead and deliver successful IT projects?
  • Are these different from the ones that were regarded as most important five or ten years ago?
  • How can some of the most important “soft skills” be acquired and honed, especially when for many in IT, they may not come very easily?

As I review the interview today, my responses seem as relevant now as they were in 2003:

“Soft skills are becoming more important than ever before. Most projects tend to fail because of a failure to communicate, especially between IT and business. The whole [Year 2000] issue really prompted IT and businesses to start conversing like never before, and we really need to make those intense and frequent communications the norm, and not the exception.

“Projects have such a high failure rate because business people have traditionally not been consulted before major IT projects are launched. The frequent result: distrust and skepticism, causing a rift to develop between IT and business. Good communication skills can go a long way toward healing that rift.”

What are the capabilities and skills that I viewed as more vital than any others?

“Excellent communication skills, both oral and written. Great listening skills, especially if what you need to hear is bad news. And experience in planning projects, particularly in the areas of risk assessment and contingency planning. Many people don’t want to spend time on contingency planning.  After all, everything will go perfectly, or so we hope. In fact, I would say that over- optimism, or failure to accurately assess how long things will actually take, is a reason that contingency planning for projects as a disciplined process is not as well developed as it needs to be.”

We still try to imbue these skills in IT professionals today.

“Project managers can set an example by establishing frequent two-way communications activities between IT and business communities.  This is especially important when the news is not good, such as a schedule slip. Show your team that the more information they share openly, the greater the collaboration can be between IT and business. Welcome input from a variety of stakeholders, and hold peer reviews frequently. We all learn a lot when we take the time (and have the courage) to ask.”

Collaboration is the key to success when managing IT projects.  So is mentoring project members.

“Universities and colleges can be great sources of needed training, as are national associations such as the American Management Association and Toastmasters International.  Unfortunately, many of the best project managers just don’t have the luxury of spending time formally mentoring new folks. For many competencies, such as contingency planning, experience is still the best (and sometimes only) teacher.

What about selecting an IT project manager?

“When deciding who will run an important project, consider several factors … Questions I would ask include: Can you demonstrate a portfolio of projects you have managed? What’s your track record in meeting client expectations?  How satisfied would your customers say they’ve been? How successful have you been in meeting budgets and timelines?   Certification may be important, but it’s no substitute for relevant experience.”

So the bottom line is that a successful IT project manager has experience leading projects and excellent communications skills.
__________
[1] Nancy Settle-Murphy.  The right stuff for leading successful projects. Information Strategy: The Executives Journal 19(1):21-25 (Fall 2003).