on Fri, 09/01/2017 - 00:33
A traditional waterfall method breaks the workflow down into stages. You complete one phase of the production life-cycle before continuing to the next. The names of the steps are up to you and can vary and are usually tailored to your organization's style or terminology already in use. Make it work for you. The objectives of the waterfall method are to complete one phase before moving on to the next and to have the output from each task feeding into the next so that there's a logical progression of development.
Shown below is a mock waterfall. Next to each point is a brief description of the purpose of each stage. You begin by analyzing your needs and all of the following steps should be completed using what you've already learned/solidified to shape your next step.
1. Analyze needs — Determine and establish the site’s purpose, list how the site supports your goals and see if a site is the best option for you.
2. Collect requirements — Based on your needs and goals, gather, analyze, document and evaluate your site requirements.
3. Create a design — Based on step 2 (requirements) you design your interfaces, workflow, interactions, information architecture and various features you need developed.
4. Develop the site — Based on step 2 (requirements) and step 3 (design) you install, configure, organize, populate, develop, and test your site.
5. Implement the site — Have your site's purpose and role in the company/organization in mind while you manage the changes that it will cause in your organization. This will include preparing your marketing campaign, training your users and configuring your site to go live.
6. Sustain the site- You will need to keep the site updated and if there's a steady stream of new content then that will need managed appropriately. Routine and planned maintenance will keep the site healthy.
The waterfall method creates an ordered project flow which makes it easier to manage. It also makes the initial bid process smoother because your first few steps (finding out your requirements and design needs) provide you with a basis for getting a bid from a contractor, estimating timelines/schedules and planning resources. The bottom line is that if you've done a thorough job with first the requirements then the design then the project development has a pretty good shot of running smoothly.
Also, waiting until all the requirements and design decisions are made before you start putting your plans into action lets you feel out how risky certain requirements are before you're commited to them. Then let developers take over and start implementing. This can save you from realizing too late in the game that certain requirements might extend your project too far past a deadline or raise the price of completion beyond your budget.
There is a potential for trouble in the lack of flexibility. Even if you do a thorough job with the requirements and the design stages what happens if you change your mind? If you need to modify a requirement after development begins (or even delete or add some requirements) then what? This method assumes that once the requirements are finished there will not be any changes. In the real world that is not typical. However, you should at least be able to forsee any major risks associated with your requirements.
Another potential disadvantage is feeling like your wheels are spinning; that your time is spent talking and planning instead of doing. This can add pressure and frustration, particularly if everyone is not on board with the idea(ex:"It's been more than two months and we don't have a site.") Time spent laying the groundwork for a project isn't necessarily time wasted though. Sometimes it simply takes a few months to understand what you want out of your site and to firm up a consensus with the project investors etc. This kind of foundation increases the liklihood of you getting the funds and approval you will need to actually develop the site. However, some believe that you can't forsee everything you will need upfront so it is a waste of time to plan a site too meticulously seeing as how the plan will inevitably change. While this is somewhat true, your big picture "needs and wants" as they pertain to your site will probably remain consistent from the project's inception to its completion.
The specifications and precise details may change/vary but that's not an obstacle in scoping out the major functionality of the site. Ideally, you can reduce these kinds of risks by involving everyone who will ultimately be responsible for the implementation of your collective vision (designers and developers) in the requirements and design phases. Joint application design/development (JAD) sessions are meetings with responsible parties and stakeholders all in one location in order to present the requirements and their respective justifications. In these forums potential plans and solutions are explored and debated. When you bring together your best team members Your best shot for having the best solution comes from combining your best team members involved in the planning phase (instead of hearing a great idea when it's too late to use it.)