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?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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

1. Budget
2. Schedule
3. 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.

Answer 5

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.

Answer 6

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.

Answer 7

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