Create your own Hybrid Project Life Cycle

There are various project life cycle approaches in use for projects. All of these have their own pros and cons. So process should be picked after analyzing these pros and cons from project perspective. But it might be possible that none of the existing approaches are actually catering to all of your project or Organization requirements. Hence, it is also very much possible to mix more than one approaches, may be in different phases of project or in different activities. Many of the projects are executed with hybrid approaches. To understand this, let us first understand about most popular approaches in brief.

Waterfall Approach
It is one of the most used approaches for projects till now. It is in use since long. The approach suggests to plan for the whole project requirements in one go i.e.

• Collect all requirements
• Analyze and freeze the requirements
• Do analysis and design for complete functions
• Plan and Schedule the tasks for whole project
• Complete the construction
• Execute the testing of all functions
• Fix the issues
• Make the project live
• Perform Maintenance activities

So you would see, it is a sequential approach to perform and complete all activities for a project going through conception, Initiation, Analysis, Design, Construction, Testing, Deployment to production and then Maintenance. Waterfall model comes from manufacturing and construction industries initially. Then it later adopted for software development also. And it actually worked well initially. It performs well for projects with comparatively stable requirements. 

Points in favor of this approach are that it give emphasis to complete the work for each phase with utmost perfection. It asks to design the system perfectly in design phase itself to avoid any restructuring later which can cost lot of money due to changes at large scale. It advocates to close the requirements in first phase itself, to avoid the changes later in project life. Due to these reasons, it results into a very stable project life cycle, easy to predict - plan - and budget. So it is good for budgeting also. It emphasize of documentation for each phase of project, and hence helps in creating the rich knowledge base. This remove the risk of loss of knowledge if any key member or members leave the project.

However points against this approach are that - with the changing world, requirements are no longer considered as constant and hence these can not be freeze in one go. These are expected to change and actually bound to change even with project life cycle. So we can not design or plan everything in advance with initial phases. We can only try to define the basic framework of whole project depending upon broad set of requirements initially. Project life cycle have to has the scope to incorporate changes. With long duration of project implementation, business requirements change with time. So if we follow water fall model, we can not change the design and hence project will not be as per the business requirements. Or budget and planning will be changed. At this point, Water fall model fails. Secondly, water fall advocates a lot of documentation which actually turns into overhead many a times with comparatively lesser benefit. Documentation is certainly required for project, but it can be reduced to a level which is actually required for maintaining and passing the knowledge in project.

XP Approach

Extreme Programming approach is an iterative approach. It advocates to break the work in smaller pieces of  work items which can be implemented in 3 weeks or lesser time. These work items are called stories. These stories are assigned to developers then. Two developers work on one story on single machine. Working in pair reduce the scope of error and also helps in keeping the implementation simple because one has to explain other. These developers do not go in detail for whole project, rather focus on the story in hand. Focus is to test the outcome after each iteration. So XP goes for an extensive suite of test cases.  Every implementation is accompanied with a test case which can test the implementation. Test cases are given preference even over implementation and hence work start with this. Continuous integration environment is highly recommended in XP to check the sanity of developed code quickly and to find and fix the errors ASAP.

This approach helps to produce the deliverable in smaller time and hence facilitate quick feedback from business users on the product. Hence it gives the chance to change or introduce the requirements after each iteration. It also helps in finding the errors quickly and hence reduce the overall time in correcting these. Small iterations also reduce the complexities. Being an iterative approach, requirements can be amended anytime.

Points against this approach could be, as developer focus only on the story in hand - that could lead to gap in overall project implementation. If iterative approach is not implemented properly, it could result in major design changes due to gap in analysis. If changes comes at later stage in requirements and hence in design, that could be costly. So a good experienced analysis is very important. 

RUP Approach

RUP is formally an iterative methodology. But actually it goes like waterfall model in requirements gathering, analysis, design phase. It advocates to define the design properly and then enters in implementation phase with iterative approach. By gathering the requirements properly, and with extensive well analyzed design, it increase the possibilities of a product aligned with requirements with reduced risk in implementation phase. As implementation goes in iterative manner, so it still utilize the benefits of being iterative by having quick feedback on outcome, by correcting mistakes early and by having scope to have changes in requirements. RUP  focus on mitigating the risk by implementing the risky portion of project first. It enables to identify the risk early and then solve these.

These are few of the popular approaches. It is hard to say which approach is good. There are long discussions with pros and cons of each of these methodologies. However, you can choose one based on your project requirement. A hybrid approach also do well. We ourselves have used a hybrid of XP and RUP in our projects. Like: 

• A broad set of requirements, analysis, and design - from RUP
• Listing of all requirements in term of stories - from XP
• Planning the sprints by picking some of the features with team - from SCRUM
• Test cases for each feature - from XP
• Continuous Integration Environment - from XP
• Retrospective meetings - from SCRUM
• Introduction of new requirements or change in existing requirements with each new sprint, as required by  Product Owner - from SCRUM
• and so on.. 

And it worked wonderfully for us. We have got very good results with both small and big teams, and with geographically distributed teams also. Create your own hybrid approach. Understand what your project is about, what it needs, what your clients needs, know about your team, and then understand the pros and cons of each of these processes and pick the best from these approaches. That would be the right process for your project. Give it a try..

People who read this post also read :