Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I have heard of PRINCE2, PRISM, and many other methodologies. I'm not sure if the waterfall model is actually a project management methodology or not. My project is based on research (Example, mobile selection using weighted scoring model and total cost of ownership).
Is the waterfall model a suitable methodology to implement it? If not, what methodology should I use?
If you are working alone, a software development methodology might be a bit expensive (time and additional research) for you, because the currently available methodologies were developed for teams which are cooperating and the need some ground rules in order to that. If you are working alone, you cannot really cooperate. My advise is cherry-pick those techniques which may bring your research further.
You mentioned in a comment that the research you are working on is a college assignment, which most probably has a deadline. Let's say the deadline is in 6 months and the result of the research is a document and a presentation.
Using an iterative approach, you schedule 5 appointments with your teacher - one in every month - where you discuss the current progress with him (status meeting from waterfall). It is important that you always bring the recent draft version of the document to the discussion (working code from XP). Together you check your findings and progress and set the goals for the next session (planning meeting from scrum). Plan your work for 5 months and use the last month as a buffer for unforeseen work items and creating the presentation (planning with buffers from classical project management).
The frequent feedback and discussion with your teacher will ensure that your research is going into the right direction and on the other side, it will put some healthy pressure on you from the beginning so that you won't start working on it one week before it is due :-)
Waterfall is a software development life-cycle. It can be used in conjunction with project management frameworks and methodologies. Since the waterfall life-cycle depends on each phase to be completed in full to continue to the next phase, it is typically recommended only if there is a rigid set of well-defined requirements. If there is still a considerable amount of research to be done in order to elicit requirements or if the project is strictly research with little-to-no software development, then there is a good chance that the waterfall model would not be a good fit.
See the Avalanche (broken link, see below) anti-pattern for more information on when waterfall is incorrectly implemented in an agile environment.
EDIT on 2017-01-10
Apparently the Wikipedia page for the Avalanche development pattern has been removed. I was able to find an article that quoted the original Wikipedia page (http://www.rtos.be/2014/01/4-reasons-you-should-stay-away-from-almost-scrum/):
The Avalanche model is a Software Engineering project management anti-pattern, it is a combination of a sequential process such as the Waterfall model and Agile software development methodologies. It is the result of a Project Manager’s attempt to apply Agile techniques to a project, when all they really understand or were taught was a sequential development cycle. Instead of breaking the project into parts that each sequentially go through the phases of development, the entire project inhabits all phases of development simultaneously. Usually the result of attempting to use the Avalanche model is mass confusion, wasted effort, and a product that cannot meet the specifications of any requirements document.
Waterfall is a software development method because it is a process which provides structure, planning, and control for software development processes. It is not so easy to tell you if it's suitable to implement in your situation without more details.
If you expect lots of changes in requirements that can comes during the time, and if you want to be able to react faster on these changes then forget about waterfall.
You can try some light-iterative processes like XP or Scrum or some other agile stuff.
Arguably, waterfall is a software development methodology (at least wikipedia thinks so). However, a methodology is a defined set of tools, activities, tasks that offer guidance on how to provide a set of deliverables. In this respect (as a delivery mechanism), waterfall breaks down as a methodology because unless the amount of work that needs to be completed is small, waterfall doesn't easily facilitate the need to make changes to the final set of deliverables once you begin. Expecting things to not change the minute you start is unrealistic.
Waterfall is a good description of the sequential activities that is needed to be completed for software development work. First, you need to figure out what it is that you want to build (i.e. - gather requirements). Then you need to determine how you will accomplish the end result given the limits of the chosen technology (i.e. - design). Then you need to build the solution based upon what you just determined is the best path (i.e. - implementation/construction/development). Then finally, you need to make sure that what you built did in fact solve the problem you initially set out to achieve (i.e. - testing). This list of activities in this order is the de facto standard for software development (yes, you can argue minor adjustments can be made by determining how you will test before you start building using TDD, but the general list remains the same).
However, the key here is to keep the size of work within this cycle small. If you grow the size of work too large, you now incur the risks that is inherent with waterfall as a methodology. This is essentially what agile software development does and why it is more successful in large scale software development projects. It prevents the waterfall cycle of activities from growing too large.
Although the Waterfall methodology was developed for software development, it has been adopted as one of the accepted project management methodologies and is used by lots of organizations.
The way this has been adopted for the project management world is as clearly defined scope, pre-determined dedicated project team, modules and team dependencies identified and established with no to very little room for slippage and no room for modification for scope.
Since Research projects in my mind have lot of uncertainties and assumptions, waterfall is not the right methodology I would go with. Event chain methodology probably is the best for research projects. You can read more about this here.
