Last week we talked about Project Plans and the SDLC and touched on the waterfall model of project plans. In case you missed the first post you can read it here. This week we will talk about other project plan models…
The fountain model recognizes that although some activities can’t start before others — such as you need a design before you can start coding — there is a considerable overlap of activities, if you plan for them, throughout the development cycle. Recognizing this, and planning for this accurately, helps keep the project on track.
The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It’s actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the project as the business users envision the final product. This model recognizes the importance of the involvement of the business users throughout the process is what is crucial for a successful project completion.
Build and fix is the crudest of the methods. Write some code, and then keep modifying it until the business user is satisfied. Since this method is without any planning, it is very open-ended and can be risky. And, if you do not have a proper project management plan, appropriate change controls, and appropriate management reporting tools available to you in the development process, whichever model you follow, it can potentially deteriorate into this model.
In the rapid prototyping (sometimes called Rapid Application Development (or RAD)) model, initial emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness. The prototype is an essential part of the business requirements phase, and may be created using tools different from those used for the final product. Once the prototype is approved, it is discarded and the real software is written. The benefit of this model is that the business users can see a prototype early on — it gives developers and business users a tangible product in which both will know they are on the same page before coding begins. It vastly reduces the number of changes required towards the end of the project during UAT.
The incremental model divides the product into builds, where sections of the project are created and tested separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested soon after it is written. The drawback of this model is that it requires a high level of business user input.
The synchronize and stabilize method combines the advantages of the spiral model with technology for overseeing and managing source code. You establish periodic release dates for code. At some point before each release, specifications are frozen and the remaining time is spent on fixing bugs only — no new changes are introduced until the system is stabilized. In the event that prior to a release date that some functionality is not ready, it is dropped until the next release date. In this model, the schedule is kept strictly, and functionality is deferred to the next release cycle.
Recognizing which model is best suited to your particular project, and creating a project plan appropriately will yield a tool in which you can manage your project most effectively and responsively.
What model do you find most effective? Why?
Are there any models we have not mentioned that you have found successful?
Article by Carol Donohue
