Monumental Challenge

Email this article

To*

Please enter your email address*

Subject*

Comments*

It’s often said that information technology is a field that lives and (too often) dies by the project. Even when a project isn’t dying, it may be weak, sickly, or on life support. Large IT initiatives are difficult to manage and can prove disappointing, if not disastrous. Some progress has been made in recent years as project management has become a bona fide corporate discipline, but the latest statistics on success rates still leave plenty of room for improvement. (The Standish Group says that more than half of all IT projects still run late, exceed budget, or fail to deliver promised benefits.)

Nearly all projects fall into three phases: preproject work to justify the initial need (read: business case), postproject measurement of the project’s overall effectiveness (read: ROI), and, in between, the most difficult phase of all: implementation (read: headaches).

During implementation, the best-laid plans often go awry, as changing needs, scope creep, untold delays, and an inevitable dose of Murphy’s Law conspire to derail the effort at every turn. Yet companies do succeed in bootstrapping themselves into the future, leaving behind outmoded systems and ways of doing business. By following some best practices, project management can become more predictable and less painful, and perhaps even culminate in an outright celebration.

Recommended Stories:

Such was the case for the finance department at Louisville-based Brown-Forman Corp., the $2.7 billion purveyor of Jack Daniels whisky, Finlandia vodka, and other spirits and wines. The company was burdened by a “Neanderthal” cash-management system that required treasury staff to re-key bank information for the company’s numerous subsidiaries into spreadsheets for daily cash positions, and to post accounts-receivable receipts from paper bank statements, among other manually intensive practices. “We had what was essentially a spreadsheet-era treasury system,” says executive vice president and CFO Phoebe A. Wood.

“It’s not that the old system was broken, or that we were losing cash, not paying vendors, or not effectively concentrating cash and putting it to work and paying down our debt,” notes Wood. “All of that happened. It’s just that the processes were very inefficient and labor-intensive, leaving our cash analysts little time to do actual analysis. This severely limited our ability to manage our cash globally. We had cash dispersed to our subsidiaries sitting in various countries and bank accounts that was neither efficiently deployed nor controlled.”

Improving that, Wood says, became a priority — and a major challenge. After executing a comprehensive feasibility study defining the project’s scope and objectives, project managers got the green light to draft a project blueprint. That document encompassed the budget, task list, milestones, and associated change-management issues expected to crop up. The company designated a project leader (assistant treasurer Roger Shannon), created multiple working groups charged with exercising specific types of leadership, partnered with IT and the system’s ultimate users, and established measurable ROI goals.

Who Does What?

All of those steps have been codified in an IT-governance framework that the company has developed over the past four years. Several “process councils” identify process improvements that can be achieved via IT projects, then present them to a steering committee. Projects are prioritized and assessed as to the resources required, then turned over to other teams for actual implementation.

That’s a lot of teams, but Brown-Forman executives say the system gets all relevant parties involved and fosters true collaboration and buy-in. The steering committee includes CFO Wood, the company’s chief investment officer, senior IT representatives, and the project leader. Sometimes it has the sole discretion to greenlight a project, but for particularly resource-intensive efforts approval from the CEO or even the board may be required.

Once a project is approved, it is turned over to a project team, which essentially charts the strategic direction by establishing milestones and determining what role an IT vendor or various consultants will play, as well as addressing the hands-on tasks of reaching each milestone.

Members of a project team typically include staff from within the company, such as senior executives from business units, HR, IT, and communications; comparable representation from the IT vendor; and, in many cases, an outside consultant as well. Since large IT projects are time-consuming, says Margo Visitacion, an analyst at Cambridge, Massachusetts-based Forrester Research Inc., careful selection of project staff is essential. “You’re basically picking internal people whose day job is not the project, so you want to be sure you’re selecting individuals who have both the required skills and the time.” Phoebe Wood agrees, noting that, “You may have a project with a highly desirable payback, but lack the people to do it. You need to take into account all resource issues, including the availability of the right technical and business staff.”

Some companies create a second project team to establish fiscal controls and monitor the budget, track any issues needing resolution, oversee quality assurance, and report the project’s progress to the steering committee. Chris Jenkins, global solutions executive at IBM’s Business Consulting Services office in Dublin, says the team must provide status reports “that are honest and open, even if they’re damning. Both the steering committee and the project committee must be mature enough to understand that things will go wrong. The key is to manage such situations and not point fingers.”

