Showing posts with label budgeting. Show all posts
Showing posts with label budgeting. Show all posts
Tuesday, October 12, 2010
InfoQ: Agile Team Meets a Fixed Price Contract
I found another interesting article on fixed price contracts managed in an agile way. It also adds some considerations on budget spent, which you don't normally find in articles of the same kind.
Wednesday, April 16, 2008
Estimating blasphemy?
I am working with my team on a new project; we still are in the Inception phase, so even if our ideas are quite clear there are also many foggy aspects. Anyway, we've identified almost all the stories we shall need (the domain is well known) and we are estimating them with story points.
This project will be quite different from all the others we've worked on for many different reasons, so there will be a lot of uncertainity; I then reported to the management that our first estimate will actually be a guesstimate, thus possibly ranging from 60% to 160%. The Project Management Institute (PMI) has an equally broad, but more pessimistic, range for this stage of the project (75% to 175%).
As expected, the management reaction was less than cold, and I was told we had to narrow the gap between the worst and best estimates - a perfectly legitimate request. The problem is that we do not have enough informations at the moment, and only when we'll have an approved product definition we will be able to get to an 80% to 125% range (close enough to the PMI budgetary estimate), but luckily that should happen in a few days.
I'm afraid that will not be enough, because the second question after "how big will it be?" is always "how much will it take?", which obviously leads to "how much will it cost?". Estimates in story points are only a pure measure value, and a duration must still be derived. We cannot use our historical velocity values because, as said, this project is very different from the ones which generated them, so we'll have to run at least a couple of small iterations, observe the values and make a more or less reliable forecast.
Luckily our managers deserve their jobs and they understood our motivations, so I've been able to reach an agreement upon a spike in which we will very lightly touch all the layers of the application and the new technologies we've identified in some previous pilots.
This was another example of how an honest conversation can lead to a win-win situation: the team will not have the pressure of an irrealistic plan and the management will be able to take decisions and actions on the basis of sufficiently reliable informations.
This project will be quite different from all the others we've worked on for many different reasons, so there will be a lot of uncertainity; I then reported to the management that our first estimate will actually be a guesstimate, thus possibly ranging from 60% to 160%. The Project Management Institute (PMI) has an equally broad, but more pessimistic, range for this stage of the project (75% to 175%).
As expected, the management reaction was less than cold, and I was told we had to narrow the gap between the worst and best estimates - a perfectly legitimate request. The problem is that we do not have enough informations at the moment, and only when we'll have an approved product definition we will be able to get to an 80% to 125% range (close enough to the PMI budgetary estimate), but luckily that should happen in a few days.
I'm afraid that will not be enough, because the second question after "how big will it be?" is always "how much will it take?", which obviously leads to "how much will it cost?". Estimates in story points are only a pure measure value, and a duration must still be derived. We cannot use our historical velocity values because, as said, this project is very different from the ones which generated them, so we'll have to run at least a couple of small iterations, observe the values and make a more or less reliable forecast.
Luckily our managers deserve their jobs and they understood our motivations, so I've been able to reach an agreement upon a spike in which we will very lightly touch all the layers of the application and the new technologies we've identified in some previous pilots.
This was another example of how an honest conversation can lead to a win-win situation: the team will not have the pressure of an irrealistic plan and the management will be able to take decisions and actions on the basis of sufficiently reliable informations.
Friday, January 25, 2008
Agile budgeting
How do you build a plan for a new software project? There are different approaches, each of which has its peculiarities; I shall discuss them shortly.
Agile teams are very well aware of the fact that requirements do change, so they don't try to prevent it but ride the wave, focusing on delivering, iteration after iteration, the highest priority requirements: they are happy because they will deliver high quality software, they know their customers will be happy because they will steer the project according to their evolving needs... and they lived happily ever after. Until they talked to the management:
WHAT? NO FIXED PRICE? NO FIXED SCOPE? POSSIBILITY FOR THE CLIENT TO CUT THE BUDGET? AAAAARGH! YOU'RE FIRED! YOU'RE ALL FIRED!
I'm exaggerating of course, but I'm sure you get the point. Well... OK, that's what we'll do: we shall meet the customers, explain to them how they will get only the functionality they really need, how they will always be in control, how they will decide how their money will be spent, and all the other advantages of an agile incremental and iterative approach. So they will talk to our management, persuade them, and tell them they are really enthusiastic with our proposal and that we should get a considerable pay raise. Actually they go more or less like that:
WHAT? NO FIXED PRICE? HOW MUCH WILL IT COST? HOW LONG WILL IT TAKE? AAAAARGH! GET OUTTA HERE! GET OUTTA HERE RIGHT NOW!
Well, we have to reconsider... Agile approaches are really great, but the difficulty lies in persuading a traditional management. Let's take it from their own point of view.
In a traditional approach you spend a lot of time to write a long (and when I say long I mean very, very long) and comprehensive requirements document - which probably no one will ever really read - which in turn is, more or less, accepted by the contractor. At this point you have already invested a considerable amount of resources, but project managers have enough informations to precisely schedule everyone's work for the next months, and that allows them to estimate a fixed price. That makes the management happy because they think they are dealing with the risk of scope creep in an effective way, and customers happy because they know in advance the amount of money to allocate for the project.
That sounds great. But let's face the facts: studies show how 19% of the initial requirements are only rarely used, while 45% are not used at all. And the requirements have changed. They have changed a lot. But the plan did not. So, when the project comes to an end, customers, which have paid a lot of money, will not be happy because they won't have what they really need, managers will not be happy because customers complain, and the blame will be "on those weirdos who developed all this crap".
How can we have happy developers, happy managers, happy clients? a succesful approach is to divide the project in different phases, just like in UP, and contract for the elaboration phase at a fixed price, than use an agile Just-In-Time (JIT) approach for the construction and transition phases. During the inception you only get enough informations to estimate the scope of the project (yes, with this intermediate approach we still want to avoid big creeps) and to do enough architectural modeling to have a sufficient basis on which to produce an initial schedule and budget. In the next phases you let customers steer the project with an agile approach: they'll be more willing to do it because they'll already have the core of the new working, although incomplete, system, and the risks will be smaller. The management will have a reasonable estimate, which will improve iteration after iteration.
Still too extreme? You can follow UP and have two fixed price contracts, the first one covering the elaboration phases, and the second one covering the construction and the transition phases.
And you would get that pay raise, after all.
Forget that. "Money, so they say, is the root of all evil today. But if you ask for a rise it's no surprise that they're giving none away". Thanks to Pink Floyd for the tip (pun intended).
Agile teams are very well aware of the fact that requirements do change, so they don't try to prevent it but ride the wave, focusing on delivering, iteration after iteration, the highest priority requirements: they are happy because they will deliver high quality software, they know their customers will be happy because they will steer the project according to their evolving needs... and they lived happily ever after. Until they talked to the management:
WHAT? NO FIXED PRICE? NO FIXED SCOPE? POSSIBILITY FOR THE CLIENT TO CUT THE BUDGET? AAAAARGH! YOU'RE FIRED! YOU'RE ALL FIRED!
I'm exaggerating of course, but I'm sure you get the point. Well... OK, that's what we'll do: we shall meet the customers, explain to them how they will get only the functionality they really need, how they will always be in control, how they will decide how their money will be spent, and all the other advantages of an agile incremental and iterative approach. So they will talk to our management, persuade them, and tell them they are really enthusiastic with our proposal and that we should get a considerable pay raise. Actually they go more or less like that:
WHAT? NO FIXED PRICE? HOW MUCH WILL IT COST? HOW LONG WILL IT TAKE? AAAAARGH! GET OUTTA HERE! GET OUTTA HERE RIGHT NOW!
Well, we have to reconsider... Agile approaches are really great, but the difficulty lies in persuading a traditional management. Let's take it from their own point of view.
In a traditional approach you spend a lot of time to write a long (and when I say long I mean very, very long) and comprehensive requirements document - which probably no one will ever really read - which in turn is, more or less, accepted by the contractor. At this point you have already invested a considerable amount of resources, but project managers have enough informations to precisely schedule everyone's work for the next months, and that allows them to estimate a fixed price. That makes the management happy because they think they are dealing with the risk of scope creep in an effective way, and customers happy because they know in advance the amount of money to allocate for the project.
That sounds great. But let's face the facts: studies show how 19% of the initial requirements are only rarely used, while 45% are not used at all. And the requirements have changed. They have changed a lot. But the plan did not. So, when the project comes to an end, customers, which have paid a lot of money, will not be happy because they won't have what they really need, managers will not be happy because customers complain, and the blame will be "on those weirdos who developed all this crap".
How can we have happy developers, happy managers, happy clients? a succesful approach is to divide the project in different phases, just like in UP, and contract for the elaboration phase at a fixed price, than use an agile Just-In-Time (JIT) approach for the construction and transition phases. During the inception you only get enough informations to estimate the scope of the project (yes, with this intermediate approach we still want to avoid big creeps) and to do enough architectural modeling to have a sufficient basis on which to produce an initial schedule and budget. In the next phases you let customers steer the project with an agile approach: they'll be more willing to do it because they'll already have the core of the new working, although incomplete, system, and the risks will be smaller. The management will have a reasonable estimate, which will improve iteration after iteration.
Still too extreme? You can follow UP and have two fixed price contracts, the first one covering the elaboration phases, and the second one covering the construction and the transition phases.
And you would get that pay raise, after all.
Forget that. "Money, so they say, is the root of all evil today. But if you ask for a rise it's no surprise that they're giving none away". Thanks to Pink Floyd for the tip (pun intended).
Subscribe to:
Posts (Atom)
