Which Life Cycle Is Best for Your Project?

October 22, 2008 | Author: PM Hut | Filed under: Project Management Best Practices

Which Life Cycle Is Best for Your Project?
By ExecutiveBrief Staff

Which life cycle will work best for your project? This is an important strategic question because making the wrong choice could lead to disastrous results of catastrophic proportions. Think about delayed deliveries, unhappy clients, project overruns, and canceled projects.

During the 80’s and early 90’s, the waterfall model was the de-facto in project delivery. With the rapid pace in software development and popular use of the Internet, many companies started shifting to more flexible life cycles such as the iterative, incremental, spiral, and agile. These new life cycle methods provide more flexibility and support fast-paced development, giving companies the edge in delivering “the first” in the industry. To date, there are dozens of life cycle methods available to choose from, each having its own advantages and disadvantages.

Here are some of the more popular life cycles:

Waterfall

This traditional life cycle method has been around for decades and has proven its ability to deliver. In fact, the US Department of Defense was actively promoting the use of this method in all its projects when it published Standard 2167A in 1998.

Waterfall is defined as a sequential development model with clearly defined deliverables for every phase. Many industry practitioners are strict in performing audit reviews to ensure that the project has satisfied the input criteria before continuing to the next phase.

The standard phases of waterfall are shown in the diagram below:

Standard Phases of the Waterfall Life Cycle

Iterative, Incremental

The main objective of iterative development is to build the system incrementally, starting from basic partial system features and gradually adding more features until the entire system is completed. Compared to waterfall, iterative development allows flexibility in accommodating new requirements or changes thereof. It also provides room for improvement in succeeding iterations based on lessons learned from previous iterations.

The diagram below, courtesy of Microsoft’s MSF, clearly shows how iterations are scheduled and delivered:

Iterative Life Cycle

Agile

Agile methodologies arose from the need to develop software applications that could accommodate the fast-paced evolution of the Internet. Agile is, in some way, a variant of iterative life cycle where deliverables are submitted in stages. The main difference is that agile cuts delivery time from months to weeks. Companies practicing agile are delivering software products and enhancements in weeks rather than in months. Moreover, the agile manifesto covered development concepts aside from the delivery life cycle, such as collaboration, documentation, and others.

The diagram from Microsoft MSF shows the various components of an agile life cycle:

Agile Life Cycle Components

Other Variants

There are more life cycle methods and methodologies being practiced including Test Driven Development, RUP, Cleanroom, and others. However, all these life cycles can be generally classified into waterfall–being sequential, with clear and strict cut-off between phases; as well as iterative or agile–being repetitive with flexible cut-off rules.
Here are some questions you need to get answers to before deciding on which life cycle method to use:

How stable are the requirements?

One of the biggest factors that dictate your choice of a life cycle method is the clarity and stability of the project requirements. Frequent changes in requirements after the project has started can derail your progress against the plan. In such cases, choose agile or iterative approach because each provides an opportunity for you to accommodate new requirements even after the project has started. On the other hand, if you are engaged in a more traditional project development where there is a stiff rule on ensuring complete set of requirements before going on to the next phase, waterfall would be your choice.

Who are the end-users of the system?

Spend some time to know the users and stakeholders. Who are they? Are they dispersed or controlled group? How can they influence the project?  A controlled group of end-users who greatly influence the project can help you define requirements and manage changes. This means you can achieve stability on project requirements and allow you to use the waterfall approach.

On the other hand, if the end-users are dispersed, you are likely to have a wide range of requirements which you can’t define until the end-users have used the system and started requesting for new features. This situation is typical in product development. For example, Google started Gmail and all its products such as Google Docs, Calendar as BETA because they wanted to know the reactions of the end-users and improve the features based on their feedback. Microsoft, the developer of the world’s most popular software–Windows and Office–also applies agile in their development methodologies. Recently, the Microsoft Solution Framework (MSF) adopted the agile approach. According to MSF for Agile Software Development, “Small iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans. Each iteration should result in a stable portion of the overall system.” Microsoft and Google choose to be more agile because they have a very dispersed group of end-users.

Is the time line aggressive or conservative?

Experienced managers will solve aggressive time lines by negotiating and cutting down project deliverables. An iterative approach helps achieve this by giving opportunities to deliver partial functionalities early. This gives an impression that the project is delivering despite an aggressive time line–generally referred to as “quick wins.” While the overall project delivery is not shortened, there is an opportunity for you to satisfy your stakeholders by delivering key features that are necessary. If your project is not time- sensitive and end-users can wait for the release of the system, waterfall would be a workable approach.

What is the size of the project?

Large enterprise projects generally require large number of project teams to work on clearly defined deliverables. The scale of the deliverables is proportional to the size of the project team assigned to do it. Thus, larger project teams are assigned larger set of deliverables which need to be clearly defined. With this kind of scenario, long iterations or waterfall would be more ideal.

Where are the project teams located?

If you have several project teams located in different geographic locations, coordination of work needs to be more detailed and stringent. Work assignments need to be well-defined to avoid confusion and redundancy of work. In such cases, Waterfall is likely more beneficial as it provides clear-cut deliverables and milestones. Applying the agile approach on geographically separate teams may introduce new challenges. As noted by Martin Fowler, a well-known agile evangelist, “Because agile development works best with close communication and an open culture, agilists working offshore feel the pain much more than those using plan-driven approaches.”

What are the critical resources?

Some projects require involvement of unique, skilled resource or integration with highly specialized equipment. In cases where such resources are not immediately available and require planning, the project team must ensure that the resource is fully utilized during its scheduled use. Moreover, tests must be performed on all possible scenarios during the resource’s available time. Otherwise, requesting for another schedule of the resource may entail project delays. In such cases, waterfall may be a better approach where each milestone must be completed before proceeding from one stage to the next and you are assured that the critical resource is well utilized.

© ExecutiveBrief 2008

ExecutiveBrief, the technology management resource for business leaders, offers articles loaded with proven tips, techniques, and action plans that companies can use to better manage people, processes and tools – the keys to improving their business performance. To learn more, please visit: http://www.executivebrief.com.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

Related Articles

6 people have left comments

Very well written article, so easy to understand.
Thanks for sharing the wealth of knowledge!

Sushma

sushma katepalli wrote on August 18, 2010 - 3:49 pm | Visit Link

This is an excellent, clearly written, useful conparative article on PM appraches/models.
Thank you.
Collette M

Collette Morton London UK wrote on September 15, 2011 - 7:13 am | Visit Link

Engineers of one sort or another have been managing projects for at least 5000 years.
Why do IT people believe they have to teach the world how to………..do anything? This is arrogant.
PRINCE was their first orchestrated attempt (in the UK) to tell us how to manage projects. It doesn’t work very well!
Here we go again!
Projects should be based on a Work Breakdown Structure (WBS).
That WBS should be PRODUCT based - NOT Life-cycle based.
The life-Cycle is important.
But less important than the basic project management approach. So get that right first. THEN start talking about the right life-cycle to use.

Ned Robins wrote on September 27, 2011 - 6:38 am | Visit Link

Comment to Ned: I think you are missing the point about the need for Agile. Certain projects can not create a WBS as the activities are too hazy. This applied to IT or any other type of company. A company may know their overall outcomes or a business driver and some basic deliverables, but that is about it. In the instance of MS or Google - they are simply going to develop what the feedback to their beta versions tells them to develop - to respond to users. So these activities can not be put into a WBS in advance.
A WBS can only be created when you have Business Drivers, and Project Mandate and Brief … etc. By the time you have these the project approach should already have been decided.
You are correct about engineers managing projects for 5000 yrs - often very badly, often well. A PM methodology will never tell an engineer ‘how’ to engineer, but will just control the outputs and quality for the benefit of all. PM methodology is not just for IT. The principles of good Project Management can be applied in all aspects of life - even personal life, so to think PMs are sticking there noses in where they are not needed is ill informed. For example, communication skills learnt can help with friends and family.

Phil Phelan wrote on October 17, 2011 - 8:43 pm | Visit Link

Excellent article, as kick off to my new career in business analysis.
s.

Shane Kouyzer wrote on October 26, 2011 - 1:05 pm | Visit Link

Even EU grant projects are using Agile approach with end user in mind. Quality of products must be in line with end customer, for who the project is financed.
I belive that project life cycle is a question of strategy and it must be choosen before WBS.

Very good article. All the best.

Enver Rakovic wrote on February 15, 2012 - 10:13 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories