2

My company has recently started to take on smaller software development projects. Typically small web applications to be used on a client's intranet. They are usually 3-5 months work in total.

Typically, the client doesn't know what they want exactly so they pay us for a smaller projects (3-4 weeks) to gather requirements and write a functional design. Once that is approved, we both know what is wanted and can quote for the remainder of the project and carry on. This is because they like to have fixed-price contracts rather than paying time and materials.

This development lends itself quite nicely to a waterfall model, we gather requirements, design, implement, test, deliver. However, despite this, we sometimes get to delivery and the client says "that's not what I meant".

My instinct is to make sure we have a more detailed design up front but I'm being told we should be "more agile" and iteratively development the system with the client so they can see it develop and we can catch problems with expectations earlier.

I'm struggling to see how to fit that into a fixed-price model. How can I estimate a project when the client doesn't even know what they want? I can see that Agile development would be beneficial in this scenario, but not with a fixed-price.

Am I missing something?

  • Think about whether you're putting enough detail into the design document. Also, if you're not getting the client to sign-off the document, then you should consider doing this. Agile is about identifying issues early. – Robbie Dee Nov 12 '15 at 11:45
  • @RobbieDee I agree with you there. The other developers here are saying "We should be agile" when they really mean "I don't want to write a design document" – A Jackson Nov 12 '15 at 12:10
  • The term Agile gets massively abused depending on who is using it. To developers, it is the chance to work a little more fast and loose. To managers, it is about the tools and processes. To clients, about getting everything quickly and being able to change their minds on a whim etc etc etc. – Robbie Dee Nov 12 '15 at 12:15
  • 2
    What you are doing is fine, with one variation that have made waterfall-like projects work quite successfully for decades. You do the requirements and top-level design and estimating like you have been doing. Instead of having one delivery at the end, you define multiple deliveries/iterations. It gives the customer something to play with earlier and you time to change direction (if needed). It helps avoid the rework that agile frequently incurs. IOW, use waterfall similarly to what agile proposes. The successful waterfall developers have been doing it this way long before agile was conceived. – Dunk Nov 12 '15 at 22:43
3

The important thing is to agree what will be delivered and then time-box it into a series of 2 week sprints - mini-waterfall developments if you will.

If the client is a little unclear on how something will work, that is fine, but it shouldn't be committed to the development sprint as it can't realistically have any accurate development effort assigned to it. Throw some wireframes together and thrash the issues out first.

It can be tempting to think you know what the client will want as it is cash in the bank but if at the end of the sprint(s), the client still isn't happy, then they have you over a barrel. In their mind, they have paid for the feature and development should progress until it is done. This nightmare scenario is to be avoided at all costs. I worked on a medium sized development where the account manager agreed to what the client called "some simple reports" without looking into the detail. These "simple reports" burned through a 1/3 of our development budget despite only having a 1/10 initially budgeted. Make it clear to the client that you're willing to throw designs around until they're happy but only commit to development once you have a firm idea of what is required.

If the design process looks like it might take some time, then by all means have a series of parallel sprints for this too. The client may decide at the end of the sprint, that they really aren't clear what is required and so might just throw the idea away, or better - they'll have been able to narrow down what exactly it was they wanted which will feed into the next sprint.

  • 2
    I like the idea of making it a series of mini-waterfalls. I'm not sure the clients would go for it without an indication of how many 2 weeks sprints there was going to be, which brings us back to square one. We'd have to get our sales manager on board as well to sell it that way in the first place. This is seeming like we're going to need a wide systemic change in how we work which is often difficult here. – A Jackson Nov 12 '15 at 12:07
  • It is a common problem - in fact we have the same here. We were a traditional waterfall shop but now we just have Agile development but with fixed delivery dates for the overall project. This of course is absolute nonsense as Agile deliveries are at the sprint level. – Robbie Dee Nov 12 '15 at 12:12
  • Beware, agile is not mini-waterfall - scrumalliance.org/community/articles/2012/january/… – Paul Nov 13 '15 at 18:49
  • That article describes a very old waterfall method which I haven't seen in use in about 20 years. Latterly, waterfall has had to adopt many of the aspects of what eventually became Agile development via RAD and Extreme Programming. – Robbie Dee Nov 13 '15 at 18:57
3

The simple fact is that you already are failing to cater for a fixed price model: you do upfont design, code and deliver ans then the client says "oh no, we want it to be different", and what do you do then? Charge them extra for the new work, or complete the changes for free?

Agile simply changes the development model to cater for this, your pricing is either by time spent or by fixed delivery date. In the former, you keep going until the client is happy, in the latter you keep going until the cash runs out. (this is one reason why you must always have something deliverable at the end of each timebox, there may not be another one)

Hopefully agile means you get to complete more work as the requirements capture is cheaper (as its iterative and requires less full documentation and signoff) so the client gets what they wanted quicker. That's the idea.. but in my experience, the client is never satisfied so they end up paying more (in a time-spent billing system) without noticing.. which always pleases management :-)

  • Typically, we'd want to charge them for rework at the end, but often the design wasn't detailed enough for us to say they approved it to be made how it is. That's what's led to this situation. We end up doing it for free and want to stop that. – A Jackson Nov 12 '15 at 12:05
2

If customer is fine paying for 3-4 week long project, they should be fine paying for 2 week project. And then next 2 week project. And then next one. And next one and so on. And at end of each of these projects, you give them some semi-finished application and ask them what is missing or what is wrong. Also ask what is most important from that which is missing or wrong, so it can be included in next project.

  • the reason clients typically don't accept this is they want to know the final cost of the software package before paying for it. Put yourself in their shoes...on one hand they could buy CSC's FooWorks for $250K; on they other hand they could have you develop a custom package for ... oh wait how much will it cost? Basically saying "we'll be done when you tell us we're done" is never an acceptable answer because the customer has to make a hard trade-off decision regarding ROI. If you were buying a house vs. building new, would you accept not knowing the cost to build? – pbarranis Dec 10 '15 at 14:37
  • @pbarranis Tell them life is never so simple. Also, are they so sure FooWorks will cost only $250k? What about cost of integration with other systems? What about training costs? What about costs caused by impedance between software and process? And stop bringing buildings into this discussion. I know you don't think those are comparable yourself. – Euphoric Dec 10 '15 at 15:12
  • Sorry, I didn't mean to make any hair on the back of the next stand up. I only mean to say that I have never encountered a client who is willing to go into a new custom software project without a good-faith estimate that allows them to see a clear ROI. IMHO it's an understandable fact of doing business. – pbarranis Dec 10 '15 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.