Making projects

Management by Wishful Thinking Is More Common than You'd (Wish to) Think

"Nothing is so easy as to deceive one's self. What we wish for, we readily believe." Demosthenes

Too many executives with control over system implementation projects practice MBWT (Management by Wishful Thinking), blundering into predictable box canyons, and incinerating budgets and energy that could have been spent wisely elsewhere.

The wishful thinkers share amazement at the steaming rubble of their costly failure, and then move on to the next project where they do it all over again, refusing to learn the basic lessons from their previous flub.

What is MBWT?

MBWT managers believe that if you sprinkle enough fairy dust and wish hard enough, you can make anything happen, regardless of available resources, appropriate team members and schedule realities.

But mostly what the MBWT manager overlooks is the hard work of managing and fine-tuning or overhauling details along the way.

Frequently in big organizations like multinational corporations and in governments, the outfit makes a plan that has been shaped by "political" considerations, not rigorous planning.

Then it holds a couple of rah-rah meetings, and the execs cross their fingers, hoping that their desire for success and the importance of the outcome will "make" the outcome happen they way they want it to.

You see MBWT behavior from IT executives who believe (or let system vendors convince them) they can deploy significant new systems without doing serious testing ("Oh, we'll just catch those mistakes early in the deployment"), or running the new system in parallel with the old system, or investing effort in change management.

Both testing and running systems in parallel (at least for a few months) are known requirements, like Newton's Laws.

And every once in a while, someone comes along and pretends their faith means the Laws don't really hold for them personally, until reality thumps them back into line.

Making projects

succeed">

All experienced IT project managers know that testing, gradual migrations and investment in change management are all mandatory if the project is going to "succeed."

They also know when they don't do it, the effort spent fixing things is no less than it would have been before (and just as often it requires more effort), and the failures cause the implementers to lose credibility with the users in a way that debilitates productivity in the present and erodes credibility for the future.

The Walgreens drug chain used to print one of those corporate mission statements on their register receipts: "Hi, I'm (cashier name). I'm here to serve you with the 'Seven Service Basics.'"

Yastrow apparently always asked the cashiers what they were and none of them ever knew any.

So, being a good marketer, he did the gadfly thing and pointed it out.

After enough of Yastrow's agitating, Walgreens simply removed the Basics from the receipt.

As Yastrow said, "I guess they finally decided it was easier to drop the program than to tell their employees about it."

Typical redefining the specs to accommodate incompetence.

It's also a great example of the MBWT that goes on around most mission statements.

A team crafts it, sends it out through the comm. channels, and then pretends that Lysenko-style, everyone will suddenly embody the executives' intentions.

Every time someone running a project tries to ameliorate a failed original estimate by pulling budgeted resources out of testing to pay for a development schedule more realistic than the one he pitched, he's engaged in MBWT.

As accomplished project manager Stephen Nelson says, if you allow several MBWT-based decisions to cascade (that is, you try to erase the toxic effects of one MBWT decision by making another with the same technique), the toxicity compounds like credit card debt, and eventually the management effort to remediate the waste (overhead) is greater than any effort left available to do something positive (work).

Ignorance is the mother

There's a different weakness that can look like MBWT, but is both more damaging when unrestrained and easier to ameliorate: brute ignorance.

This ignorance happens when people without formal IT training, usually from finance or computer science backgrounds, end up in control of big software projects.

The academic trendies who invented and proliferated the "real time" organization and the "more with less" cult, because they never actually ran an organization that produced anything tangible, just don't let real tendencies or experience get in the way of their ideologies.

Ignorance is not, in itself, a bad thing. The ignorant person can observe and see things the experienced take for granted.

The ignorant person is free to ask questions with a free pass.

But ignorance that's not seeking to learn for whatever reason is toxic. This was pandemic in the '90s and, ironically, even in the contraction, holds a lot of sway.

My favorite example was an entrepreneur, a really interesting English lit major who was using venture funding for his startup.

He was describing the super-fast development cycles he was holding his team to.

I asked him about testing, and he said (I love this), "Sometimes you just have to build the airplane while you're flying it."

Fatal thinking that is bald-faced obvious. This analogy doesn't "fly".

In real life, you can't fly an un-built airplane.

The analogy was as predestined to crash and burn as the business model he was trying to support.

The ignorant think they can get away with it because they don't know any better.

The MBWT types are the good soldiers, and are less likely to make waves, ergo more likely to stick around.

That means it's more likely over time that projects will display the results of this behavior.

The solution is to defend your specfor development and QA despite budget cuts and pressure from cost-sensitive integrators.

In addition, be prepared in advance for the wishful thinkers to do their thing, so you can negotiate a compromise, yielding on details you can live without to get assurance you'll get testing and quality control.

And never let anyone talk you out of running in parallel for at least a few months (and at least close out a month after a full fiscal quarter if the application has any finance features).

You have to manage the Brutishly Ignorant and the MBWT dingbats kindly but firmly because the consequences are expensive.

You can slap those plane-parts in place as fast as you want, but if you're counting on fairy dust to get you airborne and keep you up there, you're building your project's coffin, not the airplane.