The Quality Gap: Why Being On-Time Isn’t Enough

In which Jill advocates behavior changes, starting at the top. But not for you. No, you’re fine. Just for other people.

The biggest problem in business today is that everything is date-driven and not quality-driven.

There, I’ve said it. And a few dozen of my past and current clients are now sidling up to their laptops to shoot me an e-mail asking me if this blog is about them. (The answer is Yes It Is And You Know Who You Are.) Seriously, this is a problem everywhere, yet despite the wholesale crises it precipitates it’s actually getting worse.The root cause of this problem is the old bugaboo of perception. “Progress” is usually measured by speed-of-delivery, not fitness-for-purpose or conformance to requirements or streamlined processes or any of those other quality maxims. We’ve all heard a variation of the following:

“Just [complete the work] so I can get it into my status report for this [week/month/year].”

So that project manager’s boss is now satisfied that the team is getting things done instead of abusing flex time or work-from-home policies. Meantime the campaign went to a saturated segment. Product prices no longer match across divisions. Account managers are confused about territory assignments and are cannibalizing sales. And the Feds have just left a message for your CFO.

You have to name it to claim it. (I learned this from watching The Biggest Loser the other night.) So herewith, the five main reasons for this phenomenon:

1: The measurement conversation isn’t baked into project initiation. In our BI, MDM, and data governance projects we make sure that this is part of the requirements phase. But practitioners aren’t the only people who need to have this conversation. Business executives and managers should be proactive about their quality criteria during ideation or (at the latest) in the business case. This not only elucidates delivery steps, it makes scoping so much easier.

2: The “effort delusion”, that anachronistic WASP-y assumption that many people working hard will yield positive results. There’s a monkeys-on-an-island analogy here that I’ll refrain from making. But as many before me have aptly observed working hard simply isn’t enough.

3: No one closes the loop. Imagine how many companies have invested in quality programs, data quality automation, business analysis skills, TQM and SixSigma training and other improvements yet continue to fail to reconcile the project’s original objectives from its delivered outcome. Instead, projects endure scope creep or are delivered as a shadow of their original vision. Closing the loop between original vision and ultimate deliverable is a learned and practiced behavior. Instead, mediocre projects drive a flurry of fix-and-maintain activities that would have been unnecessary had they been delivered right the first time, and ultimately far more costly.

4: Failure to define realistic delivery increments. This is Project Management 101. Or is it? The problem here is that the people doing the scoping are often not those on the hook to deliver the goods. I’ve seen project managers idling in the doorways asking programmers to rattle off their tasks, then randomly assigning time-to-completion. It doesn’t work that way. Or it shouldn’t.

5: The economic climate has made people paranoid. There, I’ve said it. And a few dozen of my past and current clients…oh, nevermind. You’ve seen it yourself. People go into delivery hyperdrive and start producing at all costs. (“Just load the data into the database—we’ll worry about whether it’s usable later.”) Worse, they cover their collective asses while spinning stories of their productivity, backing into post-facto project plans and pointing fingers when people ask questions.

Maybe if we understand the root causes, we can fix the problem. (Thanks for that one too, Bob and Jillian!)  Or maybe we’ll just stay on the couch and keep chomping away, occasionally groping for the remote control so we can get something different just by pressing a button.

Comments

[Jim Harris]

“It's astounding, time is fleeting
Madness takes its toll
...
It's just a jump to the left
And then a step to the right
Put your hands on your hips
You bring your knees in tight
...
Let's do the Time Warp again!
...
With a bit of a mind flip
You're there in the time slip
And nothing can ever be the same
Let's do the Time Warp again!
...
Time meant nothing, never would again
Let's do the Time Warp again!”

OK – so the fact that the song “The Time Warp” from the cult movie classic “The Rocky Horror Picture Show” was the first thing that popped into my head is probably more indicative of the strange way that my mind works, but Dammit Janet (er, I mean Jill) – you are definitely on to something significant here.

