Cost, schedule, quality: pick two

Question

We have heard the adage, "Cost, schedule, quality: pick two." It has been my recent experience on big government projects that quality often suffers due in part to schedule constraints. In fact, sometimes project managers choose schedule with little apparent regard to quality and sometimes little regard to cost.

Are you asked to compromise? What are your experiences in commercial worlds? When you are the program manager - perhaps you are self-employed or work on projects at home and on weekends - and you control cost, schedule, and quality, do you "pick two?" Do you have favorite parts of your development methodology(ies) for which you never compromise (e.g. automated testing)?

Finally, which development methodology do you suggest for a team forced to choose schedule and cost over quality? Thanks in advance.

I suggest we vote up well-reasoned comments.

Answer 1

SCRUM with adequate SCRUM software.

SCRUM is an agile Software Development methodology where all the tasks of a project are simplified down into task-groups called sprints. It's an excellent way to keep track of all of the tasks for a specified person, and the number of hours of project planning it's saved is is absolutely invaluable.

Give it a go - you wont turn back, I'm sure.

Answer 2

I recommend Scrum. It's an agile development framework, focused on iterative development phases, whereby at the end of 3-4 week development intervals, you have a tangible product at the end of each 'sprint'. Then at the end of each sprint, you go over as a team what worked last round, what can be improved, and you mitigate any changes in requirements you may have.

It's really good in a government environment where people change their minds all the time as they come to a better understanding of what they want from developers, in terms of what the final product should look like, because if the product lead completely changes his or her mind, the developers can still have a sense of accomplishment for having handed off a deliverable that should be usable.

http://en.wikipedia.org/wiki/Scrum_%28development%29

Answer 3

If you're choosing schedule and cost then worrying about methodology is the wrong thing to do. Go code. Code as fast as you can. Feel free to do dirty hacks that work, so long as they allow you to make the schedule without bringing on additional developers. Remember, if quality actually doesn't matter then maintainability and testing is not really important since those are both quality issues.

Somehow, reading that, I doubt that you actually want to ignore quality completely :)

Answer 4

It's been my experience that rather the opposite is true: concentrating on quality (especially early on) tends to reduce cost and schedule. From what I've seen, I'd say most projects that have serious overruns do so mostly because they get close to what they thought was the end, and they find that their code doesn't work. At that point, they try to fix things by putting in lots of extra time debugging and such, but it's really too late to do much good. Worse, they have to undo quite a bit of what they did, because some parts depend on poor design decisions elsewhere and such.

Answer 5

In my experience, you will always be asked to compromise something. It will differ based on different clients.

You can personally refuse to compromise on certain aspects, but sometimes the only way to do so will be to change projects or jobs.

SCRUM and other methodologies are ways of managing the compromises and making them apparent to your managers and clients. They do not prevent compromises.

Lastly, remember that these are not binary attributes. You will balance how much "quality" can be compromised in different aspects of your project (DB vs GUI, Reporting vs Computation etc), and balance that against speed and cost. You don't "pick two." You make thousands of different decisions to meet the needs of your client or manager.

Answer 6

I live in the world of the classic waterfall SDLC, and we have client-driven deadlines. So for us, schedule is top priority. Cost isn't really so important to us because we estimate and bill the client before work begins. To balance the two and still achieve decent quality, we developers try to overestimate the amount of work any change will take, giving us adequate time and resources to do the job well. It's a bit slimy but it's a good workaround.

Answer 7

"Cost, schedule, quality: pick two."

That's the traditional statement, but aren't there four parameters not three? There's low-cost, short-schedule, high-quality, and high-quantity: you can maximize any three of these if you can sacrifice the fourth.

Are you asked to compromise? What are your experiences in commercial worlds?

When someone asks something of me, my cost is fixed (i.e. my rate per hour or per year), so ignoring costs.

The quality varies somewhat: some kinds of reliability look for additional written design and documentation associated with the software, whereas for other types of software they might say "as long as the software works we don't mind whether you write any documentation". I always experience an implied minimum quality level (e.g. any/all noticeable-at-runtime software bugs must be fixed).

I tend to insist on short schedules: other people might have long-term, multi-year plans, but I typically "sign up" or commit to doing something for the next few days or few weeks: longer than that and I'm not comfortable estimating it (and it probably isn't well-defined).

Therefore, the sacrifice is quantity: I want people to give me a little bit at a time, preferably one job at time (see also the words "sprint" and "iteration").

When you are the program manager - perhaps you are self-employed or work on projects at home and on weekends - and you control cost, schedule, and quality, do you "pick two?"

I sacrifice schedule; I don't care how long it takes, so long as:

• Cost is fixed/zero (i.e. I'm the only one doing it, pro bono)
• Quality is acceptable
• Quantity (or functionality) is as planned

I may reach a point where I run out of schedule, i.e. I decide that I can't afford to continue working on the project: at which point I sacrifice (the remaining unimplemented) quantity. Planning for this eventuality, it may be relevent to remember that it's sometimes better to have finished 50% of the project than to have half-finished 100% of the project (i.e. better to have half the functionality finished and usable than to have finished nothing).

Do you have favorite parts of your development methodology(ies) for which you never compromise (e.g. automated testing)?

1. Source code that's tidy enough for me to understand: software runs as expected on the computer only because I was able to, first, run it in my head.

2. Also I insist on testing software. It doesn't have to be unit-tested (instead, system-testing is OK) but in spite of my bravado about about its running in my head I won't guarantee anything that isn't tested. My boss used to say, not "you get what you expect" but "you get what you inspect".

3. For a long-running project, the tests need to be automated. I'm willing to refactor (see point 1 above) and I therefore need to run regression tests. If the tests were manual then the cost to run them would be proportional to the amount of code, so the time required for testing would increase as O(n squared), i.e. it would be too expensive if it weren't automated.