Fail Yet Succeed?

  1. Posted on September 16, 2009 12:42:PM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, project management, humor, context, quality, requirements, Management

If you build EXACTLY what “they” tell you, you do it in the timeframe they ask for, and at the cost they wanted to pay, is that a successful project? The project is

  • On time
  • On budget
  • Delivers the requested functionality
  • No defects
  • The team is ready for the next project

Is it successful?

“Yes,” you say. Rightfully so.

But what if I tell you that the above project (project A) was followed by another project (project B) a short while later to change the project A functionality because… drum roll… it didn’t solve the real problem.

Is project A still a successful project?

“No,” you say. “They should have built the right thing, not just built it right.” Right again. The addition of project B makes the building of the right thing the combination of A & B and blows the budget, schedule, etc.

But what if I tell you that the team counseled, cautioned, cajoled, and complained that what was being built in project A was the wrong functionality during project A but “they” INSISTED that this is what they wanted.

Is project A a success again?

“Well, um, yes… but, um, no,” you say. Why the uncertainty? Shouldn’t a project that meets the project success criteria be a successful project regardless of what it produces?

It depends, I guess, a little bit on the angle you take to look at it. From a pure development team perspective, it is a success. From a business perspective, it is a failure.

A friend of mine last weekend was telling me about a new outsourcing move his company made recently. “One of the most frustrating things about our vendor,” he whined to me, “is that they do exactly what we tell them to do an nothing else.”

“Isn’t that what you want a vendor to do?” I asked in all innocence.

“No, I want them to build stuff that works,” he said in all seriousness.

My radical development buddies would tell me the fault of project A lies totally at the feet of the business since they said what they wanted.

My gung-ho business friends would accept some blame but put some blame back on the development team pointing out that the team should have known better and, by the way, the method of development should have stopped them from doing the wrong thing.

My consultant friends would opine that the development team has the responsibility to deliver to the “real” requirements—whatever those are. The issue here is that the only method most of my consultant friends have for getting requirements is asking the “they” what the requirements are. The “they” which INSISTED what was needed and were wrong.

My less helpful friends would say this is a hypothetical and 1) they don’t answer hypothetical questions (practicing to be nominated to the Supreme Court) and 2) even if they did, this wouldn’t happen in real life.

Right. Never happens in real life. Sure. This happens when we ask what “quality” means on a project. When we find that at the drop-dead date nobody drops dead and the project goes on releasing a bit later and still doing well. It happens when dev teams are forced into project constraints (time/resources/functionality) that has very little correspondence to the reality of the work to be done. We find it when the business can only talk in terms of solutions, not problems.

So thinking in black & white for a moment (the world is a lot more gray but it muddles the critical questions), can you be a successful project and yet fail for the business? I think not only is this a possibility but it happens more often than we like. More likely is that we have un-successful projects yet deliver something that helps the business.

So which is better

  • Successful project, failed business
  • Failed project, successful business

Of course we would all like the successful project and successful business. Construx has identified the 10x principles that make that happen. But since that seems kind of rare, which of the above do we choose? Do your methods help you get there?

Given those choices, for me I sacrifice the project. And once I make that black & white choice, then working on software projects becomes a lot less stressful and the muddled gray not so muddled. I can fail yet succeed.

kg2v said:

September 17, 2009 6:24:AM

It's even MORE complex than that!  Not exactly "only" software, but I worked for a company 20+ years ago that made a LOT of money based upon "We built what they asked for" for a LARGE client

Picture the job is "Built this system (including software/firmware) to THIS Spec (100+ pages of spec + acceptance criteria) for a fixed price" (OH, BTW, they only got copies , not the RIGHTS to the design)

My boss at that time was fairly good at looking at the specs, and saying "Ah, this is what they Spec'd, but THIS is probably the hidden 'gotcha' that won't make it work in real life"

We'd bid on the job to make a small amount of $$ on building to the spec - while all the time planning on 'how to deliver what they really want'

Deliver the product, and pass all the tests, get paid, and when they would go to use the product, they would find out it didn't work the way they wanted.  They would come running back and say "HELP, it doesn't do what we REALLY wanted" - Guess where the company's REAL profit was made?  Rolling out the fix we already knew they were going to need!

Unethical?  Maybe, but not as much as you think, for two reasons - if you gave them what they ACTUALLY wanted, you could NOT pass the original spec, and no matter what, you HAD to pass that spec, and two, EVERYONE bid on the Spec, and the client pretty much ONLY took in to account 1)If you could do the work (aka actually had a company to do it) and 2) PRICE - yep, low bidder gets the job

As far as I know, the client STILL makes this mistake, and YOU pay the bill - It's the Federal Government.

They'd come to us and say "we need a hardware and software system that does EXACTLY this, bid on delivering 300 of them"  Lots of companies would bid (say) $5000 per item to deliver to the spec (where what they really needed would cost say $6000).  We'd bid $4900, get the job, and deliver (making a fairly low profit/breaking even), and 6 months later, they come back asn say "we need this change, how much to make it), we could nicely say "$1300" and make an extra $200 (if you tried too hard, they would just cancel the whole thing)

Twitter Trackbacks for Fail Yet Su said:

September 17, 2009 9:53:PM

Pingback from  Twitter Trackbacks for                 Fail Yet Succeed? - Practicing Earl         []        on

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl