Resolved
2 votes
As Amy Barth writes is the first sign of BPM failure:
When the customer refuses to listen to the experts they have hired to run the BPM project and demand a waterfall process. It's never a good sign when waterfall is the preferred methodology
So is there ever a call anymore where waterfall is the preferred methodology?
Thursday, August 07 2014, 09:54 AM
Share this post:
Responses (14)
  • Accepted Answer

    Thursday, August 07 2014, 10:40 AM - #Permalink
    Resolved
    3 votes
    I have a friend that works at Lockheed Martin and does a lot of big government contracts. They still use Waterfall. It seems when I talk with clients they still use waterfall or a blended approach with aspects of agile for very complex projects. I am not saying that is the best approach but still seems to be happening.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 10:44 AM - #Permalink
    Resolved
    2 votes
    Funny.. but waterfall is still the basis of all the application development methodologies. I am sure this will spark some debates and provoke the ire with the purists but every methodology has a sequence. You can't tell me that testing would happen before any coding is started. You can't tell me that some sort of planning doesn't happen before a project starts. You can't tell me that some level of development is not done before rolling into production..... So the bottom line... there is a sequence that is grounded from waterfall days however evolution and the newer methodologies has changed the micro aspects of the sequence content and abilty to change thru the lifecycle. It is all about how one chunks work scope, how deep each task is done thru the lifecycle and having a team well positioned to manage change (being agile) not to mention disciplined within the implementation lifecycle. OK I over simplified. The words of waterfall should just go away from these conversations but only for the dialogue of where we came from.
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, August 07 2014, 10:46 AM - #Permalink
    Resolved
    2 votes
    I have never been a proponent of the "waterfall" approach in any application. It assumes systems design is a serial process; I contend it should be based on a product structure thereby enabling an engineering/manufacturing process. This allows you to develop the system in parallel and concurrently. It also allows you to deliver the product in pieces. I have written on this in the past and I will have another article soon.
    • Tim Bryce
      more than a month ago
      "Waterfall" methodologies have a heavy emphasis on Project Management, not design. It is a fallacy that Project Management is the problem; instead people simply do not know how to design and build systems in a uniform manner, and "waterfall" methodologies do not provide this guidance. Imagine a manufacturing facility with an assembly line and production control. The assembly line dictates the development process, production control measures progress. In this analogy, the assembly line is the methodology and production control is project management. Can you build a product without production control? Certainly. Can you do otherwise? No. In other words production control (project management) is dependent on the existance of an assembly line (methodology). Without it, it measures nothing. Again, the "waterfall" methodology is more akin to production control as opposed to a true assembly line.

      The need to build software faster has reached a feverish pitch. So much so, full-bodied development methodologies have been abandoned in favor of "Agile" or "Extreme Programming" which are basically quick and dirty methods for writing software using power programming tools. To their credit, those touting such approaches recognize this is limited to software (not total systems) and is not a substitute for a comprehensive methodology.
    • Keith Swenson
      more than a month ago
      The problem with waterfall is that it is based on the idea that you can specify the design in complete detail before you do the work. If you are building a bridge, this is a possible. You can calculate how much iron you will need, how much concrete you need, and can lay out a schedule for exactly when it should arrive.

      Software is completely different. It is many orders of magnitude more complex, and every routine is doing something that has never been done before. Software is a voyage of discover, and by its nature, unpredictable. Without being able to predict the plan, you simply can not make a complete design necessary for waterfall. Even the original paper on waterfall by Winston W. Royce noted that it would only work on simple, well defined pieces of software.
    • Tim Bryce
      more than a month ago
      Keith - I would disagree with you to a point. First, I do not support the concept of the "waterfall" approach which would imply ALL of the programs have to be specified before moving to the next phase in the methodology. Under my "product" methodology, the overall architecture of the system is identified and detailed in a top-down approach. The architecture includes more than programs (which is lower in the hierarchy); it includes sub-systems (business processes), procedures (for work flows), operational steps for manual procedures, and a computer procedure for each business process; this is decomposed into programs (and other building blocks if so desired).

      After the system architecture is defined (which includes the logical data base), each sub-system can be developed in parallel. For example, my team could tackle one sub-system and take it through to programming, while you could take on another sub-system separately, etc. In other words, we could deliver the product in pieces, yet be assured it will all fit together in the end.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 10:49 AM - #Permalink
    Resolved
    4 votes
    I believe Gartner gives the clue here by classifying applications to Systems of Record, Systems of Differentiation and System of Innovation. (Accounting app being a typical System of Record while a BPM app built on top of BPMS is a typical System of Differentiation.) Systems of Differentiation are volatile by their nature so Agile methodologies are the best (and the only, really) choise here. But as for the Systems of Record, more traditional (e.g. Waterfall) development methodology may be used quite successfuly.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 11:11 AM - #Permalink
    Resolved
    2 votes
    Waterfall never really works that well, in my experience. But you can use some judo to get waterfall projects to act more agile.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 11:41 AM - #Permalink
    Resolved
    4 votes
    Waterfall isn't about making development better. It's about making it more inflexible, which doesn't sound like a great idea (and generally it's not), but is useful in the case where costs have to be absolutely fixed. There is no chance of getting the best possible result out of a waterfall development effort, but there is a predictability that appeals to certain cultures or is appropriate to certain situations. Think of waterfall as a pair of handcuffs. Normally you wouldn't want to use them, but there are scenarios in which they might be necessary. Or fun. But let's stick with "necessary".
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 12:01 PM - #Permalink
    Resolved
    2 votes
    I have implemented level 2 CMM processes within a software engineering program and the first thing you do when implementing a CMM program is migrate away from the waterfall method. One of the reasons you do this is exactly the opposite from what was stated in a previous comment. There is little control and predictability in a waterfall method. That's why the word "fall" is in the word. The water is falling in an uncontrolled manner and crashing onto the ground below.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 12:39 PM - #Permalink
    Resolved
    2 votes
    Waterfall model is good for situations that you set up once and can never modify again: like a space probe or a Mars rover. Agile will outperform waterfall in all applications where you can iterate -- that is, anytime you can try it, get feedback, try again, etc. If you are sending something out into space, you have to have it right before the blast off. Same with nuclear weapons. There are very few things that you get only one shot at. Almost everything else can and should be iterated. http://social-biz.org/2008/09/02/agile-development-road-trip-analogy/
    • Scott Francis
      more than a month ago
      in fact, agile is also superior in cases where you can simulate (test) rather than real-world. So your mars rover, you can show people what it should look like when it is up there, how it should work - in simulation. It isn't as good as real-world testing, but simulation is better than no feedback loop at all (usually)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 03:30 PM - #Permalink
    Resolved
    1 votes
    Systems are designed by ‘explosion’ and implemented by ‘implosion.’ - Thanks Tim As a variation for mixing waterfall and agile (re Tim's post and comments) - I use "Architecture-based agile project management" (archibagile) – decomposition cascade for architecting during the (almost) whole project and, in parallel, assembling cascades are initiated for brunches in the decomposition cascade which are ready for “provisioning” and “building”. See http://improving-bpm-systems.blogspot.ch/2014/06/different-coordination-techniques-in.html Thanks, AS
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 08 2014, 02:24 AM - #Permalink
    Resolved
    2 votes
    Waterfall methodologies worked great in the past, when there was little access to meaningful technology, either limited by number of incumbent suppliers of technology, the absence of the internet or simply the stage of technology. Today, I think the waterfall process works best for a company that is engaged in a sophisticated money-laundering scheme and it needs to siphon out millions without having to show meaningful, measurable results too quickly. :D
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 08 2014, 05:38 AM - #Permalink
    Resolved
    2 votes
    The fact is advances in enterprise software have resulted in all business logic being pre-coded and just needs configured direct from business language. The core code never changes and there is no compiling which supports not just very quick build but easy change. It is effectively a true 6GL. All this means that it is no longer necessary to have a "final" spec before build starts as "discovery" is extended into build and takes place as ideas evolve when people can see in action. So waterfall belongs in the history of the evolution of software as far as business systems are concerned. Of course very specialised needs like building a space system may well benefit from "waterfall" but not business! Big suppliers to Governments have no interest in cutting their own revenue and certainly the UK Government has no real research capability and as such do not really understand "how" software actually works. So "old ways" such as waterfall thrive at great cost to the taxpayer. We see emphasis moving to "agile" as "digital" becomes the focus but again failing to really grasp the fact it is about business operations and much more than the UI. I shall leave you with the views from Naomi Bloom an independent thought leader who articulated very eloquently in simple language “Writing less code to achieve great business applications was my focus in that 1984 article, and it remains so today. Being able to do this is critical if we’re going to realize the full potential of information technology” “….how those models can become applications without any code being written or even generated”. “If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created…..” “…”If your Enterprise vendor isn't pretty far down this path, their future isn't very bright”.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Amy Barth
    Amy Barth
    Offline
    Friday, August 08 2014, 02:33 PM - #Permalink
    Resolved
    1 votes
    It seems we all agree. Only in rare cases should waterfall be the preferred method. Thanks, Peter, for using my comment to spur this forum's conversation (although it turned out not to be very controversial).
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 11 2014, 08:06 AM - #Permalink
    Resolved
    1 votes
    IT people never learn. The harder you make something, the less chance it has of happening. When IT first came along it was hard. People had to write code for the simplest of things. Business people couldn’t be expected to understand these things. Nor would they want to for a “one-off” project. A whole system grew up which basically says – “don’t be frightened – we have experts to work out what you want so we can make it for you”. But the experts couldn’t do it either. So we ended up with a chain of experts who could translate it into a language the next one in the chain could speak and they would then translate it for the next guy. It is a bit like translating the Bible from Hebrew into Greek, then Latin before creating an English version. We owe the rise of England and the USA to translating it direct and cutting out the errors which had occurred in the multiple translation version. Now software and coding is second nature, even to business people. We teach it in schools (from the age of 6 in the UK). We have a whole generation of people who know what they want in technology terms. And we have a whole library of code already made. We can now widgetise BPM – pulling the bits we need onto the page and filling out a form to link them to data sources. Linking up a CSS file to make them match our corporate styles, putting in logos etc. with a few clicks. We can create decision trees and write queries in ordinary ( American) English. Even BigData is drag and drop. So the real question is do we need a cascade at all? Are we involving IT purely because our BPM software is badly (or arrogantly) designed? Or because some IT person wants to tell people what to do? Thinks he knows business better than them. We saw this with Websites. Websites used to be hard – every page had to be put through a review procedure, agreed by the board and then installed by IT. The result was awful long-winded jargon heavy websites no-one read. Then Marketing Automation found a way round – creating templated landing pages which anyone could create. BPM is simpler than a spreadsheet (or a Web CMS). So why isn’t it on everyone’s computer? How exciting could it be if people were allowed to try out things for themselves? AB test. Evolve processes. I'll wager it could make a bigger difference than democratising Websites. The thing is, by making BPM hard, we are stopping it reaching widespread acceptance. And we are opening ways for people to find a way round. Waterfall is stopping BPM from transforming businesses. And by stopping it from becoming widespread, it is costing IT people jobs.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 11 2014, 12:44 PM - #Permalink
    Resolved
    1 votes
    Peter Johnston wrote: So the real question is do we need a cascade at all? Are we involving IT purely because our BPM software is badly (or arrogantly) designed? Or because some IT person wants to tell people what to do? Thinks he knows business better than them. We saw this with Websites. Websites used to be hard – every page had to be put through a review procedure, agreed by the board and then installed by IT. The result was awful long-winded jargon heavy websites no-one read. Then Marketing Automation found a way round – creating templated landing pages which anyone could create. BPM is simpler than a spreadsheet (or a Web CMS). So why isn’t it on everyone’s computer? How exciting could it be if people were allowed to try out things for themselves? AB test. Evolve processes. I'll wager it could make a bigger difference than democratising Websites. The thing is, by making BPM hard, we are stopping it reaching widespread acceptance. And we are opening ways for people to find a way round. Waterfall is stopping BPM from transforming businesses. And by stopping it from becoming widespread, it is costing IT people jobs.
    There are a few flaws with this train of thought. 1) BPM is not simpler than a spreadsheet. maybe workflow, but not the development of systems that offer much in terms of value. 2) just because regular people "can" create applications doesn't mean that they should. I want my LoB employees focused on their respective jobs not on building IT systems. Ideally, the LoB has the flexibility to alter the behavior of the process or application based on their specific expertise and/or judgement. This is the yet undelivered promise of adaptive case management.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
276 Replies
25/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
220 Replies
23/09/2016
Bogdan Nafornita
209 Replies
25/09/2016
E Scott Menter
182 Replies
23/09/2016