Fail Yet Succeed?
- Posted on September 16, 2009 12:42:PM by Earl Beede to Practicing Earl
- 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.