Discouraging Waterfall contracts

I know thats a rather sadistic title for a post but I could not help write the same. For the purpose of this post, I consider Waterfall as “fixed scope” project more than a reasonable length [4 person man months and over should quality I guess]. Here are some things you can try [some have worked like magic for me]:

  1. As bad as it sounds, add even more ceremony to your waterfall contracts. Add initial requirement list sign off, each requirement gathering iteration sign off, method of estimation sign off and what not. Try to get sign off on exact process, SLA, bug count, delivery dates, feedback latency and all the abstruse things any one can think of. If that does not help, announce that after subjecting the poor client to 1 month of requirement gathering and contract revision, you plan to spend another 3 months discussing the project itself. The above time zones [1 month, 3 months] are relative for say a 6 month project. If that also would not work, try adding clauses that favour development unit more than the client – “All UAT must be done within 2 weeks of getting the build and the like.” Add costs for any allowance the client requests. You will either loose the business or get an opportunity to push fixed cost/ fixed time but variable scope projects. If you can just send an email newsletter singing paeons of Agile just at right moment to get the clients in right mood to talk.
  2. Disguise Agile Completely. Here is one approach:
    • We understand initial requirement define a fuzzy viewpoint on the horizon. Hence, we allow our customers to add requirements at any stage and delete/ edit/ replace items from the requirement list as long as it is of the same size, size determined by us.
    • We would provide you working software every iteration [basically 2 weeks/ 2 months] free of cost/ at additional charge of XX USD per iteration.
    • You can cancel the project at any stage for a free of XX USD in case your business interests are met earlier due to working on prioritized business requirements
    • We welcome client feedback and this would be managed as per attached Annexure [Annexure is more glorious description of SCRUM/ Agile].
  3. If the above slightly cheeky ideas don’t work for you, you can simply do case studies of projects done using Agile [also do customer satisfaction studies] and show how going Agile is good for business [faster time to market, lower cost of ownership, flexibility to respond to business changes] etc.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: