Software on Budget and on time?

Question

We've all (almost all) have heard about the horror stories as well as perhaps studied about them.

Its easy to find stories of software that is over budget and late.

I wanted to hear from developers the opposite story:

Question:

Do you know, or have worked on a project that was on budget and on time?
What is the most valuable lesson you learned from it?

The terms 'budget' and 'time' are mutually exclusive. You have six to eight weeks to choose one. — Tim Post, Nov 30 '10 at 15:11
@Tim not true: You can have it on time and budge, you just have to vary the number scope. — JohnFx, Nov 30 '10 at 15:35
@John Phrases like "number scope" frighten me. I understand you can achieve the _appearance_ of on time and on budget, however. — Tim Post, Nov 30 '10 at 15:41
Sorry, that was a typo. I just meant "scope" not "number scope" — JohnFx, Nov 30 '10 at 15:46
@Chad - Sorry, that's misleading. You can be on time, on budget and on scope but you can only specify what two of them will be and the final one will be determined by those two. — Jon Hopkins, Nov 30 '10 at 17:16
@Jon It isn't even that simple. You can't just pick the budget and scope you want. Otherwise I'd say I want to implement all the features of Excel for $1. No, the triangle analogy is just about which variables you can optimize for. You can favor scope at the expense of time and cost, and then decide to decrease time at the expense of cost but its not like its just a free parameter you can set. — Jeremy, Nov 30 '10 at 19:49
@Jeremy - Agreed, the phrase "within reason" is probably useful here, but it's not as Chad stated where he effectively implies that it's not possible to deliver a project on time, to budget and on scope. It is, just so long as those three have been properly set. — Jon Hopkins, Nov 30 '10 at 20:01
My version of Chad's statement is "It can be done quickly, cheaply, or correctly, pick any two." — AShelly, Nov 30 '10 at 20:07
@Jeremy: actually, given a lot of time you can have all the features of Excel for practically free (just look at OpenOffice.org). You just don't get to define the schedule. — Scott Whitlock, Dec 01 '10 at 01:06
@Scott Whitlock It wasn't free. Sun put a lot of money into it; even unpaid time spent on open source software has a cost - an opportunity cost if nothing else. — Jeremy, Dec 01 '10 at 02:43

Jon Hopkins · Accepted Answer · 2010-11-30T15:18:22.203

8

Yep, I've seen it happen.

Key elements:

1) Well defined requirements, clearly agreed, with a solid change control process.
2) Developers involved in the estimates, with no pressure on them to produce estimates which were what the client wanted to hear, just what they really thought would be needed to complete the work properly
3) Estimates that also took account of risks and uncertainties
4) Facilitate early feedback from the client - we've provided videos, demos (hands on and hands off depending on stability) as early as possible
5) A stable team whose availability has been realistically figured into the schedule (for instance if they spend a day a week doing support and admin, then they're only expected to complete 4 days a week work on the project)

It's not rocket science but removing the commercial pressures and, critically, getting the requirements clear and controlling them is challenging (and where things normally fall down).

edited Nov 30 '10 at 15:18

answered Nov 30 '10 at 15:04

Jon Hopkins

22,734
11
90
137

The OP didn't mention anything about requirements, only time/cost as constraints, so this answer seems wrong to me. – Martin Wickman Nov 30 '10 at 15:40
1

@Martin - Either I've misunderstood you or this is a very curious idea. If there are no requirements then what are you delivering? There are always requirements, the questions are when during the process you get them and how you manage them. If there aren't requirements then how could you possibly be late as there is no way you could possibly know whether you've finished. – Jon Hopkins Nov 30 '10 at 17:14
@Jon: He didn't mention requirements as a constant constrain, only the other two as being constants. For instance: "Build me a corporate web site. I want you full time on this for the next 20 weeks. We'll work on the user stories (requirements) continuously, iteratively based on the feedback I get from testing the releases I expect to see from you at the end of each week" (agile). No requirement constraints, only time/cost. You with me? – Martin Wickman Nov 30 '10 at 18:00
@Martin - that's clearer but if you're allowed to descope then hitting deadlines is frankly child's play. My reading of the question (and I'm happy to be wrong on this) is that that wouldn't be an option. Personally I'd happily accept answers involving agile methodologies as a potential solutions / contributions but my understanding is that agile is good not necessarily because it hits a defined scope but because it hits a scope which gets continually redefined based on what's really important. – Jon Hopkins Nov 30 '10 at 20:03
@Jon: Check my "extended" version of my answer here: http://programmers.stackexchange.com/questions/22597/does-late-have-any-meaning-in-agile-methodologies/22655#22655 (great question btw!) – Martin Wickman Nov 30 '10 at 21:52
+1 but you forgot "6) luck". Because estimates are, by definition subject to being wrong, you can take into account risks and uncertainties but you can never know what the unknown unknowns will be. – Alb Feb 03 '11 at 23:25
@Alb - I'd sort of turn that round and say the absence of bad luck, You can count on regular levels of misfortune and inaccurancy, it's the big things that tend to really mess you up. – Jon Hopkins Feb 04 '11 at 07:59

score 1 · Answer 2 · answered Nov 30 '10 at 14:39

The first time I worked on an agile like project (Agile wasn't a term used then). We learned that working daily with the client and prototyping ideas (either screenshots or business workflows) that the users could actually play with kept the project focussed, fun and in the end delivered exactly what the client wanted, on time and on budget.

It helped that the client were really focussed on their vision and that I was blessed with a pretty talented team that worked really hard during the working day and were able to socialise/bond afterwards as well.

score 1 · Answer 3 · answered Nov 30 '10 at 15:51

I did it a couple of times. What was common was that the client didn't really knew what they wanted, so i wrote the specs :-)

Well, in fact one of them was "we need something to manage our image library", so i knew they needed a DAM. just a few questions more to get their workflow, and then I was free to write one to fit that.

The second time was after a first quick version of a system where we got very positive reviews on everything except a single feature that was admittedly very crude (because we had to deliver quickly the first version). I just closed my door and promised the next version would fix that. Since we already knew that part wasn't good we had planned for the second version and could focus on that part of the code, knowing the rest was (almost) ready for the enhancement.

I do this quite a bit with my clients. They tell me roughly what they want, I develop the specs for it. Along with the specs I give them a rough mock-up of what it will do/look like. They typically sign off on the specs based upon the mock-up. Most of the clients I've worked with could (generally) care less what the spec said as long as it did what they wanted. — Ken Henderson, Dec 01 '10 at 03:31

score 0 · Answer 4 · answered Nov 30 '10 at 14:48

0

You can get two out of the three from this list correct before the work starts:

Budget
Schedule
Feature Set

To get the missing var, you have to start the process and measure progress based on the missing data.

If you want to be on budget and on time, you have to be working on the assumption that the feature set must be flexible. Agile methodologies happen to make this same assumption.

answered Nov 30 '10 at 14:48

sal

2,078
1
15
19

1

Just make budget=infinity. – Michael K Nov 30 '10 at 14:49
Yes, just keep writing the most important features until your time is up. Agile in a nutshell. – Martin Wickman Nov 30 '10 at 15:02
This isn't true. What you're thinking is that if you specify two the other one will be determined (e.g for a specific feature set and schedule there is a defined cost). That doesn't mean you can't plan in advance or have to flex them, it just means that you can't *state* all three. What's more if you don't specify a feature set and a schedule (at which point the budget is determined) the concept of "on time" is meaningless - if you don't say what you're going to deliver by time X then all that's happened is that you've worked up to a specified point in time. – Jon Hopkins Nov 30 '10 at 15:10
Also, if you allocate more budget and time than you think you'll need for the desired features, you can absorb problems and still keep the feature set. If you get through the desired list before running out of time and money, you can add more features or just deliver. There's a certain amount of wiggle room, and you don't have to nail one or two things down firmly and force the wiggle room all on another. – David Thornley Nov 30 '10 at 15:10

score 0 · Answer 5 · answered Nov 30 '10 at 15:29

I had only one client in my life where all projects were completed on time and budget was steady -- It's my University where I studied and worked in a computer lab for science. For tasks, that most companies ask to finish in 1-2 months, in University we had a year. In companies they give you $N per hour, after a while they say "We lost some clients, dudes outside stole my bag with your salary, boss divorced with his wife and she wants a half of his biz, ..." etc. and your fee decreases by $K, then by $K again, and again. Until you think that you must pay for what you do. In University they have a tender for $XXX,XXX.XX divided on: rector, managers, you supervisor, some other people, your co-workers (mostly other students), and you.

Of course this is much less money than you can have in companies, but for a risk you should pay.

score 0 · Answer 6 · answered Nov 30 '10 at 15:36

Yes, I've worked once in such a kind of project. It was a not so little web application for documents managing, for a quite big company, in which the different documents could be categorized at different nodes, supporting meta-data for documents and nodes, different authorization levels, etc. the key points for me were:

Clear, concise, and well defined requirements,
Management focused in ease the developers work, not in watch their work, control it, or urge developers. About this, in the final rush, the manager just told everybody "boys, we have to deliver next week. Let's try to get in time", and everybody did our part to reach the target. Trust is a key word for me at the team management.
Spending time at the system modeling phase, is not at all a waste, but a investment. A detailed design saves lots of development hours.
And last, but not least, a good relationships among the team members, and a friendly environment, do more for productivity than we are used to think.

score 0 · Answer 7 · answered Dec 01 '10 at 00:16

We built a web based multiple listing service application. The first one took the most time but the idea was to build a solid app that could be cloned quite easily. While a fair amount of R & D went into the first one, we were able to turn them out fairly quickly and did make a profit on each one we sold.

I don't work there anymore but it's still a good application.

Webfodder MLS Application

Software on Budget and on time?

7 Answers7

Linked