Choosing the right SDLC for your project

Choosing the right Software Development Lifecycle (SDLC) methodology for your project is just as important to the success of the project as the implementation of project management best practices. Choose the wrong software methodology and you will add time to the development cycle. Adding extra time to the development cycle increases your budget and is most likely not able to deliver the project on time.

Choosing the wrong methodology can also hinder your effective management of the project and also interfere with the realization of some of the project goals and objectives. Software development methodologies are another resource in the development store’s tool inventory, just as the best practices for your project management tools are in your project manager’s toolkit. You wouldn’t choose a chainsaw to finish the edges of your kitchen cabinet doors because you know you’re not getting the results you want. Choose your software methodology carefully to avoid spoiling your project results.

I realize that not every project manager can choose the software methodology they will use for each project. Your organization may have invested heavily in the software methodology and support tools used to develop their software. There is not much you can do in this case. Your organization will not approve of a request to override a methodology and tools they have spent thousands of dollars on because you are recommending a different methodology for your project. We’ll give you some tips later in this article on how to tailor some methodologies to suit your project requirements. In the meantime, before your organization invests in software development methodologies, you, or your PMO, should be consulted so that at least most projects can benefit from a good match.

This article doesn’t cover every SDLC out there, but we’ll try to cover the most popular ones.


Scrum is more of a name than an acronym (that’s why I didn’t capitalize the letters), although some users have created acronyms and is often used in conjunction with agile software development. Scrum is generally chosen for its iterative nature and its ability to deliver fast-acting software. For these reasons, it was decided to develop new products. In this methodology there is usually no role for a project manager, the 3 main roles are: the scrum master (replacing the project manager), the product owner and the team that designs and builds the system. There is only one role you would be asked if your organization is committed to using this methodology, scrum master. If you should determine that this really is the best methodology for your project, you should rethink your role as a project manager. You can identify a suitable scrum master and return to the bench, or fulfill the role of scrum master.

Scrum is suitable for software development projects where it is important for the project to deliver fast working software. Scrum is an iterative methodology and uses cycles called sprints to build a working system. Requirements are recorded in a “backlog” and a set of requirements is chosen with the help of the product manager. Requirements are chosen based on 2 criteria: the requirement will take precedence over others left in the backlog and the chosen set of requirements will build a working system.

During the sprint, which can last up to 2 to 4 weeks, no changes can be made to the requirements in the sprint. This is one of the reasons that this method does not require a project manager. Requirements management is not necessary because no changes may be made to the requirements under development. All changes must take place in the requirements set in the backlog.

Scrum will be suitable for software development projects where the product is a new software product. By new I mean that it is new to the organization running the project, not in general. The methodology has been developed to meet the need for a method to build software when it is necessary to learn on the fly, not all requirements are known to the organization and the focus is on delivering a working prototype to demonstrate the possibilities. You must be careful in choosing requirements to be delivered in each sprint to ensure that the developed set builds a software system capable of demonstrating the feature set that supports the included requirements.

You should also make sure these requirements are well known and understood as no changes are allowed once the sprint starts. This means that changes to the requirements have to come through a new set of requirements in the backlog, making changes to these requirements very expensive.

This methodology divides the stakeholders into 2 groups: pigs and chickens. The inventors of this methodology chose this analogy based on the story of the pig and the chicken – it goes something like this. One morning a pig and a chicken were walking the road and happened to see some poor children who looked like they hadn’t eaten for days. The compassionate hen said to the pig, “Why don’t we make those kids breakfast with ham and eggs?” The pig said, “I’m not happy with your suggestion. You’re just involved in making breakfast, I’m all for it!” The point here is that the product owner, the scrum master, and the team are all in the “pig” group. Everyone else is in the “chickens” group. If you choose the Scrum method as a project manager, you are in the “chicken” group.


Waterfall methodology requires that each stage of the development cycle be repeated only once. Requirements are collected and translated once into functional specifications, functional specifications are translated once into design, designs are built into software components once and the components are tested once. The advantage of this methodology is the focus. You can focus the efforts of all your analysts on producing functional specifications over a single period of time instead of spreading the effort across the entire project. Focusing your resources in this way also shortens the amount of time that resources are needed. Programmers are not engaged until all functional specifications have been written and approved.

