Academic help online
Centene, Flowserve, and Shaw Industries: Relationships, Collaboration, and Project Success
Managed care provider Centene has just finished deploying a new financial system. CIO Don Imholz says the project, which involved multiple PeopleSoft modules as well as financial planning and reporting software from Hyperion, was completed “very quickly”— in 12 months—and on budget. Imholz believes the project was successful for a number of reasons, including that the company implemented proven technology and hired a systems integrator to help who was experienced with PeopleSoft. Most importantly, Imholz says the project was successful because of “good teaming between the IT organization, the finance organization and the systems integration resources.” In other words, much of the project’s success came down to people skills. The constructive relationship between IT and finance— and in particular, between Imholz and Centene’s CFO, William Scheffel—ultimately kept the project on track when the going got tough. And it did get tough. For example, at one point, the project team was having trouble setting up the technical environment needed to deploy a Hyperion module that a third-party was going to host. The difficulties that IT encountered put the project’s schedule at risk, says Imholz. Had the relationship between IT and finance been acrimonious, the organizations would have pointed fingers at each other—a counterproductive move that would have further delayed the project. Instead, says Imholz, they worked together to recover the lost time and keep the implementation on schedule. “We could have blamed each other and told each other we can’t help,” says the CIO. “But there’s no value in doing that. It delays getting to the solution. If IT or finance tried
to recover the schedule alone it wouldn’t have happened. We had to do it together.” Good relationships—between IT and business partners, project managers and IT staff, and project managers and stakeholders—keep IT projects on track, say IT leaders and project management experts. Bad relationships, however, are a leading cause of project failure. Faced with mounting operational and regulatory pressures, Linda Jojo, Flowserve’s CIO, knew it was time to simplify the company’s entire IT infrastructure—an endeavor that would bring about sweeping changes across an enterprise spanning more than 56 countries. At Flowserve, a world leader in the supplying of pumps, valves, seals, automation, and services to the power, oil, gas, chemical, and other industries, Jojo’s assignment was heavy on IT change as the company sought to update processes and systems: establishing a common IT infrastructure, introducing global help desk capabilities, and cutting dozens of disparate ERP systems. But that didn’t stop her from taking a decidedly business approach to simplifying Flowserve’s IT footprint. “The first step was making sure that this wasn’t viewed as an IT project,” says Jojo. “From our CEO, our leadership team and our board of directors on down, we’ve made sure that this project is something we talk about in terms of its business impact.” It’s a tactic that helped set the scope for a project that could have otherwise become unwieldy. For starters, Jojo helped assemble 35 divisional representatives from across the globe at the company’s world headquarters. Here, holed up in a conference room for 17 weeks, these divisional representatives pored over disparate systems and processes, deciding what was—and wasn’t—worthy of improvement. Throughout this period, Flowserve also called on internal subject-matter experts, from engineers to sales representatives, to offer their in-the-trenches take on the company’s shortcomings. The result: a blueprint for business standards, the design of a common financial chart of accounts, and the creation of a set of data standards for customers and suppliers. In addition to creating project perimeters, Jojo says that by involving business leaders in the critical design phase, she was able to garner widespread support for a companywide strategic business initiative costing more than $60 million over four years. “I’ve seen projects that should have been successful fail purely because of relationship issues,” says Greg Livingston, director of IS planning and system development at Shaw Industries, a flooring manufacturer. On the other hand, when mutual trust exists between IT project managers and stakeholders, “IT project managers are more likely to discuss problems that could threaten the project as they arise,” says Imholz. If bad blood exists between the two groups, project managers may not be inclined to point out those issues, or they may try to cover them up. “If you look at projects that fail, invariably someone on those projects knew things were going bad,” says Imholz. “If you don’t have relationships and trust, those things don’t surface. And when you don’t do something about problems in a timely manner, those problems invariably get bigger. In many cases, minor problems become more serious because they’re not addressed in a timely manner. A culture of openness is absolutely essential to good project performance.” Furthermore, when something does go wrong with a project, business partners are less likely to place the sole blame for them on IT if they respect IT, says Shaw Industries’s Livingston. In fact, they’re more likely to give IT some leeway with the project schedule, he says. “It doesn’t matter what technology you’re using, how talented your technology staff is and how knowledgeable the business partners are on process and business improvement: Every system initiative will have issues,” says Livingston. “If you don’t have a relationship, you resort to pointing fingers as opposed to being transparent and admitting ‘we messed up’ or ‘we didn’t test that as well.’ If you have a good relationship, you’ll sit down and find a way to make it work.” Decisions affecting the project also get made more promptly when everyone involved gets along. “Fast and good decisions are crucial to keeping projects on track,” says Imholz. “The failure of senior people to make decisions means decisions are made at lower levels of the organization. If you have a software developer who’s waiting for a decision on a business requirement, there’s three things that can happen: He can guess what to do and guess right. He can wait for a decision and while he’s waiting he’s not as productive. Third, he can guess and guess wrong. If those are equal possibilities, two-thirds of the time it will be detrimental to the project. And if you stack enough of those decisions on top of each other, it will negatively impact the project.” Despite the positive impact good relationships have on project management, IT project managers rely more heavily on software and methodologies than on building relations when they need to improve their delivery. It’s no wonder: Compared with the time it takes to build relationships, software seems like a quick fix. IT project managers are also most comfortable with tools. Shaw Industries’s Livingston is using Scrum, an agile software development practice, to improve relationships between IT and business partners and ensure project success. With Scrum, says Livingston, business partners meet with IT during a four- to eight-hour planning meeting to look at all the projects in the backlog and to jointly determine which one will bring the greatest value to Shaw Industries. IT then divides the project into sprints—30-day increments of work. When IT completes a sprint, business partners assess IT’s progress and suggest any necessary changes. “The agile development methodology, just by design, promotes better relationships,” says Livingston. “Scrum and Agile force interaction on a more frequent basis. By doing so, IT delivers solutions on an incremental basis to the business, as opposed to the waterfall method, where it’s a year and a half before the business sees the fruits of an initiative.” Livingston says it’s not necessary for IT and other business functions to get along swimmingly for Agile to work effectively. Agile can work even if there’s initial tension between the groups, he says. “We’ve had groups with troubled relationships, and certainly initial meetings are not always effective out of the gate,” he says. “But at least we can agree that we’re going to focus on 15 key items in the next 30 days, and at the end of the 30 days, we’ll get back to you.” The process forces IT and business partners to prioritize projects together and agree on the 15 items IT will complete in 30 days. Scrum also then drives IT’s behavior. At the end of that 30 days, IT has to show something for its work. Scrum makes IT accountable to the business. When business partners see IT making tangible progress every 30 days, their confidence in IT grows. Says Livingston, “If the business partner sees results more frequently than they used to, relationships can get better. Agile promotes better relationships just by forcing a process, forcing interaction.” Between the structure that Scrum imposes and the relationships that grow out of it, project delivery improves. Livingston says Shaw Industries is seeing this happen: “Better collaboration results in better value for the business,” he says.
CASE STUDY QUESTIONS
REAL WORLD ACTIVITIES
1. Why do you think the practices described in the case led to success for these companies?
1. The Scrum approach to project management has become quite popular in recent years. Go online and research other companies that are using it to organize their projects. Have those experiences been positive as well? What can you tell about how the approach works from your research? Prepare a report to summarize your findings.
2. How do they change the structure of projects so that the likelihood of a positive outcome increases?
2. Would the issues discussed in the case be solved by making a business executive the head of any projects involving IT? Why or why not? Break into small groups with your classmates and develop a justification for both alternatives.
3. In the case of Shaw Industries, how did Scrum help?
4. Provide three specific examples from the case, and explain where and how those activities helped the company move their projects along.
5. Using examples from the case and your own understanding of how those worked, can you distill a set of recommendations that companies should follow when managing technology-based projects? Would these be universal, or would you add any limitations to their applicability?
Academic help online