|
One of the more interesting conversations about software development I had over the past year was with the CIO of a major cruise line, whom I'd been introduced to by a consulting firm that wanted to tell the story of its contributions to a successful agile development project. But to the CIO, the story was less about the success of the methodology than it was about the art of the deal.
The reason I'm not naming either the CIO or the cruise line is that this is one of my botched projects from the past year, originally planned as a feature case study. By the end of my interview with the CIO, I thought I had a great story. But when I got up to leave, the CIO asked me when I would have a copy of my article ready for review by the firm's marketing department. It turned out he thought I was there to write up a marketing piece, rather than a journalistic one, on behalf of the consulting firm that had provided the introduction. He didn't have permission to talk to a reporter, and though I tried to smooth things over with the firm's public relations people, I was never able to convert this into an on-the-record interview.
But there are a few details I'd like to salvage, even if I can't name names. The cruise line was in the process of overhauling its web reservations systems for consumers and for travel agencies, and looked to the agile methodology to help the process go more smoothly. But at first, the development methodology of tight iterations and quick course corrections helped less than it should have because it turned out the developers were getting feedback from the wrong managers and from too low a level within the company.
This was a project about 80% staffed by outside consultants and contractors. So when the CIO brought in a new consulting firm to help him get the project back on schedule, he negotiated a contract that not only gave him the developer manpower he needed but also the negotiating leverage to get the attention of the right people who could give the developers the right direction and feedback.
Here's the deal. While the CIO and his team had done a good job of anticipating the project's technical requirements, they underestimated the creative requirements of the job, CIO says. "We thought the technical infrastructure would be our biggest challenge. And it was a challenge, I don't want to downplay that. But the biggest challenge was the creative part of it -- how to get the right look and feel, and then represent that in code, of course."
One problem was that the developers set out to create a more sophisticated equivalent to the old web site. And the initial feedback they got in review sessions with their business counterparts was that they were on the right track. But when more senior executives got a look at what had been done so far, their reaction was that it wasn't what they wanted at all. They didn't want a new version of the old website; they wanted to deliver a whole new experience, conveying that it would offer users a sense of freedom in the flexibility it offered for booking upgrades, excursions, and other options.
In principle, following agile principles might have headed off such problems in the first place. Development would be organized into two-week sprints, followed by an opportunity for management to provide feedback on the working code delivered in that iteration, rather than working from dry specifications. The process is meant to engage the business team members who ultimately rule on whether a software system matches the company's business needs. Unfortunately, in this case, the more executive decision makers within the company were unavailable for those meetings, so they sent surrogates.
"Yeah, they liked it," the CIO said, but the surrogates didn't have the final say. "We were getting feedback, but it was from the wrong level."
The issues being raised were largely at the level of "look and feel" rather than any deep technical problem, but they still caused substantial rework, he says. And in the middle of the process, the company came out with a new branding initiative that also forced changes in color and imagery choices. "What we had at that point became almost a throwaway."
Realizing he needed more help on the creative side, he brought in design firm to work on wireframes, color palettes, and such. "They had their own methodology that wasn't agile, and really didn't feel comfortable doing it a different way. But still we put pressure on them to work in two-week increments because we needed to get that food chain going," the CIO said. In turn, the business team had to feed requirements to creative team early enough that they could be working about two weeks ahead of the developers. "Managing the business came to be the key piece of success. We had times when we didn't have enough work to do in the iteration because we didn't have the wire diagrams," the CIO said.
Traditionally, the attitude within the company had been more to make the project manager responsible for getting things done. But the project manager couldn't make it happen without that critical business input. "It was really a supply chain, food chain type of activity that needed to be coordinated outside of the realm of the agile development process," the CIO said.
As he worked to tame the consumer web booking engine, the CIO realized he was running out of time on a second web portal for travel agent use, to be built atop the same middleware platform. And he was determined not to let that project fall victim to the same problems. In fact, he wanted to use it to dramatize how much better things would work if the right people were involved from the beginning.
That's where the consulting firm comes into the story. CIO had worked with this firm previously and appreciated its capacity for speed and quality. That was important because the consulting firm would have to deliver its part of the system in about 3.5 months. And although this was more of a wholesale outsourcing arrangement, it would face the same dilemma of needing to get requirements fed from the business and through the creative team to the developers.
CIO figured the best way of getting the attention of the executives was to put money on the line. "We constructed a contract to force behavioral changes in the business," CIO says. The consulting firm made an aggressive commitment to delivering software on time, even in the face of changing and evolving requirements, and there would be monetary penalties if it failed to meet that commitment. But the contract also allowed the consulting firm to charge more if the project got stretched out because cruise line executives were failing to keep its end of the bargain by providing requirements and feedback in a timely manner.
The result was "an unbelievable transformation," the CIO said. "All of a sudden we were getting the right people in the room."
"It was a matter of being able to tell people, 'we're on the clock, so make up your mind,' " agrees the cruise line's director of web systems. "It was a way of providing structure, because it had consequences attached to it. This was a way to monetize the consequences."
Only registered users can write comments.
Please login or register. |