The disadvantage of this approach is the inability to teach the project team anything during the project. An important difference between the waterfall approach and an iterative methodology, such as Scrum or RUP, is the ability to learn lessons from the current iteration that will improve the effectiveness of the team in the next iteration. The waterfall methodology is an ideal methodology to use when the project team has built software systems that are very similar to the one that your project should deliver and have nothing to learn from development that would improve their performance. A good example of a project that would benefit from the waterfall methodology is a project to add functionality to a system the project team built in the not-too-distant past. Another example of an environment well suited to waterfall methodology is a software system maintenance program where a project is planned for specific time periods to improve the system. For example, an order and configuration software system that is expanded every 4 months.

The waterfall method does not lend itself particularly well to projects where the requirements are not clearly understood from the start. Iterative approaches allow the product owners or user community to examine the outcome of building a subset of requirements. Exercising the subset of requirements in the iteration build may cause the product owners or user community to revisit those requirements or requirements to be built. You won’t get that chance with the waterfall method, so you need to be sure of your requirements before starting the construction phase. Translating requirements into functionality is not the only aspect of development that can benefit from an iterative approach. Designing and building the system may also benefit from performing these activities iteratively. You should use the waterfall method if your team is familiar with the system being developed and the tools used to develop it. You shouldn’t use it when you first develop a system or use a completely new set of tools to develop the system.


The Rational Unified Process, or RUP, combines an iterative approach with use cases to guide system development. RUP is a methodology supported by IBM and IBM provides tools (e.g. Rational Rose) that support the methodology. RUP divides the project into 4 phases:

1. Initial Phase – Produces high level requirements, business case and use cases

2.Cooperation phase – produces sophisticated use cases, architecture, refined risk list, refined business case and project plan

3. Construction phase – produces the system

4. Transition phase – changes the system from development to production

RUP also defines 9 disciplines: 6 technical disciplines and 3 supporting disciplines: configuration and change management, project management and environment, so it is intended to go hand in hand with best practices for project management.

Iteration is not limited to a specific project phase – it can even be used to guide the initial phase, but mainly applies to the construction phase. The project manager is responsible for a general project plan defining the products to be delivered for each phase, and a detailed iteration plan that manages the results and tasks associated with each phase. The purpose of the iterations is to better identify and mitigate risks.

RUP is essentially a cross between Scrum and waterfall in the sense that it only applies an iterative approach to project stages where the most benefit can be obtained. RUP also emphasizes the architecture of the system being built. The strengths of RUP are its adaptability to different types of projects. You could simulate some aspects of a Scrum method by iterating all 4 stages, or you could simulate the waterfall method by choosing to avoid iterations altogether. RUP will be especially helpful to you if you are some familiar with the technology but need the help of use cases to clarify your requirements. Use Cases can be combined with storyboarding when you develop a software system with a user interface to simulate the interaction between the user and the system. Don’t use a RUP if your team is well acquainted with the technology and system being developed and your product owners and users don’t need use cases to clarify their requirements.

RUP is one of those methodologies in which your organization is likely to have invested heavily. If that’s your situation, you probably don’t have the authority to choose a different methodology, but you can adapt RUP to suit your project. Use iterations to eliminate risks and unknowns that arise from your team’s unfamiliarity with the technology or system, or eliminate iterations where you would otherwise use the waterfall method.


Joint Application Development, or JAD, is another methodology developed by IBM. The main focus is on capturing and interpreting requirements, but can be used to manage that phase in other methodologies such as waterfall. JAD gathers participants in a space to articulate and clarify requirements for the system. The project manager is required for the workshop to provide background information on the project goals, objectives and system requirements. The workshop also requires a facilitator, a writer to record requirements, participants contributing requirements, and members of the development team who aim to observe.

JAD can be used to quickly clarify and refine requirements as all players are gathered in one room. Your developers can avoid misunderstandings or ambiguities in requirements by questioning the participants. This method can be used with almost any software method. Do not use it in places where the needs of the organization are not clearly understood or on large, complex projects.


