Outsourced development projects face many of the same obstacles as in-house projects -- in particular, time and cost overruns caused by scope creep, and products that don't meet expectations. Who should take the hit for these problems -- the customer or the contractor?
It's a source of contention that two outsourcers are addressing through agile methodology. The result? Shared risk, more predictability, and products that better meet customer needs through ongoing collaboration.
For Morpheus Ltd., a U.K.-based developer of e-business applications and an IBM Business Partner, the traditional development approach (with a fixed time and price) was too rigid for e-commerce projects that can change frequently in response to market changes.
"E-commerce designs are constantly changing, and they're difficult to manage," explained Joanna Read, marketing director at Morpheus. "We'd price it at one point in time, and three months later the project doesn't resemble that."
Typically, she said, a lead technical person would determine the time and effort required, price it, and Morpheus would develop a project plan with milestones and provide weekly status reports to the customer. "It was fairly traditional," she said, "leaving developers pretty much to work on their own unless there was a problem."
However, she said, an engagement required certain data from the customer, and the plan outlined the dependencies and when action needed to happen. "But the data came in in different orders or the pieces wouldn't be tested, and we found it difficult to stick with the plan."
In commerce projects, she added, "you may want to put aside something and work on another request, to be more proactive and fast-moving." And while the price was fixed, "there were really so many unconfirmed areas of development."
"Most classical outsourced models or dispersed models see feature bloat happen significantly," said David West, a senior analyst at Forrester Research. "Why? The customer tends to tends to write down everything they could possibly want … and you end up building software that's bloated and continually point fingers afterwards." West called this is a "wasteful process" where both parties stand to lose. "The most valuable characteristic of an agile project is the ability to deliver nonbloated software," he added.
For its part, Morpheus decided to adopt a hybrid of Scrum. "Our project manager had done Scrum before, and IBM was an advocate of agile," Read said, "It fit nicely with the scale of our projects," which range from short-term to three months, she said.
Morpheus has started doing sprints around time boxes, and the team now includes cross-functional members who are all involved in planning, estimating and prioritizing with the customer.
"We used to nail down the technicality, rather than [ask], 'What does the business want the site to do?' In the past we met with the IT manager and spec'd it out," Read said. Now Morpheus meets with someone from marketing or sales, asks what they want, and separates it into a "wish list" of top criteria and a handful of generic statements about what the site needs to do and the test success criteria.
Then a plan is created, breaking down functionality into time boxes of 10 days each. "Each time box has bug fixing and testing time built in, and at the end the customer knows they will have a certain functionality they can test as a unit on its own, [which] they can sign off on as complete," Read said.
If the client comes back with a change that will require more than five days, it gets put in another time box and the client either agrees to it or decides it's not necessary.
Read added that clients can view the project on an ongoing basis to see what's going on with the code and go through the test site. "The more we can do to be visible to the customer and show progress and give access to the system, the better it is."
More and more, customers are requesting to see business value earlier in a project, according to Alex Adamopoulos, chief operating officer of Exigen Services, a San Francisco-based software outsourcing services company with multiple global delivery centers. With agile methodology, he said, "[customers are] seeing working software more frequently, touching the features, so they can pinpoint immediately if a feature needs to be corrected or needs to be revised."
With the waterfall methodology, he said, "you don't provide views to the end user for longer periods of time."
Exigen follows a variety of methodologies depending on client needs, but Adamopoulos said agile is the predominant approach. "We quickly realized the value of a development methodology that provided near-immediate results for clients, which is something lacking in the outsourcing world."
Traditionally, he said, the outsourcer and the customer would sign a contract and then for every added feature or change, the client would receive a change request form, tacking most costs onto the project. "Agile allows [us], through iterative development, to flag those changes earlier in the lifecycle so changes won't occur as often, and you're building something more likely to be of value to the client," Adamopoulos said.
"We practice exchange requests, not change requests. Customers can exchange priorities of what they want done," he said.
For example, he said, a project is estimated and the customer and project team agree to the top 10 priorities. If a new priority arises, "you reprioritize the 10 so you're not adding an 11th, and you stay within the budget. The essence of an agile sprint in Scrum methodology is you're constantly reprioritizing."
Exigen has dubbed its fixed-price, agile-based application development offering Flex-agility. "We're taking on the estimation risk," Adamopoulos explained. "We ask them to sign up for a fixed price and budget. The key deliverables we define allow customers to exit a project early if a mutually realized business value is achieved. They pay us an exit fee, and they're allowed to save the balance of the budgeted amount. It's a win/win for everyone."
A challenge of moving to this methodology is the higher level of collaboration required from the customer, Adamopoulos said. "That disruption in the environment had many companies initially avoid adopting agile; they don't know if they can sit in a meeting every two weeks looking at software. But once they found they were getting to market faster with a better product, people changed."
The relationship between customers and suppliers has also changed over the past 18 months, Forrester's West said, becoming more of a partnership with shared risks. And with agile, both sides are seeing improvements.
"You're delivering the right software, you've got efficiency, and if you really build a partnership with your supplier you're getting very strong and transparent reporting, which increases trust and allows you to make decisions you may not have made," he said.
Morpheus' Read added, "It's not always about charging the customer, but making them aware of the extra effort. Setting expectations better leads to happier projects all around."