I have witnessed so many projects start off well. But then the complexity of the project begins working against your best intentions. It is so easy to get pulled into the mechanics of documenting the business requirements and functional specifications and then charging ahead on the common mantra:

“We planned the work, now we work the plan.”

Once the project achieves some momentum, it can take on a life of its own and the focus becomes more and more about making progress against the tasks in the project plan, and less and less on the project's actual goals – whatever those were – just make the date!

Therefore, I completely agree with you.

Instead of requesting that timeliness “Rose Tint My World”, let’s all say “Don’t Dream It, Be It”, and take control of this “Wild And Untamed Thing” we call effective (and not just efficient) project management.

Gotta go now – the movie just started on my DVD player . . .

[Phil Simon]

Awesome post, Jill.

Allow me to vent...

4: Failure to define realistic delivery increments. This is Project Management 101. Or is it? The problem here is that the people doing the scoping are often not those on the hook to deliver the goods. I’ve seen project managers idling in the doorways asking programmers to rattle off their tasks, then randomly assigning time-to-completion. It doesn’t work that way. Or it shouldn’t.

Preach it, sister. This irritates me to no end. I'm not saying that everyone needs to be in the room when every decision is made, but how the hell do PMs routinely make design and delivery decisions without the faintest idea about what they are promising? The answer is in your next point.

5: The economic climate has made people paranoid. There, I’ve said it. And a few dozen of my past and current clients…oh, nevermind. You’ve seen it yourself. People go into delivery hyperdrive and start producing at all costs. (“Just load the data into the database—we’ll worry about whether it’s usable later.”) Worse, they cover their collective asses while spinning stories of their productivity, backing into post-facto project plans and pointing fingers when people ask questions.

It's very shortsighted for people to do a "package slam" and then attempt to clean up data later. Yet, this seems to be happening far too often because of the economic realities that you describe.

To me, this is penny wise and pound foolish. Long-term pain is sacrificed for short-term "gain", although I use that term very loosely.

I'm glad that I'm not the only one outraged at these practices.

[Jill Wanless]

Right on!
#1 Quality Criteria - I just spent half of my morning stating the exact same thing (ranting, if you want to be precise) in an email conversation with someone in the IT architecture sphere. They have a direct impact on all project solution approaches and I did get them to finally agree but sheesh..it took half my morning. Typical day in the life of moi! What a waste of $$.
#3 Scope Creep - just once I would love to see our benefits realization results include the costs associated to the re-active data quality related activities we need to do because we failed to do #1.
#4 I see this as directly tied to #1 and #3. If it's not about quality, it's about delivery, and whatever collaboration, iteration, huddle processes you have end up being one giant project status.
Thank you and please forgive me as I email the url for this post to those that are tired of hearing this from me directly.

[James Standen]

Oh. Bad flashbacks to endless project progress meetings. Must sit down.

Great post.

[William Sharp]

Like those that have commented before me, I too have seen PMs sabotage the quality of a deliverable for the sake of its timeliness.
However I think we, as developers, need to stand up and do two things to avoid this from happening. The first thing is to learn to provide better estimates for the delivery of our deliverables, as you stated in point #4. And the second thing is learn to stand firm on missing a date which would be re-enforced well if we actually had people do what you state in point #1. In fact the success of projects ultimately relies on the fact that someone does what you stated in points #1 & #4.
We (the software industry as a collective) are a bit like weathermen. As long as we deliver a forecast, we feel like we should be allowed to get back on air the next day and give another one!

[Jennifer Banzon]

I don't think this is only an issue about PMs. I know these scenarios all too well because key stakeholders were pushing the dates over the data. Unrealistic expectations are also a factor. I know many a non-technical manager that does not understand that changing a system is not a silver bullet for solving data and process problems.

[Phil Simon]

Jennifer -

I think that we've worked with the same people!

Phil

[Kevin Davis]

We have a saying at work - "we're a victim of an on time delivery"

:)