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?

Improve this question
4
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 22:43

3 Answers 3

Reset to default
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.

Improve this answer
4
  • 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, 2015 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, 2015 at 12:12
  • Beware, agile is not mini-waterfall - scrumalliance.org/community/articles/2012/january/…
    – Paul
    Nov 13, 2015 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, 2015 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 :-)

Improve this answer
1
  • 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, 2015 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.

Improve this answer
3
  • 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?
    – pbristow
    Dec 10, 2015 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, 2015 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.
    – pbristow
    Dec 10, 2015 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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