Thanks to Jeff Mlakar for hosting this month’s T-SQL Tuesday, a monthly collection of blog posts by data bloggers who work and live in the Microsoft SQL Server space.

This month’s topic is about projects that have gone wrong.

“Why Do Good Projects Go Bad, Andy?”

Deltas.

That’s all. Deltas. Allow me to explain.

In life, engineering, and projects, we experience deltas in a variety of forms.

IRL…

As a manager I learned there’s a difference between how we are perceived and how we think we are perceived. I label this the “self-awareness delta.”

In Engineering…

In engineering terms, delta is the letter of the Greek alphabet used to represent a difference or change or gap.

In Projects…

Projects that will eventually fail go astray early on in ways that are either invisible or ignored. Projects disappoint or fail. I’ve seen (and believe) statistics that 85% of business intelligence projects fail or disappoint. Disappointment or failure begins as some delta – some difference – between what is real and what is perceived as real.

Detecting Deltas

Think about how we discover there’s a delta in our self-awareness… it requires, well, self-awareness! It turns out that detecting deltas requires meta thinking. The risk of being too meta? We can succumb to circular logic. Thinking meta involves some circular – or, at least, circumspect – reasoning.

Our perspective is also limited by our perspective. A wise man once said it’s difficult to remove the speck from our brother’s eye while we have a plank in our own eye. (Note: Andy’s Plank Removal Service Offering currently has but a single customer…)

So how can we achieve delta detection?

I regularly reference Kathryn Schulz’s TED talk on Being Wrong. Kathryn begins her (excellent) TED talk by stating that we do not know what it feels like be wrong. But she concludes her introduction by contradicting herself (which is totally appropriate… think about it…) and states that we do know what it feels like to be wrong; it feels like we’re right.

Ownership

I’ve seen projects fail. Heck, I’ve seen companies fail. I’ve made mistakes and when I’ve caught them, things have sometimes improved. Sometimes I catch them too late to effect a complete or partial remedy. It’s rare, but it happens.

The first step on the path to (project) health is to admit we have a problem:

“We have a problem.”

Another step is communication. I prefer over-communication.

Over-Communication

I’ve never once had a client say to me, “Andy, you are communicating too much about this project.”

Not. Once.

I’ve had projects go sideways because I failed to communicate effectively or enough. Here’s one thing I’ve learned about communication in projects:

If I communicate enough, I will communicate effectively.

Failure, By Degrees

Projects that fail first go sideways. Were we to graph the trajectory of a project failing, we would not see a 90° turn at the point where the project goes sideways. Instead we would see a gradual departure – a curving away – from the path to success. The departure would reach 90° and then – if not corrected – continue to 180°. At this point the project is irrecoverable. A project may become irrecoverable at 90°, even. It depends on the project.

Fix It!

I can hear you thinking, “How does one fix it, Andy?” I’m glad you asked.

If you catch the departures at 1° – or even 9° – it takes much less effort and time to address and correct the departure.

This sounds simple and it is, but it’s also difficult. Remember that meta thinking is required, and meta thinking is hard. Simple, yes; difficult to implement and accomplish.

DfG

I address “Deviation from Good” (DfG) by over-communication. It’s the drum I beat throughout any project I lead. How do I implement DfG?

TPS Status Reports

I loathe bureaucracy. Especially bureaucracy for bureaucracy’s sake. I learned the reason I loathe status reports is I am not naturally good at tracking status. I struggle to remember details of what I did all week at the end of a week. Being an engineer, I engineered a solution:

A few years ago, my friend (and hero) Donald Farmer (Treehive Strategy | @DonaldTreeHive | LinkedIn) shared this Notepad hack with me. If you start a Notepad file with the text “.LOG” followed by a carriage-return / line feed (hit the Enter key), Notepad can provide a log template. Save the file with “.LOG” on the first line. Each time you open the file in Notepad a new line will be added containing the current date and time. Try it. It’s cool.

I use the following format to log project time:

I use this to track my time. I’ve even built an SSIS package that reads this file and stores the data in a database. I’m able to generate status reports from this data very efficiently.

My former boss and mentor, Bennett McEwan (LinkedIn), challenged me when I reported to him at Unisys 10+ years ago. When I complained that my status report was taking an hour or more each week Ben said, “Your status report should only take you five minutes.” My kneejerk reaction was not positive. But then I engaged to solve the problem, remembered Donald’s Notepad hack, and the rest is history.

Come To Jesus Meetings

I’ve been wanting to use “Come to Jesus Meetings” in a heading for a long time. It’s not a perfect fit here but I must confess I’ve become tired of waiting. So I shoe-horned it in right here.

I visit (if possible) or call the sponsor for each project on which Enterprise Data & Analytics is actively engaged and ask questions similar to:

• What questions do you have for me?
• How can I better serve you?

These conversations identify expectation deltas at 1° – or 9° – deviation… a place where almost any issue can be efficiently addressed within the confines of the current work effort.

These conversations keep a project on track.

Are these conversations pleasant?
Not always.
But they are extremely valuable.

Failure is normal.
Failing fast is almost always a good thing.

I’ve learned over-communicating is vital to mitigating project disappointment or failures.