Project Lifecycle Models: How They Differ and When to Use Them

Business eSolutions provides System Development Project Management services, Problem Project Diagnostic and Recovery services and Project Management Training and Facilitation courses covering strategy, project management, project estimating, business requirements, risk management and quality assurance. We can help you define a lifecycle methodology customized to your organizational strengths and development risks. Our mission is to help our clients produce quality systems on time and on budget.

Project lifecycle models are not interchangeable. To deliver a quality system, it's critical to know the risks facing your project and to use a model that reduces those risks. The following describes standard project lifecycle models, and reviews their strengths and weaknesses. These standard models can be adapted to fit the industry issues, corporate culture, time constraints and team vulnerabilities which comprise your environment. Contact Us to help.

Pure Waterfall • Spiral • Modified Waterfall • Evolutionary Prototyping • Code-and-Fix

Staged Delivery • Evolutionary Delivery • Design-to-Schedule • Design-to-Tools • Off-the-Shelf

What model do you use? Or, more appropriately, what model should you be using? Here's a summary to help you decide.

Pure Waterfall

This is the classical system development model. It consists of discontinuous phases:

      1. Concept
      2. Requirements
      3. Architectural design
      4. Detailed design
      5. Coding and development
      6. Testing and implementation
Strengths
Weaknesses
  • Minimizes planning overhead since it can be done up front.
  • Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff.
  • Inflexible
  • Only the final phase produces a non-documentation deliverable.
  • Backing up to address mistakes is difficult.
Pure Waterfall Summary
The pure waterfall performs well for products with clearly understood requirements or when working with well understood technical tools, architectures and infrastructures. It's weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.		 Return to top

 

Spiral

The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks. After major risks have been addressed, the spiral model terminates as a waterfall model. Spiral iterations involve six steps:

      1. Determine objectives, alternatives and constraints.
      2. Identify and resolve risks.
      3. Evaluate alternatives.
      4. Develop the deliverables for that iteration and verify that they are correct.
      5. Plan the next iteration.
      6. Commit to an approach for the next iteration.
Strengths
Weaknesses
  • Early iterations of the project are the cheapest, enabling the highest risks to be addressed at the lowest total cost. This ensures that as costs increase, risks decrease.
  • Each iteration of the spiral can be tailored to suit the needs of the project.
  • It is complicated and requires attentive and knowledgeable management to pull it off.
Spiral Summary
For projects with risky elements, it's beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-risk-based lifecycle.

Return to top

 

Modified Waterfall

The modified waterfall uses the same phases as the pure waterfall, but is not done on a discontinuous basis. This enables the phases to overlap when needed. The pure waterfall can also split into subprojects at an appropriate phase (such as after the architectural design or detailed design).

Strengths
  
Weaknesses
  • More flexibility than the pure waterfall model.
  • If there is personnel continuity between the phases, documentation can be substantially reduced.
  • Inplementation of easy areas do not need to wait for the hard ones.
  
  • Milestones are more ambiguous than for the pure waterfall.
  • Activities performed in parallel are subject to miscommunication and mistaken assumptions.
  • Unforseen interdependencies can create problems.
Modified Waterfall Summary
Risk reduction spirals can be added to the top of the waterfall to reduce risks prior to the waterfall phases. The waterfall can be further modified using options such as prototyping, JADs or CRC sessions or other methods of requirements gathering done in overlapping phases. 		Return to top

 

Evolutionary Prototyping

Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration.

Strengths
  
Weaknesses
  • Customers can see steady progress.
  • This is useful when requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements, or when no one fully understands the application area.
  
  • It is impossible to know at the outset of the project how long it will take.
  • There is no way to know the number of iterations that will be required.
Evolutionary Prototyping Summary
The manager must be vigilant to ensure it does not become an excuse to do code-and-fix development.		 Return to top

 

Code-and-Fix

If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.

Strengths
  
Weaknesses
  • No time spent on "overhead" like planning, documentation, quality assurance, standards enforcement or other non-coding activities.
  • Requires little experience.
  
  • Dangerous.
  • No means of assessing quality or identifying risks.
  • Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out.
Code-and-Fix Summary
Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes. 		Return to top

 

Staged Delivery

Although the early phases cover the deliverables of the pure waterfall, the design is broken into deliverables stages for detailed design, coding, testing and deployment.

Strengths
  
Weaknesses
  • Can put useful functionality into the hands of customers earlier than if the product were delivered at the end of the project.
  
  • Doesn't work well without careful planning at both management and technical levels.
Staged Delivery Summary
For staged delivery, management must ensure that stages are meaningful to the customer. The technical team must account for all dependencies between different components of the system. 		Return to top

 

Evolutionary Delivery

Evolutionary delivery straddles evolutionary prototyping and staged delivery.

Strengths
  
Weaknesses
  • Enables customers to refine interface while the architectural structure is as planned.
  
  • Doesn't work well without careful planning at both management and technical levels.

Evolutionary Delivery Summary
For evolutionary delivery, the initial emphasis should be on the core components of the system. This should consist of lower level functions which are unlikely to be changed by customer feedback.

Return to top

 

Design-to-Schedule

Like staged delivery, design-to-schedule is a staged release model. However, the number of stages to be accomplished are not known at the outset of the project.

Strengths
  
Weaknesses
  • Produces date-driven functionality, ensuring there is a product at the critical date.
  • Covers for highly suspect estimates.
  
  • Won't be able to predict the full range of functionality.
Design-to-Schedule Summary
In design-to-schedule delivery, it is critical to prioritize features and plan stages so that the early stages contain the highest-priority features. Leave the lower priority features for later.		 Return to top

 

Design-to-Tools

When using a design-to-tools approach, the capability goes into a product only if it is directly supported by existing software tools. If it isn't supported, it gets left out. Besides architectural and functional packages, these tools can be code and class libraries, code generators, rapid-development languages and any other software tools that dramatically reduce implementation time.

Strengths
  
Weaknesses
  • When time is a constraint, may be able to implement more total functionality than possible when building everything "from scratch".
  
  • You lose a lot of control over the product.
  • You may become "locked in" to a vendor. If it is for long-term functionality, vendor lock-in can become a weak link.
  • May not be able to implement all features desired or in the manner desired.
Design-to-Tools Summary
Consider the tradeoffs of time-to-market versus lock-in and functionality compromises. This may be an appropriate approach for a high-risk element of the overall project or architecture. 		Return to top

 

Off-the-Shelf

Following requirements definition, analysis must be done to compare the package to the business, functional and architectural requirements.

Strengths
  
Weaknesses
  • Available immediately and usually at far lesser cost.
  
  • Will rarely satisfy all system requirements.
Off-the-Shelf Summary
It is critical to know how the desired features compare with the packaged set and if the package can be customized. 		Return to top

 

These standard models can be adapted to fit the industry issues, corporate culture, time constraints and team vulnerabilities which comprise your environment. We can customize a methodology to fit your needs or help you with a special or problem project.

Contact Us with your project needs. We're here to help.

Copyright © JJ Kuhl 2002