Working with fixed budgets, or by project, is a common practice in the IT world that I too endure as a consultant. However, from my point of view and experience, an R&D software project with a fixed project is a missed opportunity to create a great result with great value and, moreover, it can compromise quality. In this article, I’m going to explain why.
The Project Management Triangle is well known in software project management theory as a way to represent the constraints a project may have. On its corners, time, scope and budget (or schedule, scope and cost) shape the boundaries of the project, and quality is a by-product of the combination of these.
It is important to notice that quality is not a variable we can choose upon; otherwise, trying to meet the three axes at the same time – which happens more often than not – will inevitably lead to lousy products by decreasing quality. Think about it: if we are running late, and our budget is fading away, and we still have to keep scope… the easiest and perhaps only way to carry on is by working fast, making poor decisions and neglecting details. This is well explained by Ben Scheirman in his squirrel burger story.
So we have three axes with three variables; each one of them is a project constraint. We can choose whether to adjust one, or any combination of two of them – since fixing the three would get us a squirrel burger, and we don’t want that!
Working With Fixed Budget Projects
When fixing the budget variable, all we can choose is when the project is delivered, and what is the scope delivered. This is when reality strikes in.
As an IT consultant, I have too often seen the following pattern: a client wants a project done; she is quite sure about the scope, and she definitely has a delivery deadline – though this one can be somewhat flexible sometimes. Now all she needs is a quote so that she can get the funds and contract the job to a well-skilled software engineer or firm.
What happens next, is a matter of where the client and contractor agree to put the risk: whether on the client, whether on the contractor. Just google “fixed price vs time and materials” and you’ll get a glimpse on what I mean. Bottom line: budget and schedule go often hand by hand.
Fixed Price Strategy
This approach will put the stress on the contractor. By setting a fixed budget, given also a fixed scope and no matter which time frame, what happens is what we see too often in the industry: quality gets affected. But why?
It is partly because, in most cases, estimations are optimistic guesses.
Imagine the project is late. This contractor has other projects to work on afterwards, so she is interested in finishing on time. But, for one reason or another, she did not estimate the workload well – most probably, because of theCone of Uncertainty. This is a classic problem in Waterfall Project Management: there is so much unknown variables at the beginning of a project, that too much effort is spent in estimation and planning at the beginning, and eventually the scope becomes immutable because of the high inertia acquired. It’s like going to the Moon by firing a huge cannon: you better aim well first.
Back to the example. The contractor failed in correctly estimating the project’s workload. The deadline is approaching and she has to finish this project no matter what: she has other commitments to attend afterwards or, even worse, she depends on the money to pay her bills – as we all do! She is getting nervous and tries to change scope, but this is not negotiable and budget is fixed. Remember the Project Management Triangle: if time, budget and scope are fixed, we can only compromise quality!
What happened here is that fixed-price projects are a classic trap to contractors because they will also be constrained by scope and time by the client, almost without them – the contractors – ever realising it. The cannon backfires and affects the client, who gets a low-quality product, and so it turns out that putting the stress on the contractor impacts negatively the client too!
Let’s imagine the complete opposite scenario: the contractor will finish the project before schedule. What will happen then? Will she charge less for her services? The price was fixed, right? The more common practice here is a small reduction in the bill (as a good faith token) which means and an increase on benefits for the contractor – well deserved for her productivity, no question on that. In any case, the client is missing an opportunity, whether to get an astounding product, whether to save some money.
Time And Materials Strategy
This approach, unlike the previous one, will put the stress on the client. It lets both time and budget to be flexible, and fixes the scope, without compromising quality at any level – we don’t want squirrel burgers, remember?
The risk lays on the client’s side with this strategy because, not being able to estimate when the project will be finished, it is too easy for the cost to be higher than she can afford. Moreover, the contractor may relax and see that no matter what pace she works at, she will be paid regularly anyway, and so there is aconflict of interest: the client wants the project to be over as soon as possible, the contractor wants to delay it as much as possible.
In the best case, from this unsupervised and uncontrolled scenario will come up a rather good application for the client. In the worst case, the contractor will end up consuming the client’s money, and not really adding any value. Both ways, this is again a missed opportunity: for the client to get something valuable for her money; for the contractor to create a remarkable product.
My Approach: Continuity
Image by Planbox – Licensed under CC BY-SA 3.0 via Wikimedia Commons.
I confess myself Agile, and therefore I instantly love any project management methodology that allows a continuous flow of quality work done, in the form of iterations no matter their length – but the shorter the better! By providingcontinuity to a software development project, the time variable is removed and the uncertainty reduced: the client gains control over the budget and the scope is constantly adapted to match real user needs.
Software development is a complex task. It is a highly creative process whose outcome is very difficult to predict – not to say impossible! From my point of view and experience, time and budget are actually always tied, since money/time is the real variable a contractor needs to know whether she will pay the bills, which leads to the conflicts of interest we saw before. In a real world, one cannot change one without affecting the other.
Looking at the project management triangle again, we can realize that, if we don’t want to compromise quality, and given a fixed amount of money and time, the scope is the only true variable in the equation; but a fixed scope is too riskyfor an R&D software project because of the cone of uncertainty I introduced before. Again, there may be a conflict of interest that impacts quality.
Continuity is here provided by following an Agile iterative project management methodology, so that the scope evolves as the project is developed. This way, the user and client feedback is taken into account, from the very early stages, and after each incremental iteration.
A Hybrid Agile Methodology
A screenshot of Comodoro: A Micro-Project Management Tool.
The best approach for this project management problem I have found so far is a custom, personal, hybrid methodology that mashes up concepts from Scrum, Kanban, Visual Management, along other philosophies. It is based on Corey Lada’s Scrumban book, which describes a way to go from pure Scrum to pure Kanban, with degrees of freedom in between.
From my point of view, the best way to approach this highly creative and innovative R&D projects is to start with an MVP (Minimum Viable Product) and then keep on delivering PSIs (Potentially Shippable Increments). This allows to fix a small initial budget for the MVP, knowing that afterwards, either the money will flow in from sales or investment, either the idea will be abandoned or frozen as it does not bring value to the customers. This initial budget is just for a collection of absolutely necessary features, which will move to a flexible scope as the project evolves, the initial uncertainty is reduced and the user feedback is considered.
The most important point here is the way time is no longer really a constraint when we work in Agile mode. Scrum defines sprints and velocity: two-to-four-week iterations that will set the development pace; Kanban uses continuous flow and cadence: the amount of features that are added to the project by unit of time. In both cases, we are removing time from the equation and replacing it with an indicator of the “speed” of development. Since we are delivering PSIs with every iteration, both time and budget can be controlled and scope can better adapt to the other two constraints..
To Sum Up
So… if neither time or budget are important… what is?
It is a matter of shifting the paradigm to me. Instead of focusing on grasping what is by definition unattainable (consistent estimation and planning), I focus on adding value in a regular time basis. Doing weekly sprints, for instance, is a good way to realize within a month how long the project may take and how expensive it may be. Working in Potentially Shippable Increments ensures that the client will see value early in the development process, getting a better idea of how the outcome fits her needs; this may lead to changes in scope that could not be anticipated otherwise, and will produce a piece of software that fits user needs better. Finally, the client gains control and visibility over the development process, and can step in to correct the scope, adjust the development pace or budget, as the incremental outcome matches her expectations.
This is the best way I know to deliver quality of both result and service. Of course, this is just my opinion from my own experience and knowledge. I will be glad to read your ideas on the subject, so please leave a comment!
Interested in project management? You can join me on skype to discuss further: jorge.albaladejo.