Alternative to Fixed-Price Contracts in Software Development

Alternative to Fixed-Price Contracts in Software Development

Overwhelming evidence shows that fixed-price, fixed-scope contracts fail in software development. I won't rehash the reasons here, as they've been discussed much better elsewhere. Fixed-price contracts favor neither client nor vendor.

Software development is not like a construction project, where there is a fixed start and end. Software development should be seen as product development. Software needs to be constantly modified based on the feedback from stakeholders and the ever-evolving pressures of the industry. It's more like gardening rather than construction.

The contracting model should therefore be like gardening. The most ideal model for software development is a managed service, similar to the contracts you probably already have with law firms or accounting firms. You need to hire skilled and caring gardeners to make sure your software is continuously able to serve its purpose despite changing business and technology needs.

Note that I'm not advocating for staff-augmentation either, which puts the burden of management with the client, and limits the skill sets available to the client.

The advantages of a managed service:

  • Aligned to long-term maintainability of the software. Fixed-price encourages short-term delivery of software that meets written specs but will be expensive for the client to adopt to future requirements.
  • Allows for quick changes in features, no need for tedious change request process.
  • Vendor can assign the people special skills to implement specific tasks at different times, and is overseen by the vendor's seniors (not the case with staff-augmentation).
  • Technology is updated appropriately, you're not stuck with the legacy technology that was specified in a fixed-price contract.
  • No need to spend excessive time and effort in detailing requirements. Product team can instead iterate requirements with the development team.

john homer A.

AWS | Cloud Architecture, Adoption & Migration

3 个月

Hey Calen, this is interesting. Can you propose a pricing model for this please? Time and material? What are the variables? Complexity? Man hours?

回复

要查看或添加评论,请登录

Calen Martin Legaspi的更多文章

  • "Sprint Zero" Activities Can't Fit in One Sprint!

    "Sprint Zero" Activities Can't Fit in One Sprint!

    Extreme Programming (XP), Scrum and Kanban emerged from the rescue of so called "Death March Projects" - projects that…

  • Story Points Are Not Function Points!

    Story Points Are Not Function Points!

    Story Points are not Function Points! We tried Function Points in the 80s & 90s already and they didn't work! Now many…

  • Why Do We Need the Philippine Skills Framework?

    Why Do We Need the Philippine Skills Framework?

    I have the honor of helping draft the Philippine Skills Framework on Software Development and Security. This is the…

    4 条评论
  • Avoid Custom Fields Unless Absolutely Necessary

    Avoid Custom Fields Unless Absolutely Necessary

    Custom fields..

  • User Stories Come in Many Forms

    User Stories Come in Many Forms

    Kent Beck never specified a format for User Stories. He just basically wanted the elicitation of requirements to be in…

  • Teaching Mockito in a Less Mystical Way

    Teaching Mockito in a Less Mystical Way

    It was my first time teaching Mockito to a face-to-face class yesterday (I've taught it before to online classes), so…

  • Interface-InterfaceImpl Anti-Pattern

    Interface-InterfaceImpl Anti-Pattern

    You don't need to do the Interface - InterfaceImpl anti-pattern. There's a misunderstanding of two design principles:…

    3 条评论
  • First Time Teaching Scrum in School Class

    First Time Teaching Scrum in School Class

    Just some notes on how I'd teach Scrum in a school class the next time around. School Schedules Incompatible with…

  • A Senate of Scientists

    A Senate of Scientists

    We tend to ignore scientists until people start dying on a massive scale. The coronavirus epidemic was predicted by…

    1 条评论