Designating a project team leader is critical. “One project manager assures vision, clarity, and consistency; two managers assures confusion and uncertainty,” says Jenkins. Shannon’s experience in assisting in the implementation of a treasury-management system at a previous employer made him an ideal candidate. He arrived at Brown-Forman in 1997 and immediately saw that the existing cash-management system needed overhauling. When Y2K prompted the company to roll out a major ERP initiative, it considered adding cash management to the mix, but felt that SAP’s module was not ready for prime time. After SAP developed a state-of-the-art treasury system for companies like Colgate-Palmolive and Nike, Shannon felt the technology warranted a second look. “We went and talked with Colgate and, encouraged by what we saw, began work on a feasibility study,” he says.

To manage the implementation, Brown-Forman broke it up into pieces. “We created four distinct phases for the project: blueprinting, realization, final prep, and go-live/support,” says Jaime Ryan, a principal at Media, Pennsylvania-based e5 Solutions Group LLC, the specialty SAP consultancy that assisted Brown-Forman.

During the “blueprinting” stage, Ryan, Shannon, and other members of the implementation team analyzed and documented Brown-Forman’s existing treasury processes, assessing what worked well, what didn’t, and how the company’s approach compared with world-class processes. “We then developed a wish list of business processes that we felt we could achieve with SAP,” Ryan says. “We ended up with about a 90 percent match, and then we brought that to the steering committee to approve.”

The team also performed what Ryan calls “quick configurations” of the new model within the SAP software, and scheduled prototyping workshops where they demonstrated the new processes, minus any custom work. Once this blueprint was approved, the implementation team moved into the “realization” phase — executing the software configurations. “We tried to utilize the configurations that we used during our prototyping sessions, leveraging them as much as possible to save time,” Ryan adds. “Then we built the system for real. At that point we also started the custom software-development work that was needed.”

Talk It Through

When the treasury system was coded and ready, a series of so-called superuser sessions was scheduled. “We tested the system with people who ran the wire desk or the back-office confirmation work,” Ryan explains. “Once we determined that everything was going smoothly and the system had received the end users’ validation, we moved into final prep, which calls for IT to prepare the production system to go live, while the business side prepares the end-user training. The focus of final prep is to get the user community ready to use the system at the same time that the system itself is being prepared.”

During the final preparation stage of any IT project, communication with the end-user community becomes a top priority. “The goal throughout all phases of any type of project is to overcommunicate,” says IBM’s Jenkins. “Consult the user community from the beginning of the project and consistently throughout. In all cases, give them time to digest the change and constant support to minimize the impact.”

The final go-live/support phase, a.k.a. the cut-over, involves transitioning from the manually intensive legacy application to the sleek new software — the old way gets its last hurrah on a Friday, and on Monday morning workers will, in theory, be happily tapping away at the new system. “Over the weekend we load all open contracts and make sure bank balances are accurate — sort of a bleed-over of stuff from the final prep stage,” Ryan says. Both the project and implementation teams stick around after the go-live to provide continued end-user support.

One goal of a phased approach is to limit scope creep. “The project team has to control the staged gates [a set of prescribed activities that must be completed before moving to the next phase],” Jenkins explains. Think of it as “managing by milestone.” As Jenkins says, “Each milestone is the point at which the company confronts the current reality of the project and the possible need to readjust the variables of people, time, and quality. Something often has to give.”

Brown-Forman CIO and vice president Paul Gross says the company examines every project quarterly along two dimensions — the value it creates and the risk it creates (which he defines as organizational change, level of commitment/sponsorship, and technical challenges) — and makes changes as needed. He says the company also conducts a postproject review to evaluate how successful the project team was, and that it is now putting together a system to evaluate projects six months to five years after completion to see how well they met the business objectives.

As for its new finance system, Brown-Forman says early results are positive. “We’ve reduced the total workforce associated with our cash-management processes by 60 percent and the resources required to manage our daily cash application and payments by 81 percent. And we’ve lowered the person hours required for month-end closing from 48 hours to 1,” says CFO Wood. “Moreover, the project came in on time and on budget. For any project, that alone is pretty good.”

Russ Banham is a contributing editor of CFO.

A Postproject Reality Check

Project consultancy Technical Pathways offers these simple yardsticks to determine whether or not an IT project can ultimately be deemed successful by all parties involved:

For users:
Ease of implementation and training
Ease of use
Ease of maintenance
Enthusiastic acceptance

For the company:
On time
Within budget
According to plan
Verifiable ROI or similar metric(s)

For those who worked on the project:
Functioned as a true team
Concluded with a sense
of accomplishment
Individual contributions
properly acknowledged