Mar 27 2008
Management

Righting the Ship

Is your IT project in danger of sinking? Act fast and apply these fixes to salvage the situation.

We all know it — that sick feeling in the pit of your stomach that comes when your latest IT project isn’t going so well. Usually, the feeling comes on long before any official acknowledgment that the work has gone off track. There’s just a sense that things have gone awry.

If you have that sense, you’re bound to be right. We queried a number of project-management pros — the ones who are called in to oversee the biggest, riskiest projects. Here is their collective wisdom on how to spot the warning signs and, more important, what to do next.

Red Flag: Scope creep. Every bad project has the
inexorable rise in requirements, and the attendant blown budgets and shot timelines. Preventing scope creep is a fundamental principle of Project Management 101, but that doesn’t mean the problem doesn’t happen every day. Scope creep is a regular part of project life, says Brenda Breslin, director of the Project Management Office at the CIO/Office for Technology for New York state, in Albany. As such, it is not so much a bad sign as something that needs to be mitigated in a systematic fashion. “If there is a change-control process in place, usually you’re going to be OK,” says Breslin, a 28-year veteran of state government.

Fix: Phase the project and implement change controls. Breaking large projects into smaller, more easily achievable phases is another bedrock project-management principle — one that should be employed as soon as you are aware that project scope has gotten out of control. But to keep from getting into this problem in the first place, an airtight change-control process is key. Nipping change orders at the front end is the goal, says Stacia Cropper, director of strategic planning for the Office of Information Technology of the Department of Budget and Management for the State of Maryland, in Annapolis. “The worst time to realize you’re dealing with scope creep is when you see your financials going off the boards.”

Separating out the change-review function from the project’s frontline project management may keep you from getting into this situation in the future. “The people who approve changes to the project plan should be different from the ones who ask for the changes,” says Cropper. At the Arizona Government Information Technology Agency (GITA), changes to the project plan (such as an extension to the start date) must be approved by an oversight committee rather than the project team. Paul Wix, GITA enterprise applications manager, agrees with Cropper that having an additional layer of control helps stop problems in their tracks.

Red Flag: No communication. (Related: No bad news.) Any project plan worth its salt includes a reporting schedule according to which project managers, project leads, user leads and other involved parties are due to report on their progress. In this case, no news is definitely bad news, as it often means something has gone wrong but the individual does not want anyone to know. “The report either doesn’t come in or I can quickly see that this is last month’s with the date changed,” says Breslin. Inexperienced project managers often think a negative report reflects badly on them. “I may not want to tell anyone because they’re going to think I’m a bad project manager,” says Cropper. If it persists, that attitude can be career-limiting, not to mention project-threatening.

“If I don’t get a report that I am expecting, that is a red flag,” says Wix. “We tend to nip that in the bud. If we have problems with individuals, it’s usually very short term.”

So-called “good news reporting” is a related problem. “If the report contains only good news then I am immediately suspicious because projects — especially sizable ones — just don’t go that way,” says Breslin.

Fix: Get directly in front of the culprit and find out what is going on. In this case, an in-person meeting is far preferable to a phone call or an e-mail. You need to get to the bottom of what is really happening, and it will be much easier to do that face-to-face. The most important thing is to meet with the person as soon as possible rather than letting months go by.

You will also need to take a hard look at how your organization deals with bad news. If there is a kill-the-messenger culture, people are not going to come forth with the real deal. “People don’t want to report the bad news because they don’t want to be beaten for it,” says Cropper. If you have that problem, it will likely take a major cultural transformation — led by the very top of the organizational hierarchy — to turn it around.

Brenda Breslin’s experience directing IT projects for the state of New York makes her adept at spotting signs of trouble.

Timothy Devine

Red Flag: “This project has no risks.” Anyone with experience in project oversight knows to cringe when a project plan comes back with no description of the risks inherent in the undertaking. “That means they have either skipped a step or they just don’t want to deal with it. Every project has risk. You need to identify the risks beforehand. If you have planned for problems, it is a lot easier to deal with them when they occur,” says Breslin.

Cropper concurs. “Never accept a statement that there is no risk. That does not reflect reality,” even when the project is not multiyear and multimillion-dollar in size.

In the past several years many state governments, including New York’s and Maryland’s, have undergone significant migrations of legacy applications to newer computing architectures, including Web services and service-oriented architecture. Those projects in particular need a detailed risk plan to mitigate the two most serious risks: lack of user adoption and acceptance.

Fix: Kick back the project plan and insist that risks be quantified with mitigation strategies. No project manager or project sponsor should ever let an IT project plan slip through without addressing risk. But if that has indeed happened, the only thing to do is go back to the project plan’s author and ask him or her to fill in the risks and mitigation plan. Then resolve never to let that go again.

Red Flag: Executive sponsor often misses
meetings (or has dropped out altogether). One of the most frustrating phenomena for IT managers who work in government is to lose their project’s executive sponsor. If your executive sponsor is MIA (chronically missing meetings and never asking for information, for example), odds are good that he or she has lost interest in the project. That can be very difficult to combat. “That’s a pain point that we go through with election cycles,” says Breslin. “You never know if you are going to lose or gain a champion as the result of election cycles and associated changes in staffing.”

Fix: Hope for the best. There is not much you can do to re-energize an apathetic or absent executive sponsor, and heaven knows there is no way to stop the new appointments that result in staff changes. But what you can do is ensure that every project is staged to deliver results quickly. “When you are in a political organization, you have a year or two at the most to make your mark,” says Cropper. Even more of a reason never to have a “big bang” (that is, an overly ambitious project plan where many years go by before any results are delivered).

The discipline of project management is full of helpful principles and strategies for dealing with problematic projects. What it doesn’t have, says project pro Breslin, is a perfect formula for knowing when you are in danger. “It’s all in the variables of that particular project and agency — the expertise, the people, the budget cycles, the history,” she says. At the end of the day, you will have to weigh all of these factors against the feeling in your gut.

Adding Up to Failure

Tom Mullen, practice head of the federal and defense services team for PA Consulting Group, warns IT leaders to mitigate if their projects meet more than two of these conditions.

  • Ambiguous and/or changing requirements
  • Immature technologies
  • Lack of risk-sharing
  • Inexperience
  • Incomplete plans
  • Tight or inflexible budgets and schedules
  • No interim releases

The Warning Signs Were There

In the 1990s, the state of Maryland took its first steps down the path of updating the child-welfare records system at the Department of Human Resources, a project that was slated to take a few years and cost under $10 million. No one knew at the time that the journey to implement the Children’s Electronic Social Service Information Exchange (CHESSIE) would reach well into the next millennium and end up costing nearly $100 million, according to individuals familiar with the situation.

Early on, the project exhibited all the classic signs of impending doom — burgeoning requirements, blown timelines, shredded budgets, disgruntled users, lack of executive sponsorship, no risk-mitigation plans. Adding to the pain, the project was very much in the public eye, as critics blamed the inadequate system for the deaths of at-risk children who had fallen through the cracks. Maryland’s mainframe-based child-welfare system had gotten among the lowest marks in the country for systems of this kind, so pulling the plug was not an option. The project lumbered on for a decade, racking up costs and missed milestones.

The situation began to turn around in 2004, when Ellis Kitchen became the state CIO. Emphasizing fiscal responsibility, Kitchen installed a project advisory committee that halted work on CHESSIE while the team developed a new project plan. It took a year and a half to get the project back on track, but the first phase of the implementation was completed in 2007. The lesson learned from this is to not let problems fester for long before intervening.

Close

Become an Insider

Unlock white papers, personalized recommendations and other premium content for an in-depth look at evolving IT