On Thu, 01 Apr 2010 12:48:37 -0700, Richard Clark
wrote:

On Thu, 1 Apr 2010 10:56:44 -0700, "Joel Koltner"
wrote:

Software projects by "professionals" are quit all the time -- there's some
shockingly low percentage of software projects that are ever actually finished
(like, 25%). Even for hardware projects, at least for awhile Tektronix
seemed to be quitting upwards of a quarter of all the projects they'd start.

Pulling the plug on an IT project is not necessarily a bad thing. A
project I've been working on has changed functional scope four times
in the last nine months. Is it any wonder the project is six months
late?

WHOOSH - the sound of a deadline flying by.

Business owners and project managers are reluctant to make any
admission of poor decision making. Being able to say the project is
'done' is how too many measure success. User adoption and satisfaction
always seems to be secondary. Arbitrary due dates are determined
before any real analysis of the problem and potential solutions is
made. Requirements fall by the wayside as EOQ or the day after
Thanksgiving approaches. Project managers, especially the
non-technical, often fail to manage their own unrealistic
expectations. Over-promised and under-delivered is an unfortunate fact
of life.

Usually a problem of poor specification. You cannot design what is
not described. Frequently, success is in the mind of the beholder:
"Oh! I forgot to mention you need to....(gestures made here). You
know what I mean."

Absolutely. Deliver exactly what the customer asked for and then
they'll tell you what's missing. And again and again .... For web
applications it's not unusual to be given a 'design' of what it should
look like (image only, no mark-up) and a contradictory list of
commingled business rules, requirements. features and functionality.

In other words, professionalism that fails to rise above rank amateur.

My amateur designs are far more complete and robust than professional
ones, but they are not commercial. They would take too long the first
time (but they always could have been done in the time it had actually
taken to get to shipping).

We always do throw-away proof of concepts to test and better
understand both design and functionality. Essentially the project gets
written twice. Producing a proper deliverable is much easier if you've
done 'it' before. Too many people consider the investment in any code
as being too valuable to be discarded. That's just plain wrong. A
maintainable and extensible design is of the utmost importance.

Tracy Kidder's "Soul of a New Machine" proved how little so-called
professional effort is needed to do a professional job right. I work
with a lot of inventors/entrepreneurs whose idea-to-shipping time is
measured in the single digits of weeks.

Much depends upon the complexity of the problem, management's
understanding of possible solutions, and the skillsets, abilities &
dedication of the individuals involved. In DG's case a knowledgeable
project manager was working with a team of not just any recent
engineering graduates. Most of these were hired specifically for the
project. For all the successes in some respects the project can be
considered a failure.

Very seldom does a business owner or project manager ask "what's the
best way to ..." because in their mind they already have determined
what the only solution is. IT should be treated as vested peers rather
than day laborers.