I can not see how a software project can make any meaningful progress under a waterfall methodology if the requirements cannot be clearly stated from the outset. Am I missing anything?
3
-
3Yes, you need to define what you mean by "strict" waterfall, "succeed" and "progress". Faulty requirements capture will, of course, cause dates to slip regardless of methodology. Whether or not that causes the project to be terminated without reaching completion depends on the what the stakeholders have to say about it.– AngeloOct 18, 2011 at 21:10
-
1I like what the author of Management 3.0 said, "every project is a success until it fails". As Angelo pointed out, you need to define what you consider success. Even products that already sold for several years could be considered failures if the world turns towards a better product that the competition is providing. If you are asking can waterfall project have profit (i.e. revenue > cost), answer is yes. But do you consider that a success if non-waterfall project delivering similar product could have delivered more profit?– DXMOct 18, 2011 at 23:45
-
And of course let's not discount very lucky guesses about mystery requirements.– Erik ReppenFeb 3, 2016 at 0:49
Add a comment
|
8 Answers
We use waterfall and have completed lots of projects with changing requirements. Waterfall isn't as bad as it's been made out to be and Agile isn't the silver bullet that fixes everything (as many badly done agile projects as waterfall projects as far as I can see.) Neither methodology has a particularly high success rate, in part because users don't know how to define what they want and in part because there are alot of incompetents in our field.
-
6I would qualify that claim a bit, but I don't entirely disagree. Waterfall done right will fail often. Scrum done right really cannot fail because it doesn't make promises on both scope and date; it just says "we'll do what we can by then" or "we'll do that as quickly as we can." But Scrum is rarely done right, mostly because people don't really understand how to set expectations, and thus (in the eyes of the customer, at least) it does fail as often as Waterfall.– pdrOct 18, 2011 at 21:32
-
3@pdr You're right about Scrum but in a somewhat trivial way - any methodology that technically promises nothing technically can't fail. Waterfall modified to "we will take your list of requirements at the beginning and maybe do some of them eventually we hope" also could not technically fail.– psrOct 18, 2011 at 21:40
-
@psr: Correct, but that wouldn't be an easy sell to the customer. I wish it was, I'd make a fortune by putting a name on it and writing a book.– pdrOct 18, 2011 at 21:47
-
3It would help to explain "completed lots of projects with changing requirements". In my experience, doing this requires a lot of flexibility to change the project plan. That "flexibility" could be called "Agility" and that would lead one to question how much waterfall was really going on. An Agile waterfall is -- well -- Agile.– S.LottOct 18, 2011 at 21:51
-
1@pdr, the perception of the customer is the important measure of whether something has failed. Right now no method can guarantee success and no method is perfect. All methods can deliver products or we wouldn't have any live software. We went to the moon on software designed in a waterfall process.– HLGEMOct 19, 2011 at 13:17
Comment by "Andrew" above is valid. Also, which part of the requirements is missing. The waterfall methodology is not as rigid as some thinks it is. Waterfall focuses on moving between major stages after enough information and facts have been collected. There is nothing stopping you from refining your analysis as long as you are not re-doing major parts of it.
For example, you can start design without knowing all the required reports and you can start design without knowing all the validation rules. All of that can always be added later.
However, you don't want to start the design with only 1/3rd of the columns in the database identified. Water fall is a great methodology and is quite suitable for most applications where the business is not being invented from scratch and where users know the business.
You can make progress in your database design, screen design, system architecture, use cases and more without knowing all the details up front.
The art here is dividing the problem to pieces that can start and progress with least dependency on other grey areas. This is a generally good approach regardless of the employed methodology.
It depends on how good the coders are.
If the coders have a good understanding of the business they are working on and if they are clever enough to write the code in a loosely coupled way, then towards the end of the waterfall when the customers see the product they should :
a) not have too much to complain about
and
b) what they complain about can be easily altered and fixed
You have to be good to make it work though!
-
-
-
1I guess it depends on what part of the application you work on, I think Agile is much much harder for database developers. Only someone spectacularly good could create a performant database under those conditions.– HLGEMOct 19, 2011 at 13:31
I have never heard of a project using a waterfall methodology that did not incorporate change orders. So in practice, if the initial requirements are wrong (they are always wrong to some degree except perhaps on a tiny project - I've never seen them be 100% perfect) you just have change orders, and redo whatever you have to. Does that mean it's not really waterfall? It's really a philosophical question.
Can it succeed? It can, but the methodology isn't as focused on dealing with changing requirements, so it may not cope with it as well.
Actually, what I've seen a lot is that when requirements are not accurate then waterfall succeeds pretty well for the software developers , not as well for the clients. The reason is that most of the time a waterfall methodology was adopted in the first place because the client, quite reasonably, wanted to know up front exactly what the project would cost. Unfortunately nobody knows how much a software project will cost. Sometimes clients never figure that out and refuse to hire anyone that won't give them a fixed price. Since at that point developers trying to get the client's business are competing primarily on the basis of quoting a low price, they underbid and hope to profit on the change orders, which cover anything beyond the initial requirements and usually carry a high hourly rate.
Therefore, when the requirements are bad that means the developers get more of the profitable part of the contract (change orders) and less of the unprofitable part (the list of requirements the client thought he wanted back when this all started).
But eventually the true requirements are uncovered and the changes made, so for the client it "succeeds" in the sense of getting done, though at higher cost in time and money than if the requirements were right initially.
So I like Agile personally for two main reasons - first it aligns the interests of the client and the developer better than the "is this a change order?" battles waterfall can lead to, and second because frequent deliverables help mitigate the risks. But "pay us and we'll try to write you some software, but we don't yet know how much you'll get for your money" is a tough sell sometimes, even if it's really only admitting the underlying reality of the situation.
The requirements not being clearly defined doesn't automatically doom the project, IMO. The probability of failure is high I'll concede though there can be cases where it still succeeds.
It can. You just have to build contingency into your initial estimates and explain that if the requirements are uncertain, so are your estimates. If requirements are coming in at the same pace that development is progressing, it will work just fine.
Remember that Waterfall is not the opposite of Agile. All you are saying is that you will not deliver components incrementally. It's just "give us your requirements as soon as you can and we'll code, delivering you a product at the end. But if you don't bring us requirements quickly enough, your product will be delayed."
However, Scrum is designed to manage uncertainty and change and I still think that's the best way to go. I'm just saying that if the client isn't interested then that doesn't mean you're certain to fail.
Allow me to recommend that you read "Death March" by Ed Yourdon. Once you realize that you aren't the ONLY one working under less than ideal conditions, it really is helpful and motivating. That said, it also has not dissuaded me from asking uncomfortable questions--like why are we coding without clearly defined requirements?
The circumstance for success when answering the question of how long it will take to build something neither you nor the client understand is to say it will take way way longer than you think it will. Put in months, or years of slack if you have to.
