Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

8 Reasons to Choose Time and Material for Your Software Project


Published on

How do you make a project with an inhibiting agreement with fixed key terms successful? You don't. Here are 8 reasons to pick time and material instead. Trust us, we've been through this.

Published in: Business
  • Login to see the comments

8 Reasons to Choose Time and Material for Your Software Project

  1. 1. 8 Reasons to Choose Time and Material for Your Software Project
  2. 2. // 2 How do you make an agile project, or any project for that matter, successful with an inhibiting agreement with fixed key terms?
  3. 3. // 3 You don’t. And there’s no way around it. The projects that have been - or are - a success at Espeo have always had one common denominator: a time-material agreement.
  4. 4. // 4 Basing on our experience in past and ongoing projects, we’d like to give 8 reasons why time and material contracts are the best choice for software development.
  5. 5. #1 100% transparency
  6. 6. // 6 You get billed for the time we’ve spent working on your project. Every minute of it and not a minute more. No rounding up. You pay for what you get. Time spent on our self- development, training, company meetings is NOT billed.
  7. 7. // 7 We think there is a problem ahead - we’ll tell you immediately. We don’t think the feature is worth spending time on it - we’ll tell you, you might reconsider.
  8. 8. #2 You’ll be playing on the same team
  9. 9. // 9 There’s mutual understanding that long-term success benefits both parties more than any short term wins on either side. This leads to mutual respect.
  10. 10. // 10 This allows all people - involved on both sides - to think in ROI categories. And one more thing: we love suggesting killer features - hey, at the end of the day everyone benefits!
  11. 11. #3 The overhead is minimal
  12. 12. // 12 ●no debates on what’s in scope and what’s out ●no debates on what’s a bug and what’s not ●no debates on what’s a bug and what’s a CR ●hey, no CRs! ●no development of features we don’t believe in ●no more waste!
  13. 13. #4 Time and material and agile are a perfect match
  14. 14. // 14 Agile still the best approach to software development. And there can be no real agile with an inhibiting agreement underneath. Give your success a chance! No more artificial agile, calling it agile, iterations being just another name for weeks, etc.
  15. 15. // 15 It’s simple: you show your needs, we advise, you decide, we do it.
  16. 16. #5 Time and material agreements are change-friendly
  17. 17. // 17 You’ve changed your mind about your business direction. Very well, we can react to changes. We play right along.
  18. 18. // 18 Here’s a sample dialogue: “no offence, but the feature you’ve started work on is pointless now since the competition already has it” - “none taken, let’s build something new they don’t have yet. Let’s start today!”
  19. 19. #6 Development can become business- driven
  20. 20. // 20 You need to grow your business in an optimal way, we’re there to help you achieve this goal. Even if it means taking a suboptimal route from the IT perspective at times. Technology shouldn’t dictate the path your product is to take.
  21. 21. #6 Time and material encourages the development of a long and sustainable relationship
  22. 22. // 22 Long-term motivation based on a common goal is achieved together in small steps. It’s not based on bonuses, management pressure, fear and contractual penalties.
  23. 23. // 23 A long-term perspective motivates against taking intentional shortcuts that would remain unnoticed for a long time but are very costly when eventually TSHTF.
  24. 24. // 24 This model has a significant impact on team morale: which leads to attracting new team members and inhibits departures thereof.
  25. 25. #8 Time and material contracts allow you to rely on actions rather than words
  26. 26. // 26 Proof of Concept: ●instead of multi-page specification and implementation documents ●instead of estimations, negotiations and assumptions
  27. 27. // 27 You should get an MVP ready and show it to the clients ASAP. That’s what time and material allows you to do. And it allows you to carry on with scaling and growing!
  28. 28. // 28 You should also estimate your budget and milestones based on facts (real team velocity) not promises (initial estimates based on documentation).
  29. 29. // 29 To sum up: we’ve tried to bend the continuum before to get the most out of fixed-term projects. It wasn’t only uncomfortable for us - these contracts end up not benefiting the client either. Other opinions? We’d love to hear you out.
  30. 30. // 30 Like what you see? Let's start development! THANK YOU! Poznań // Helsinki // San Francisco