IT Project Pain?
Take 10 Tips and Call Me in the Morning
By Ed Hau, Protiviti Managing Director

Distilling all of my “street experiences,” I have identified the top 10 principles that should be applied with rigor and discipline throughout an IT initiative whether a company is deploying a large-scale IT system, performing upgrades or enhancing current functionalities.

We probably all know people at the office who, when launching a major project, want to dive right in, get the job done and admire the fruits of their labor.

For some routine office projects, this ”roll-up-the-sleeves-and-go enthusiasm” is perfect. But for those undertaking major IT initiatives, a carefully defined and planned effort will yield the most value every time.

In my nearly 20 years in the IT and technology-risk arena, I have repeatedly seen companies get bogged down on their initiatives. The ironic thing is that similar issues seem to dog them all. These issues pop up so frequently and in so many different situations that I have come to see them as “timeless” safety considerations that affect organizations despite everyone’s best intentions to make an IT project go well.

Distilling all of my “street experiences,” I have identified the top 10 principles that should be applied with rigor and discipline throughout an IT initiative whether a company is deploying a large-scale IT system, performing upgrades or enhancing current functionalities, to name a few scenarios.  In my experience, the root of all problems encountered during these efforts can be traced to not giving enough attention to one or more of the following 10 factors. These factors are arranged in a sequence corresponding to the life cycle of an IT project.

1. Establish a Common Language

Anyone who has ever asked their children whether their homework is “done” will probably know about the need to clarify, right from the beginning, what “done” means. By whose standard is it “done” -- the parent’s, the child’s, the teacher’s? (Children have an uncanny lawyer-like talent for parsing words.)

Defining terms and setting a common language from the start is key in managing IT change. The project’s steering committee must have clarity about such powerful terms as risk, complete, pass, trained, requirement, go live, and so on. Not setting these definitions will inevitably create risk and ambiguities in the up-chain and down-chain reporting.

In virtually all of my experiences with IT projects, there has been some degree of misunderstanding resulting from the lack of clarity upfront among key people involved.

2. Check the Steering Committee’s Agendas at the Door

This is a meaty and challenging step because there are egos, reputations and potential embarrassment at stake. The committee might “over-steer” the project toward a politically desired outcome, or it might “under-steer” the process by not keeping all the details in sight. It can be difficult to eliminate bias, but it is necessary. The committee has to be ready to hear both good news and bad news, and make tough decisions. In fact – as counter-intuitive as it sounds – as objective managers, the committee must welcome the opportunity to hear all news, bad and good.

In one recent situation, a company brought me and my colleagues to the project table at the 11th hour. With an imminent go-live decision looming, we alerted the committee to some likely problems. But committee members were unable to see “red lights” galore and forged ahead anyway. There was a political agenda in the room.

The upshot: 10,000 customers affected by a network outage, thousands of unreconciled accounts, and hundreds of man-hours to recover the baseline operation.

3. Manage the Scope

Managing the project’s scope means forming a scope statement and scope definition.  I am not talking about chiseling plans in stone and never deviating from them.

Scope management means that whenever you deviate, you have a process to manage that change because it will impact ancillary details downstream. For example, let us say you are building a house and you decide to add a new detail. You must return to the blueprint and understand the implications of that change. Likewise, a scope statement and definition is the project blueprint outlining the time frame, cost, objectives for functionality and so on. The statement allows us to anchor back to the objective at any validation point in the project’s lifecycle and ask, “Are we still on target with what we’ve set?”

Can a company afford to not have a scope statement? Here is a real-world example: A wireless communications operator planned to spend $20 million on a new customer-care and retail-management system. Three years and $100 million later, they were still wrestling with the project. There were numerous complicating factors. The technology had changed so many times in just three years that the company was aiming at a moving target. Also, their embedded base of business operations were being automated but not re-engineered prior to the automation.

But more tellingly, the company had a relatively weak – that is, poorly defined -- set of objectives for advancing the project, other than to remain competitive. Their project lacked sufficient depth, detail and definition, causing a lot of internal debate to take place and individual judgment to be applied during the initiative’s lifecycle. The steering committee lost its focus and challenges emerged repeatedly.

The original scope was never clearly defined, the company did not have a mature scope management process, and tragically (in a financial resource sense) the underlying business processes that needed enhanced were never addressed.

4. Find the Best PM Talent Available

I can almost hear you say, “Well, of course, we’ll find the best people!” And I say, “Sounds good!” After all, organizations spend hard-earned money on these initiatives, so they have to make judicious picks for their steering committees. Individuals are chosen not simply because they have been successful in the past but because they appreciate the challenges, are brave souls, understand the outcome, communicate effectively, and are capable of driving the change.

5. Dedicate a Team, Involve the Best

And once “the best” have been chosen, they have to be freed up from their daily responsibilities so they dedicate their talent to the IT task. I have seen several situations where the right people were selected but their day-to-day operations were not passed on to others, which caused significant conflicts. Having to choose between devoting time to the long-range initiative or to day-to-day operations, which can radiate the heat of urgency, individuals tend to prioritize the day-to-day tasks.  The net effect: neither is done well, spoiling the investment being made on the enhancement initiative.

Finding the right talent is the easy part; the challenging part is dedicating their time to the project.

6. Involve Risk and Controls Specialists

