About fixed-price estimation, Jeff said "Explaining this to the client...the scope and the duration to be negotiated..." when he talks to the FDD approach of project development.
OK, it is a good idea to explain this approach to your client but in the real life, I mean usually, the client first needs to make a RFP with its needs, its dates constraints, and so on and then, you, the supplier, you make a proposal with your estimations (duration, work). So, I mean that with a fixed-price contract approach, the supplier engaged himself on a "needs scope" for a fixed-price before he can be the supplier of the client (ok, I know that the scope of the client's needs is never frozen and this is why the iterative approach is encouraged). When the client has signed the contract, it is difficult to change it (the contract) and have this collaborative approach of the software development.
So, my question is : Is the iterative approach compatible with a fixed-price contracting approach ?
NB: I've read the "Progressive acquisition and RUP" articles (Jim Highsmith) but I always wonder if fixed-price contracting is appropriate when you use an iterative approach
Yes
There's a very long history of iterative and increment projects. Craig Larman and Victor Basili recently co-authored an article (June IEEE magazine) on the history of iterative and incremental development.
My consulting practice has ONLY done fixed price projects.
Jeff
Well, so how do you, can you,
Well, so how do you, can you, manage the contract. When can you decide that some requirements are new (not explicitaly expressed in the RFP of your client) and/or affect the terms of the contract (workload, price) ? I mean because you've been engaged on a duration+price for a specific scope (even if you know that this scope is not necessarily well defined), it will be difficult t say to your client that this specific needs/feature/requirement was not specified.
But ok Jeff I agree on the siprit of iterative development and I'm really a sponsor of such an approach but I wonder how a client that does not adhere this approach can really combine iterative development and fixed price contract.
So, when do you discuss the contract ? At the end of the RUP phases ? Add the end of some iterations ?
Thanks for your first reply
Break it down
Hi Gollot,
there's a lot of questions, statements and issues in your posts. It isn't even clear to me whether your question is about iterative in general or FDD specifically.
So, try and break the problem down. Let's take it one step at a time.
Your first post seemed to say that development can't be done under fixed-price. There would be thousands of projects (my speculation) that have been interative and fixed-price. Hence, I refered you to the recent Larman and Basili article which is a good history and would expose you to several projects that might surprise you that were done iteratively or incrementally.
Or do you mean FDD specifically?
I discuss the contract before the start and after the startup phase in FDD (see How to Reduce the Risk of Fixed-Price Estimates). Then, the granularity of the features in the features list plus the fact they are client valued then makes it far easier to establish what is a new feature (see How To Record New Features). You may also find this newsletter relevant Getting Flexible with Planning.
You said
you've been engaged on a duration+price for a specific scope (even if you know that this scope is not necessarily well defined)
But then the scope wasn't specific was it?
You said
I wonder how a client that does not adhere this approach can really combine iterative development and fixed price contract.
You're right - they can't if they don't adhere to it.
Jeff
Yes, my question is about ite
Yes, my question is about iterative + fixed-price.
I've not read all the FDD story but to me, it (FDD) seems that it's not far from the RUP and a use-case driven approach (incremental), so it is what is called "iterative & incremental approach" of software development.
Your startup pahse is like the Elaboration phase of the RUP; you know where you are and where you go so you can engage yourself in a fixed-price contract. I can understand this point of view.
But my question or remark in fact is that with an iterative approach (FDD or RUP or Agile XXX or ...) you completly need the adherence of the client and its financial service and it is very very difficult to change the mind of the financial service which probably does not understand all the subtlety of your concerns/view/arguments.
My remark is also that it is "easy" to introduce FDD, RUP, Agile approachs at the IT level but it far more difficult to introduce it at the client/financial one (I work in France !). And this aspect (client, financial) is rarely addressed or when it is, it is usually supposed that they adhere to this approach and only the collaboration with the IT team is described.
My conclusion is that the hard job is transform your client and its financial service view of the software development !
Thanks again
Fixed Price and Iterative
gollot
There is no inherent conflict between iterative development per se and fixed price development. Fixed price development (or any quasi-contractual arrangement) depends on fixing either scope or resources, i.e. you must have more-or-less fixed scope or fixed resources.
So if you fix scope (by a formal definition of requirements), then it doesn't matter to the client whether you (the developer) do iterative development or not, as long as you deliver the requirements.
The issue is that Agile development (including FDD) promote a collaborative rather than a contractual relationship. If you don't take advantage of this, then you will loose many of the benefits of iterative development. However, collaboration requires both parties to collaborate. You have to educate your client that they will reap the benefits of iterative development through a process of give and take in the light of what is discovered as iterations deliver new function. If the client wants to stick to the letter of whatever contractual arrangement you have - specifically a statement of requirements - then they will loose out on the opportunity to improve on requirements that iterative development presents.
You as the developer still gain the benefits of iterative development even if your client does not want to collaborate and wants to stick a fixed requirements definition.
Note that FDD is much better at fixing scope (requirements) up front than RAD derived Agile methods like XP, through the domain model created in process 1 and the fine-grained features list created in process 2.
My conclusion is that the hard job is transform your client and its financial service view of the software development !
I agree! But its not necessary (although it is desireable).
phil
Thanks
Thanks, Phil & Jeff to your comments
I agree with all of you but my opinion is (be carefull it's a hot think) that contracting should be a "Process discipline" (as we have requirements & analysis discipline in RUP) in all process description so that the process could be seen as less theoretical
"Process discipline"?
erik
I didn't really understand your last post.
What about contracting ?
I mean that in "real life", you've a lot of things to say about how to define a contract between a client and a supplier. In all "new processes" like iterative processes, nothing is said about contracting and if you do not modify the way you contractualize your relationship with your supplier (or your client, it depends who you are) it can be very difficult to adopt an iterative approach.
For example, take the Rational Unified Process, there's a first phase, the Inception, whose objectives are (among others) :
- Mitigate business risks
- Estimate a planning, workload
- Identify all use-cases and describe the major's ones
- Is the project feasible and financially worthy ?
1- Who do that ? ok, roles are described in the process but who has the roles, the client or/and the supplier ?
2- Is this phase done before or after contractualization ?
3- When can you contractualize ? Before the Inception ? After Elaboration ? Reimbursable, fixed-price, Reimbursable then fixed-price ?
What is your experience with contracting and the relationship you can have with your client or supplier ?
Well, so how do you, can you
I don't really understand the problem as stated. That is, I don't really understand how an Interative Approach to software development as to do with how contracting is done.
"So, when do you discuss the contract ? At the end of the RUP phases ? Add the end of some iterations ?"
I negotiate a contract when my customer wants to. Sometimes I motivate him a wee bit :)
"it will be difficult t say to your client that this specific needs/feature/requirement was not specified."
Contracting is all about negotiation. You know the following:
"even if you know that this scope is not necessarily well defined"
So does your client.
So its all about business reasonability. Everyone knows that budgeting is an estimate (You and your client). The risks of these actions need to be shared amongst parties. How do you? You manage the risk of overblow the bufget. How? Commitment! If you client knows that you are commited to the success of his venture (How? Show him with real actions, deliver features as scheduled, help him to manage change), then its easier to negotiate your concerns within the scope of his (give some, get some).
The heurist provided by Jeff given the time spent to "build" the overall domain model gives you some pointers to estimate cost. If you client wants to discuss the contract prior to this then is a matter of negotiating a clouse that encompass this concern.
You bet that he will take this phase seriously then. Why do I say this? I've been in projects in Portugal that the client understood the concept of analysis, considered it important, but in practice they have shown little commitement to it (a couple of meetings and one or two presentations and that is it). But also I've seen development service providers that also don't understand that the development process is a learning process for clients too, so giving the impression to the client that is not really commited to solve his problem.
Nuno Lopes
You've a client if you've a contract
You said "The heurist provided by Jeff given the time spent to "build" the overall domain model gives you some pointers to estimate cost. If you client wants to discuss the contract prior to this then is a matter of negotiating a clouse that encompass this concern."
The problem, in France, is that before being THE supplier of your client, you often need to sign a contract (with engagements on budget, ressources and work)
Thanks for your point of view
You've a client if you've a contract
Absolutely. Here in Portugal too. Resource allocation is an estimate too.
I've mentioned Jeff heuristic mainly to measure time. And time is a component of a set of resources. One needs to estimate what can be a reasonable ammount of "staff" for the project at hand. Again this reasonability is an estimate that IMHO is for the supplier to cover the risk, unless the scope of the project suddently goes ballistic and then .....
The man/hour rates are essentially fixed according to the persons role on the project. Most companies have their rates set according to this and of course experience. There are people assigned to the project fulltime, and people assigned to the project part-time.
For instance a project manager (it depends on the resposibilities at stake) can possibly be allocated only 40% of the time, programmers and CP's 100% etc.
So back to time. If suddently the project that was expected to take 6 months (customer requirement) takes 1 month in the domain modeling phase something is really wrong. It does not really matter if you throw-in more people, IMHO, so something as to go, or one can negotiate the project to be done in stages, so the contract needs to change to cope with this new uncovered reality. Reality that is put in front of the customer as the company fully participated in the uncouvering the features that are required and where hidden bellow the business abstractions.
Nuno Lopes
A false dichotomy?
I suspect we are asuming a false dichotomy here. The dichotomy being either we do T&M i.e. no commitment to deliverables, or we do fixed deliverables (and to an extent fixed time).
Why not do T&M and fixed deliverables with continual (or periodic) negotiation on deliverables in the light of discoveries as development proceeds. Jeff has described how FDD supports this in a previous newsletter. It also ties into the next thread and Jeff's latest newsletter on budgeting and planning.
When I think back to projects I worked on that went well, most had this hybrid model, i.e. T&M, plus fixed deliverables that were regularly renegotiated. The negotiations also help both sides (development team and client) to appreciate the others issues.
I am also reminded of a old adage that someone told me, which is you can only negotiate if you are prepared to walk away (from the negotiation). You should remind your client that iterative development means they always (every 2 weeks) have a working system (although incomplete) unlike non-iterative waterfall processes where if they walk away from the negotiation they have nothing that works (until the end).
BTW I am not implying that FDD does not support fixed price
A false dichotomy?
Hi Bradley,
"I suspect we are asuming a false dichotomy here. The dichotomy being either we do T&M i.e. no commitment to deliverables, or we do fixed deliverables (and to an extent fixed time)."
If this was what came out of my comment then I have failed to communicate my message.
"When I think back to projects I worked on that went well, most had this hybrid model, i.e. T&M, plus fixed deliverables that were regularly renegotiated."
Excellent. I have not said the contrary I believe. By changing your phrase a little bit:
"cost that were regularly renegotiated."
Are you saying that you regurarly negotiated funding/cost? Becouse this is basically the theme that I'm tackling. If the answer is YES then I'm afraid that I have not yet experienced this in such terms.
"I am also reminded of a old adage that someone told me, which is you can only negotiate if you are prepared to walk away (from the negotiation)."
That is why I have not experienced yet what you seam to suggest. A customer will never negotiate the cost of the next few features unless he is prepared to walk away, and he can't walk away that easily in the middle of a project. That is why most customers want to negotiate a priori (Myself as a manager that is what I do).
Nuno Lopes
Walk away
Yes, prepared to walk away : that is the problem !
Trust!
Any good negotiation is about trusting parties. If the customer feals confortable re-negotiating cost in an ongoing project (I've never experienced this with new customers but can be possible) it means that the customer really feals confortable with the quality of your services.
I thought about it further, and yes I've experienced similar situations with customer that knew us from previous projects and/or where desperate!
There is another rule "first we try then we trust"
Nuno Lopes
Walk away
Hi Erik,
"Yes, prepared to walk away : that is the problem !"
I see no problem about that, honestly. That is I don't see this as an impedement to adopt an iterative approach to software development such as the one promoted by FDD. In fact it is a benefit for customers to adopt a process such as FDD becouse at least with this process if a Customer decides to walk away he knows where the development activity stands and why this decision was taken in more detail, so does the supplier actually.
Nuno Lopes
Renegotiation and walkway
Are you saying that you regurarly negotiated funding/cost?
Yes, on a T&M project (and this includes all inhouse development) any negotiation on delivery dates is a negotiation on costs and the reality is that most software projects miss their delivery dates (often for good reasons like scope changes).
I don't have figures to hand but a significant proportion of software projects get cancelled before they deliver (and sometimes after they deliver). A cancelled project is one where the client walks away. Some processes (methodologies) and I am thinking specifically of PRINCE build-in cancellation decision points.
FDD doesn't have explicit cancellation points but I would argue its implicit at every progress report.
I know from personal experience that some projects (too many) proceed when they should be cancelled precisely because the plan is unrealistic and senior management believes the plan.
FDD promotes realistic plans and therefore facilitates cancelling projects that should be cancelled for whatever reason which may have nothing to do with the merits of the system or the capabilities of the development team.
Business people should understand this.
That is why most customers want to negotiate a priori (Myself as a manager that is what I do).
As Jeff points out in his latest newsletter there are intrinsic limitations to up-front negotiations in software development.
Phil
Renegotiation and walkway
"Business people should understand this."
What if they don't care less (Executives and Managers). Honestly, unless we are talking about a multimillion dollar project this reasoning does not make sense at all in business terms.
I would risk to say that 90% of contracting is done as as Eric described.
Now my argument is that an Iterative Approach to software development does not constraint how contracting is done. In fact it should have little to do with it. If the contrary was the case then 99% of the books about managing the software development process would be of no use.
I'm talking about LEGAL contracts and the sustainning negotiation processes. We all know how harmfull it could be if we described FDD in legal terms or any other software development process in fact (unless legally required).
The question that we should ask ourselfs is why usually contracting is done as Eric described. I read Jeff's reasoning and I added some of my own.
We all know the drawbacks and its limitations. So why do business people still persist with this kind of contracting process? I've tried my best to describe why, we can just ignore it and say that contracting should be done in this way ...... becouse .....
The process decribed by Eric is very common, even great businesses (contracts) where made before a product or service ever existed.
Usually one sets a price for a service in advance, then set a payment schedule and method up front. We can negotiate delivery in stages, or simple state that stages X1...Xn should be left out from this contract.
Nuno Lopes
PS: Renegotiation implies that the previous contract does not fit the needs anymore. The problem is when do we know that it does not fit? It can be the supplier to ring the bell, usually the bell is the cost on his side, or the customer, the bell is deliverables are not being met, then we sit on the negotiation table and discuss the reason of such change (FDD helps on this due to its natural reporting structure that speaks "features" rather then technical concerns)
cancellation points?
"cancellation points?"
This notion is funny, as it reminds me of the risk of process embelishment as pointed out by Alister Cockburn in is book "Agile Software Development". Any manager resists signing a contract where he/she could only cancell it in some predefined dates otherwise .... :)
Conceptually I agree with you Phil in terms of how contracting should be done, it may work in some projects if not a lot, but I honestly have only experienced such in less then a handfull of projects and not that counciously.
FDD is great, I'm s trong supporter but I fail to see how can this process (or any other SDP) help me to negotiate contracts, or how it would not help me at all.
Nuno Lopes
They help
FDD is great, I'm s trong supporter but I fail to see how can this process (or any other SDP) help me to negotiate contracts, or how it would not help me at all.
It can help in several ways but it does depend on what kind of contract we're talking about.
If you are able to break the work into the smaller startup phase followed by a separately priced construction phase (as described here) then it helps a great deal. Now you have all the information from having done the overall model with the domain experts and all the requirements analysis that goes along with that, you have all the information from having broken down the domain and scope of this project into the feature breakdown structure, and all the information from having done the planning. And you've been paid to get all that information, and now with all that information, you get to price the construction phase.
You are dramatically better off than having to price before doing anything.
If however, this is the public sector (government) style RFT process then yes, you can't use this approach. So, you are no worse off then before. It's not that FDD hurts here - it does not- but it does not help either.
Then, having started, by using a feature breakdown structure and of the granularity that FDD does you are in a much better position to manage change and scope. Part of contract negotiation, even if you all insist it can only be a one-time up-front activity, is to manage the contract during the execution. That is - to stick to it! The feature breakdown structure (features list in FDD) makes this FAR easier to do. It's no silver bullet for changes or scope screep but it makes such things very visible and identifiable.
Finally, Agile methods value customer collaboration more. This affects how you go about contract negotation (as I think Phil is trying to communicate when the talks about iterative and feedback).
Jeff
Contracts, Waterfall and Iterative Development
I realize that many people try and write a cast-iron contract for a software development. But this can never work for the same reason pure waterfall doesn't work (and I would argue could never work). Iterative development results in feedback, including feedback into the requirements. If you don't use this feedback then I don't see any point in doing iterative development. In a contractual situation this means you must re-negotiate the contract.
PS: Renegotiation implies that the previous contract does not fit the needs anymore. The problem is when do we know that it does not fit? It can be the supplier to ring the bell, usually the bell is the cost on his side, or the customer, the bell is deliverables are not being met, then we sit on the negotiation table and discuss the reason of such change (FDD helps on this due to its natural reporting structure that speaks "features" rather then technical concerns)
Exactly, the feedback that iterative development provides, tells you when the requirements need to change.
So why do business people still persist with this kind of contracting process?
Because there is a widespread and false assumption that software can be purchased in the same way that other kinds of fixed assets can be purchased, e.g. buildings where accurate and complete requirements can be specified. David Anderson uses the example of lighthouses. Engineers have known for the last 200 years how to build a lighthouse that can withstand storms, i.e. comprehensive requirements can be specified and are in fact well understood.
One example of how discovery can result in a contract being cancelled happened to me about 20 years ago. In those days really thick printed reports were common. The company I worked for had a contract with a client to produce a particular report. The client was very keen on getting the report. The layout and content had been specified. The developers agreed it could be done and how long it would take and hence how much it would cost. A highly specific contract had been signed.
It was my job to manage the implementation. For scheduling purposes I had to calculate how long it would take to print. I realized this would be a *REALLY* thick report - about 150 ft (50 metres) high. When I explained this to the client he concluded he didn't want the report after all and the contract was cancelled.
phil