Executive Coaching & Consulting

Smarter operations delivery

If you are a mid-level director or manager in the IT or software delivery space, then you’ve no doubt been surrounded by super-smart technical nerds and highly-paid project managers who just cannot seem to deliver projects on time, on budget, or with anything close to full scope. If you’re a Chief Operating Officer (COO), then you’re also Chief Project Manager, which means that, for all of these operational projects, the buck stops with you.

Delivery Smart Success Patterns

Patterns are “logical templates” used during execution of specific actions. The term was popularized by architect Christopher Alexander in his 1977 tome A Pattern Language, part of a three-volume series about sustainable, sensible building practices. The term was borrowed by the software community and incorporated into our descriptions of object-oriented programming. I borrow it again in this book to apply it to the practice of complex project delivery.

In this section, we’ll look at the various patterns used in Delivery Smart implementations, and recommend ways to incorporate them into your own projects.

Installation Patterns

In this section, you’ll learn about the Delivery Smart Success Patterns used at the outset of an engagement to ensure projects go smoothly, and to avoid major landmines that could otherwise blow up both the project results, and your client relationship, including future business.

The DS Installation Patterns we’ll cover are:

Discovering the Buyer’s true goals

Picking the right project

Identifying Stakeholders and their objectives

Securing Buyer support

Building a ‘Batphone’ to your Buyer

PATTERN: Deliver value to your customer, not to your PMO

In this section, there be dragons… read on at your own risk.

Enterprise software projects almost always start something like this:

BUYER: “Bob, the CFO wants to implement a new accounting system, the HAL9000 Account-o-Matic system from Odyssey Software. I need you to lead this project.”

What ensues then is the assembly of a list of “deliverables,” most of which have little or no value-add for the actual project, buyer, or customer(s), either internal or external. These include things like phase-gate review documents, arbitrary timelines, pre-defined budgetary breakdowns, and estimates (commonly referred to at every one of my clients as ‘SWAGs’ or silly wild-ass guesses).

There are lots of things wrong with this picture, but before we examine them, a brief detour:

How software consultants and staffing firms REALLY make money

Ever since I was 13 years old, I have delivered projects on a “flat fee” basis. This implies that I know my own production process, time, and costs so well that I can accurately value and sell a product (like the customized screen printed t-shirts and ad specialties my father and I made) or a service (like my logo creation and graphic design) at a fixed price, and still make a profit. When I started my first consulting business as a solo venture at age 28, I did the same: sold my communication and strategy consulting for a flat fee. The reason why I could do this and succeed was that these engagements had limited variables, and I knew how to mitigate all of them.

But delivering enterprise software is another matter. In his book Uncontrolled, author Jim Manzi, a software developer and business statistic geek himself, explains that some business and public policy problems have what he calls “high causal density.” High causal density means that are lots of possible reasons (causes) for a particular problem (outcome), some of which may be overlapping (happening simultaneously), so many, in fact, that even fancy statistical techniques like regression model analysis yield inaccurate or imprecise answers. In such cases, it is very difficult to compare apples to apples, or to arrive at the root cause of a specific issue or problem. And that is how most software consulting and software staffing firms make their money.

What do I mean by this?

Because these problems are so vexing and so specific to a given organization, it would seem that the only logical way to bill a client is on a time-and-materials basis. And if you are the consulting or staffing firm, that makes good sense: it puts 100% of the risk onto the customer. The longer the problem takes to solve, the more money the consultant makes; and by the way, at no financial jeopardy to themselves. But from the client’s viewpoint, it stinks, for precisely the same reasons! [Take heart; there is a better way, as I discuss at the end of this section.]

Only measure that matters

I told you all that to tell you this: there is no magic set of requirements specifications or software build methodology that can overcome high causal density (HCD). Neither a super-heavyweight, CCMI Level 5, PMI-certified set of marketing/functional/system/subsystem specifications, nor a super-lightweight, lean, scrum-certified set of verbal user stories can reliably predict all of the non-obvious interaction effects that will impact your software delivery. And keep in mind that each new interaction, whether an upstream system, changing business need, or a careless developer who writes sloppy code, can increase the number of interaction effects exponentially! Thus, it makes zero sense to base the success of your project on some seemingly objective set of requirements documents formulated before code development even got underway. The only measure of success that matters is your Buyer’s satisfaction. And yet, virtually no enterprise software project lead begins by asking the Buyer (whether internal or external) what their personal objectives are for the project, and how they would measure success. Instead, we take the title of the project and an overly-broad “vision statement,” then march right off to begin creating a requirements document, creating a Gantt chart, and any number of activities that together constitute prescription-before-diagnosis.

The best place to start

Whether your project is value-based, results-based, equity-based, or straight time and materials (T&M), the best place to start is with your Buyer’s definition of success. What are their personal objectives and goals for the engagement? Let’s revisit our opening conversation:

BUYER: “Bob, the CFO wants to implement a new accounting system, the HAL9000 Account-o-Matic system from Odyssey Software. I need you to lead this project.”

BOB: “Sure, Joan. I’m happy to help. What are your goals, as opposed to the CFO’s goals, for this project?”

BUYER: “Well, I’d like to see it delivered successfully within this fiscal year, of course.”

BOB: “Of course. What constitutes ‘success’ in this case?”

BUYER: “If we could get it live within 6 months in our unit, and roll out to the rest of the company within the year, that would be great.”

BOB: “What’s the benefit of the 6 months target?”

BUYER: “Honestly, after this reorganization we just had, it would help establish us at the go-to team for high-value programs. Also, we had to fight to get the CFO to do this project in-house instead of outsourcing it. If it fails, we’ll look really bad, and may lose future faith and funding for major internal initiatives like this. If it succeeds, we could save millions in vendor fees for future installations, and possibly generate some innovations from it that we can go to market with.”

BOB: “Terrific. OK, what else?”

BUYER: “I’d like to get the Business ‘shadow IT’ team working smoothly with our Production IT team, rather than maintaining two separate systems, and having me ‘referee’ between the teams.”

BOB: “Makes sense. Anything else that would make this project a ‘win’ for you, Joan?”

BUYER: “It always helps if we come in under budget, but not by more than 10% under.”

BOB: “Why 10%?”

BUYER: “Any more than that, and we have to give back the funding. Plus the Budget Office starts assuming that we’re padding all of our projects, so they start arbitrarily lopping off 10-15% from all of our project estimates! But if we are able to keep all of our funding, then the Budget wonks are fine if we share it among other programs. So 10% under helps us to look good and keep receiving funding, but also deliver under budget.”

BOB: “Understood- 5-10% under budget, if possible. Now, coming in under budget may require sacrificing some of the features, or some other trade-offs, Joan. Are you OK with that?”

BUYER: “It’s not my first choice, but as long as we deliver the most important features, I think everyone will be happy.”

BOB: “Alright, Joan. I’ll summarize what I heard here in a memo to you, and I’ll set up a regular checkpoint with you to show you how we’re doing against your goals.”

BUYER: “Perfect, Bob. Thanks.”

If you do nothing else, do this

In the above script, we defined the Buyer’s personal goals for the project, examined the value of each of those goals, both the the Buyer and to the company at large. We also plotted out what the Buyer’s metrics of success were for each of those goals. If you do nothing else that I recommend in this book, do this. You will cultivate and enjoy a much stronger, more trusting relationship with your Buyer, and much more project success by the only measure that matters: your Buyer’s satisfaction.

Got to be a better way

As mentioned above, there are better ways, both for you and your client, to charge for a project. After all, if you had a problem that was costing you millions of dollars per year, and I could give you the solution in (a) 6 minutes or (b) 6 months, which would you prefer? Option (a), naturally. If I told it would cost the same for either option (a) or (b), wouldn’t you still pick option (a)? Of course; any rational buyer would. If you are getting exactly the same benefit at exactly the same price, then option (a) gives you the addedbenefit of instant gratification, while option (b) makes you wait long enough that you may be out of a job, or that your company is out of business.

Now how much would you pay?

Clearly, option (a) is worth a lot more money than option (b). After all, when was the last time you paid a premium for slower service? Shockingly, many otherwise rational buyers choose option (b), and not just in software consulting scenarios. There is lots of research around this topic.

To help buyers see the wisdom and premium value of option (a), you have to frame the issue correctly. The topic of fee-setting and negotiation is beyond the scope of this book, but I discuss it elsewhere on my website.

To ensure your best chance of project success, know your client- whether you’re a third-party vendor, a project manager, mid-level director, or senior exec- understand where the value truly lies for your key stakeholders, and shape the project delivery according to their expectations, not some overblown technical specification far removed from reality. After all, people buy projects, and they are the ultimate arbiters of your success.

About the author

Curtis Guilbot helps improve leaders and organizations. His new book is Delivery Smart: How Fortune 500 companies get 10x gains from enterprise IT teams. Curtis marries creativity (he’s an accomplished actor and musician) with 20 years of demonstrated results for global Fortune 500 leaders and entrepreneurs. For free resources, tools, insights, and case studies, visit www.curtisguilbot.com.