RAD is an acronym for Rapid Application Development and uses an iterative approach and prototyping to accelerate application development. Prototyping starts with building the data models and business process models that will define the software application. The prototypes are used to verify and refine the business and data models in an iterative cycle until a data model and software design are refined enough to begin construction.

The goal of RAD is to enable development teams to create and implement software systems in a relatively short time. It does this in part by replacing the traditional methods of requirements gathering, analysis and design with prototyping and modeling, the prototyping and modeling enable the team to prove the application components faster than traditional methods like waterfall. The advantage of this method is that it allows for rapid development by eliminating design overhead. The downside is that by eliminating design overhead, it also eliminates much of the safety net, preventing requirements from being misinterpreted or missed altogether.

RAD is suitable for projects where the requirements are reasonably well known in advance and the data is an industry or company standard, or already exists in the organization. It is also suitable for a small development team, or a project where the system can be broken down into individual applications requiring small teams. RAD is not suitable for large, complex projects or projects where the requirements are not well understood.


Lean Software Development, or LSD, applies the manufacturing world’s waste reduction principles to software development. The goal of LSD is to produce software in 1/3 the time, 1/3 the budget, and 1/3 the flaws of comparable methods. Lean does this by applying 7 principles to the pursuit of software development:

1. Eliminate waste

2. Reinforce learning (both technical and business)

3. Decide on requirements as late as possible

4. Deliver as soon as possible

5. Give the team more options

6. Build integrity

7. View the whole

While Lean Manufacturing has been around for a while, its application to the software development process is relatively new, so I wouldn’t call it a mature process.

LSD would be a suitable method to use if you have a subject matter expert in the method who has some hands-on experience applying lean methods to a software development project. “Reinforced” learning means that your development team has a deep understanding of the software tools provided, as well as a broad knowledge that includes an understanding of the customer’s business needs. LSD would be suitable for a project where the development team has these properties.

LSD relies on fast turnaround time and late completion of requirements to eliminate most change requests, so it is not suitable for a project where delayed completion of requirements has a low probability of eliminating change requests, or the size and complexity of the system to be developed would prevent a rapid turnaround.

Extreme programming (XP)

Extreme programming emphasizes the ability to accommodate changes in requirements throughout the development cycle and testing so that the code produced is of high quality and has a low failure rate in the field. XP requires developers to write concise, clear, and simple code to troubleshoot problems. This code is then rigorously tested through unit tests to ensure that the code works exactly as the programmer intended and acceptance tests to ensure that the code meets customer needs. These tests are accumulated so that all new code passes through and the chance of a failure in the field is reduced.

XP requires the development team to listen carefully to the needs and requirements of the customer. Uncertainties are cleared up by asking questions and providing feedback to the customer clarifying the requirements. This ability implies a degree of familiarity with the client’s business; the team is less likely to understand customer needs if they don’t understand their business.

XP’s intent is to improve coding, testing and listening to the point where there is less dependence on design. At some point, it is expected that the system will become sufficiently complex that it will require design. The intent of the design is not to ensure that the coding is tight, but that the various components fit together and function smoothly.

XP would be a suitable software development method where the development team has knowledge of the client’s business and the tools to run the level of testing required for this method. Tools include automated testing and reporting tools, problem recording and tracking tools, and multiple testing platforms. Developers who are also business analysts and can translate a requirement directly into code are a necessity because design is more architectural than detail. This skill is also required because developers implement changes directly to the software.

XP is not suitable if the development team is not experienced in business analytics and where testing is done by a quality assurance team rather than the development team. The method can work for large complex projects as well as simple smaller projects.

There is no law requiring you to choose one of these methodologies for your software project. The list I have given you here is not a fully comprehensive list and some methodologies are not on it (eg Agile), so if you think there is another methodology that fits your project better, go ahead. You should also look at combining some of the features of each of these methods to create a custom method for your project. For example, the desire to eliminate waste while developing software applies to any method you choose, and there is likely to be waste that can be eliminated in any development store.

Make sure to choose a methodology that is a good fit for your team, stakeholders and client, as well as your project. It’s not a good idea to introduce a new development methodology that your team will struggle to learn while trying to meet tight deadlines. On the other hand, if you have the leeway, you may want to learn a new method with your project.