Earlier, I mentioned the need for the steering committee to be objective. The ability to objectively vet festering issues is a key benefit a risk specialist brings to the table.

Specialists pool years of experience with dozens of large-scale projects.  This is a valuable intellectual base from which a company can draw, either throughout the project’s lifecycle, during periodic checkups or with deeper analysis leading up to critical milestones. A seasoned specialist can help strengthen the project structure, aiding in the development of entrance and exit criteria for each phase as the initiative moves from concept to prototyping and to the critical go-live moment.

Anecdotal research suggests 5 to 10 percent of a project budget should be earmarked for risk management activities. Ask yourself: What are the costs of poor risk management?

7. Manage Requirements Rigorously

Requirements are really a further articulation of what functionality needs to be delivered. The “what” and the “when” are defined in the scope statement; the “how” is done through gathering and managing requirements.

For example, the scope statement sets the objective of having a sub second response time. Requirements look at the technical specifications relating to, say, interactive voice and Web functionality, modes by which customers will interact with the organization, presentation and layout, data elements, system configuration, and the like. At any point in an IT project life cycle, the committee should be able to reverse back through these requirements and determine whether the solution will fit the user’s needs.

Time and again, I have seen situations where the absence of clear scope statements and scope definitions yielded poor requirements gathering fanned by requirements “drift” stemming from lax scope management. How would a company ever validate and test a system unless there are very deeply defined requirements linked to technical specifications?  Plus, the base requirements need to be well-managed to improve the effectiveness of the validation and testing efforts.

8. Test, Test and Test Again

And speaking of testing …. By now, it must be clear how these 10 factors reinforce each other. The more you clarify the scope statement and define and manage the requirements, the better you will be able to test for integration, regression, user acceptance, volume/stress, fail-over, recovery, and so on.

Recently we worked with a large incumbent local exchange carrier to validate the performance of its wholesale customer-facing ordering, provisioning and billing systems. We worked “from cradle to grave” talking with product managers on what they needed; navigated through numerous functional groups to understand the workflow and transaction cycle of dozens of products and services; built an integrated bed of test data that was passed through with both pass and fail scenarios; and looked for break points along the chain to understand why the break was occurring.

Also, just as any Broadway production will have a full dress rehearsal before opening night, an IT project should stage rehearsals into the project stream and hold a go-live rehearsal before the curtain opens on your initiative. And yet, some committees will say they do not have time to simulate a rehearsal, feeling that it is too challenging or there is no value in it.

Testing, testing and testing again drives more success at the end.  Seldom is adequate time devoted to this phase of the effort.

9. Understand the Risks: Know the Ones You Will Accept and Those You Cannot Tolerate

OK, you have followed the steps up to this point, and the moment of truth is near. You are ready to ask, “Are we ready to go?”

But before the switch gets flipped, there are a few questions to answer: How will we know we are ready? Do we know the risks? Which risks are unacceptable? What things will we accept and react to? Which events can we just live with and life will go on? Use those answers to formulate a risk-based go/no go scorecard, listing all the issues ranked by nature, impact or priority of need to address.

Along with an across-the-team readiness, this scorecard allows you to make a much more effective go/no go decision, with individuals ready if there are any “hiccups” during the cutover and deployment process.

10. Measure Progress Regularly, Communicate Frequently

My last consideration really ties together most, if not all, of the other nine steps.  It points the way to what happens after the go-live decision, which, after all, is not really the end of your IT initiative.

Throughout your planning, you have exercised the fundamentals of communication: a strong common language, and the abilities to convey information clearly and to hear that news objectively. After the metaphorical IT switch is flipped, your steering committee becomes a type of triage team to handle the risks that you prioritized in Step 9. To achieve go-live, you may have put some Band-Aids in place that will not stand the test of time. Some of the “real” work begins with go-live. If the work-around is not permanently healed, inefficiency will fester with the Band-Aids put in place.  Before everyone on the project team departs to other assignments, clean up the lingering issues, make permanent and corrective actions, capture and preserve the success factors and war stories, and build a case file for the next major IT initiative.  Memories will fade with time.  There is no better opportunity than this to capitalize on the knowledge and experience available.

After observing IT change initiatives for nearly two decades, I can say that I do not think steering committees intentionally ignore these principles. The truth is, when people are placed right in the middle of a complex labor- and thought-intensive process in which much is at stake, sometimes considerations are simply overlooked. While nothing of this sort is simple or pain-free, following a few prescriptive guidelines might be the remedy for your next major IT initiative.

Edward M. Hau is a Managing Director with Protiviti Inc. in Vienna, Virginia.  Ed is a global leader in the Technology Risk Services competency for Protiviti which provides information technology risk management and consultation.  Prior to Protiviti, Ed was a partner with a Big 5 audit and consulting firm and he has over 18 years of service.  He is a PMP, CISA and CPA and has an extensive background in a wide variety of industries primarily focused on telecommunications, technology and manufacturing. He can be contacted at edward.hau@protiviti.com. 

Article from Protiviti’s KnowledgeLeader – www.knowledgleader.com

KnowledgeLeader is a subscription-based website that provides audit programs, checklists, tools, resources and best practices to help internal auditors and risk management professionals save time, manage risk, and add value. Free 30-day trials available.