Dan P. wrote:
Cost - the project to be done for a low cost.
Quality - the project to be high quality (full of features or content
That’s scope, not quality. Quality is how clean, simple, robust, and DRY
your code is, and how deep your tests go.
Think of it as the amount of work needed. A project with a large scope
(many features, pretty code, lot’s of user testing, etc…) requires
more work and could be considered a higher quality product than a
project with a smaller scope (fewer features, sloppy code, no use
testgin, etc…). It’s the same difference.
Time - the project needs to be finished quickly.
Help the client define the two most important criteria.
If the client picks cost and quality, then time to complete the project
will be longer.
That means the client has requested more scope. To get there, do the
high-business value things first, deploy continuously, review often, and
seek every opportunity to exclude scope.
That’s has more to do with project management work flow than pricing. A
larger scope (for example adding more features) usually means the
project will cost more and/ or take longer to complete. The order of
tasks and deployment strategies are consistent enough in my environment
from project to project so I can use the formula and not itemize those
out as a separate issue or price each time.
If the client picks cost and time, then the quality will not be as high
And that is indistinguishable from your first iteration with the above
formula. So if the client wants early deployment, they get a lite
with a few high-value features, but it’s useful early. (And thanks to
ActiveRecord migrations, Capistrano, gems, and plugins, you don’t need
bury yourself in rendundant details.)
An early deployment is still a deployment with a date on it and all
features should be useful and have some value. In general keep in mind
that scaling down the number of features for your project should mean
less time is needed and lower the cost. You might price each deployment
by the amount of work needed to develop the necessary features at each
stage if it helps.
A low cost project created in little time usually has less features than
otherwise. If your client spends more, they get more, bottom line. If
your project has a large scope (no matter what technology or methodology
is used) it will costs more or takes longer to compelete.
The first iteration refered to cost and quality instead of cost and
time. Say the client wants bug proof, acccessible, validated, pretty
printing, highly commented code - that takes a little extra time to do
compared to just hacking something together. The quality vs. time needed
is a fundamental difference that should not be overlooked in pricing.
If the client picks quality and time then the cost goes up.
How? How do you get more features in less time?
Hire more people is the typical way. If you have more people working on
a project then they can each be working on different features at the
same time (or in more groups of two if you prefer). More eye’s looking
for bugs can catch more of them quicker for example.
Another way would be to buy a prebuilt solution that can be modified
rather than building from scratch. It always takes longer and costs more
to create a custom solution compared to buying something that’s close
and extending it.
It ultimately depends on your situation, constraints, and creativity.
You can’t lower quality, because that will make you go slower, and will
the “pay as you go” and “just-in-time requirements” formulas.
Higher quality does takes longer to achieve. Creating a lower quality
product should not take longer. If you spend 100 hours on a project and
it’s of lower quality, or has less features, than an project you spent 1
hour on, there’s something wrong. Lower quality should not be taking
I’m not familiar enough with the pay-as-you-go and JIT requirements to
understand how they effect the cost, quality, time formula.
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Hope that helps!