Category: contracts
As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. What are the available playing rules and what is the best approach for a agile project?
Bookmark/Search this post with:
Some people would like to believe that building complex software
is like going to the grocery store: pick a candy bar off of the
shelf, ask what it costs and decide to buy it. You get no risk and
quick gratification. But building custom software is more like
building a race car. A special one-off product to meet exactly the
needs of its sponsor: win races.
As a customer, what are you really buying when you contract for
software development? You may think you are getting a solution. But
what you are really getting is an implementation team. And risk is
always part of the bargain. So what you really want is a team you can
trust to build your product and to minimize the risk of that choice.
In this article, I present a lightweight, lean approach to
selecting a software development partner which should dramatically
reduce the risk and cost to all parties.
Bookmark/Search this post with:
My customer wanted to find an external partner to
develop
their new software product and develop using Scrum. So we needed to
evaluate
the potential partners, but how? The classical approach is to define
the
application “exactly”, then ask some potential vendors if they can do
it and
how much it will cost (and then haggle over the price). This is not
very Scrum
like, but it represents a starting point which is well understood by
customers
and vendors alike. What is different about an Agile RFP?
Bookmark/Search this post with:
I just finished helping a customer write an RFP (Request for Proposal) for a software development project. The customer has had some expensive experiences with waterfall style projects, and Scrum had been the key to getting those projects back on course. So it seemed logical to plan Scrum from the beginning. But how do you write an agile, Scrum-Compatible RFP? How do you select a company to implement an agile project? We started with Scrum.
Part 1 in the Agile RFP Series;
1. Using Scrum to Create an Agile RFP
2. Contents of the Agile RFP
3. Selecting an Agile Outsourcing Partner
Google was remarkably unhelpful with this problem. The top links all pointed to a paper and presentation from 2003 about combining Use Cases and User Stories in the RFP process. A request to the ScrumDevelopment Group produced no responses. So we were on our own.
Bookmark/Search this post with:
There are three prerequisites for starting a project under Scrum: a product owner, a product backlog and a team to implement the features. Is that enough to get a project approved for development? Probably even an agile company will want some basic questions answered: What are we building, and why? How much will it cost? How long will it take? Here's a way to move forward.
Bookmark/Search this post with:
Again and again I am asked (or feel forced) to explain why agile software development fits nicely with fixed price contracts. Some people still think that a fixed price contract requires a detailed up-front requirements study, to accurately calculate the costs of the project. But that's not correct.These are the arguments that I use frequently:
Bookmark/Search this post with:
Some people think that agile and budgeting are incompatible. The product is ready when the product owner says it is. But before starting a project, most managers want at a least budget. So the product owner puts together his wish list and asks the ScrumMaster what it will cost to build. The answer comes back — usually a long time and whole lot of money! Then the customer turns pale as he tries to decide what it will really cost, whether he can afford it and whether it's worth it.
But there is a better way: the product owner can perform a double worst case analysis. This quick and easy tool uses the project's business value to determine a reasonable price for the software investment.
Bookmark/Search this post with:
Upfront planning
Last weeks I spent huge amount of time negotiating with the renovation company about the details of our upcoming bathroom renovation. You know, all this bargaining, market research and choosing between a multitude of option takes time. To make things even more complicated our house manager happened to be very peculiar about what he can allow to be changed - it triggered yet another round of negotiations and renegotiations even though we signed the contract already.
The biggest problem is that there is a decent element of uncertainty. Some technical decision can be made only after they start works and break the walls. Therefore we have to nail down plan B and plan C well in advance not to be offered a bill with the "additional costs" after the fact.
Bookmark/Search this post with:
While it is possible to utilize fixed price, fixed scope contracts with the agile methods, fixed contracts are still discouraged in preference of time & materials or Pay per Use. The reasons is that in most if not all cases software development is not a mass production, but a new product development. It is rarely possible to just clone the existing system for a new client. At best, when implementing tunings for a new client, we can try copying the existing approach or best practices. Therefore in order to build something that is not known to the last bit in advance we have to unfix at least one angle of the quality triangle
Bookmark/Search this post with:
Agile software development methodologies discourage the use of the fixed price contracts. When forced to commit to the fixed price, agile approaches advocate unfixing the project scope. However, even if it is impossible, there are still ways to realize the benefits of agile methods.
Poorly predictable complexities
Sydney opera house, a beautiful piece of art, the Sydney's best known landmark and international symbol was started as a fixed-price, fixed-date project. Unfortunately, since it was no standard building time, it was impossible to estimate all the difficulties and complexities in advance. As a result, it took 13 years and 102 million Australian dollars to build instead of 3 year and 7 million estimated - 330% time overrun and 1350% costs overrun!
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle
