Mistake of the week

The planned post I had for this week has changed. This week I’m sharing one of my mistakes. 

Everyone makes mistakes on their journey, myself included. I’ll share the big one with you in the hopes that you learn something from my errors.

For those of you who have read my book, you know I’m focused on the concept of Business (or Organizational) Value. If you start a project, job, program where you’re going to spend time and money, and haven’t mapped it back to Business Value, then you’ve started down the wrong path. You may achieve value, but that will be accidental.

There are two paths to Business Value:

• You can develop a (new or improved) product or service that allows your external* customer to do something of value to them that they were unable to do before
• You can reduce the internal cost of delivering a product or service to a customer with no loss of value to them

* We’ll come back to who your external customers are and why there is no such thing as an internal customer in another post (those who have my book already know the answer).

In order to get to Business Value as shown above, especially with technical projects, you need to approach them from a business centric standpoint.

This is something I push for day in and day out. It’s something I believe in. I try to make sure everyone understands the rationale behind the process – from clients to business partners to team members. I get it.

I still got it wrong. There’s a good chance you’ll get it wrong from time to time as well. 

Here’s what happened to me…

When we work on big Business Critical Application projects, it’s common for us to be brought as subcontractors to big-name organizations. There are not a lot of people who do what we do, so we often act as the technical experts for a lot of the big players in IT manufacturing and IT consulting.

We were brought on to a project to build a small, well defined piece of technology (First trap: defined by whom?) that formed part of a bigger program led by the firm that brought us into the account. Time was tight, and as we went deeper into the design, it got a whole lot worse (Second trap: no time to go back).

Here’s what it looked like:

As we moved the project forward, it became clear that things were not well defined, the constraints weren’t well understood, least of all by the client, and we would have been better off starting from the beginning despite what everyone around the table initially felt.

Fortunately, we had enough business information to recover and get things back on the right track. This was not our first (or second, or tenth) rodeo, but we lost time and money because we didn’t follow the fundamentals.

There are two take aways from this week:

• Follow the process from Business Value to Solution Design in order
• When you find yourself off track because you didn’t, stop. Don’t keep digging.

If you're interested in digging in further on your own, you can get a copy of the book From Technical to Exceptional: Transform to Outperform and Make your Mark on Amazon.

For those who want to go deeper, you can sign up for the Technical to Exceptional Online course. (Don't forget to grab your 15% discount code!)