Why Software Development Projects Fail, Part III: Methodology
This series of five articles takes a closer look at software development, the reasons for failure and how to avoid them.
The previous article in this series dealt with the importance of project requirements. Once you have that nailed down, it is time to select the development methodology. While there are many different methods to choose from, each of which does work, picking the wrong one for a particular project could cause it to stall or, worse, fail.
Project managers have several different methods to choose from when selecting a software development model. One early method, which is still in use, is called the waterfall model. In 1970 Winston Royce, who worked on space mission planning software in the 1960s, described this method in a technical paper titled Managing the Development of Large Software Systems. The waterfall method consists of seven steps: requirements specification, design, coding, integration, validation, installation and maintenance. In this model, each step is fully completed before moving on to the next.
The advantage of waterfall development is that the requirements and design are finalized before moving into coding, which saves time later in the process. The disadvantage of waterfall is, in most cases, it is difficult to fully conceive of the end product before development and testing begins to take place.
Large, heavily regulated organizations, such as in banking and insurance, are more conditioned to traditional waterfall: move everything from point A to point B and dont move on until everyone is at point B, said Jeff Monteforte, co-founder of Exential, an IT management consulting firm in Cleveland, Ohio. Waterfall matches that type of a culture and organization.
To overcome the slow pace of waterfall, several iterative approaches were created. The spiral model, developed by software engineer Barry Boehm while working for TRW in the 1980s, involves building a series of prototypes. It starts by defining an initial set of system requirements, creating a preliminary design and then a prototype. That first prototype is then tested and evaluated, and the requirements, design and construction phases are repeated to create a second prototype. The process is again repeated to create an operational prototype and finally a release product.
Both waterfall and spiral development models are suited for large and lengthy projects. For faster results there is agile development which started gaining popularity in the 1990s. Agile development is typically done by small, multidisciplinary teams that put the software through a number of rapid iterations. This method makes it easier to respond to changes in requirements, but may not be suited to larger, mission-critical projects.
When you have a small rapidly growing company that is doing a lot of work over the Web, their expectations for incremental functionality and value is so high, you have no choice but to do iterations or agile programming, said Monteforte.
The basic waterfall, spiral and agile models each have a wide variety of offshoots and variations designed to meet different specific needs. "All these are great techniques, said Monteforte. It is a matter of matching up the right techniques to the right situation, client, culture, priorities and expectations.
Mix and Match
So, how do you select the best method for a specific project? The choice depends on a number of factors including the stability of the requirements, whether your team is in one location or distributed, and the size of the project. But there are some general guidelines: when the specifications are likely to change, agile programming works best; when there is a formal and procedure-based customer culture (such as government or military), use waterfall; product development tends to use a spiral approach. But these methods can overlap, such as using iterations and daily planning in a waterfall project, or thoroughly documenting an agile one.
Every methodology should be considered as a set of techniques, which can be combined and applied differently, depending on your customer and project needs, said Mikhail Bykov, CTO of Luxoft, a Russian application development outsourcer. The best solution here is not to follow some methodology blindly, but understand its strength and reasons, and use them consciously.
Abid Ali Neemuchwala, VP and head of Global Process Excellence at Tata Consultancy Services (TCS), said that while his firm selects the technology in consultation with the customer, there are very well defined guidelines they use to make the final decision.
When the process is mature and requirements are stable, waterfall is more suitable, said Abid. But when you are innovating and developing new business processes, iterative development technology makes more sense.
Jon Hughes, VP, Technology Solutions Group for Robbins-Gioia said in his business the customers often have the method selected before engaging his firm. But there are times that he needs to step in and make a recommendation when they have chosen the wrong method.
We usually comply with what they ask for unless we realize that there is a cultural inhibitor to doing a spiral or agile development that will make it unsuccessful, he said. If someone wants to do a spiral development methodology, but is not willing to commit resources (and) time to periodic reviews, there is a fundamental problem. They should be doing waterfalls.
Luxoft's Bykov likes to talk about a large development project his company completed that involved a complex set of business rules, large amounts of data and a high volume of transactions. "The underlying cause was pretty typical: unstable requirements and long releases. The client worked very closely with us on all details, but numerous changes introduced made project planning nearly impossible.
Luxoft shipped the builds according to the plan, but each took a long time to test and produced a huge number of corrections and enhancements. As the initial deadline approached, it became clear that implementing all the change requests could not be accomplished in the allotted time. This extended the initial time estimate of nine months to 15.
After some hard replanning, we decided to change the project implementation approach to agile, introduce daily builds, and weekly reviews of the results with the customer, said Bykov. It's hard to make such a change in the middle of a project, but it looked like it was the only way to ever get the software into production.
The change produced the desired result. The number of bugs declined and the much shorter iterations inherent in the agile methodology made it easier to introduce enhancements and changes. The initial production version finally was released and Luxoft created follow-up versions of the system later.
The lesson we learned is that mistakes in the choice of development methodology can be very expensive later in the project, said Bykov. It often makes sense to persuade a customer to change their standard approach to something more fitting to the nature of the project.