Wednesday, 12 April 2017

You’re Not Going to Need It

Neal Conan: “You had solar panels (on your sailboat) for electricity.”
Matt Rutherford: “I did, but they broke.”
Neal: “They broke?”
Matt: “One by one.”
Neal: “I think you had a Kindle for reading books.”
Matt: “I did. It broke in a storm.”

I like Matt’s story for all that it tells as about our expectations and presumed requirements for a huge project we’ve never done before.

When I started out professionally the teams I worked on created deliverables; mockups, storyboards, sitemaps, taxonomy listings, content maps, wireframes, process flows, clickable prototypes, specification documents, usability testing, amazing looking proposals, Photoshop, timesheets. When I struck out on my own I assumed all of these things were required, so I packed them all with me.

Project after project I saw how each of these tools could bring as much confusion, delay, and tedious re-work as they could clarity. I saw how easy it was to iterate, debate, and perfect them, while losing sight of the project’s purpose and its promised business value. One by one, I stopped promising any specific design planning deliverable – other than a wireframe and a functioning web app. Then I dropped the wireframes. I eliminated all of this design planning documentation in favor of engaged conversations directly with the buyer that culminated in pen-on-paper sketches of how the key functionality should work followed by an estimate on when it’d be available to click-through.

Everything else? So much jetsam.

It’s not that I stopped doing the thinking encapsulated in those deliverables, the thinking became hyper-focused, hyper-prioritized on the core function of the project. If the core function couldn’t actually work nothing else will save it, not the color palette, not the logo, or which order the navigation labels are in. Hell, not even the project management methodology choice will save a project where the unique value proposition is neither.

The tools we actually need to be successful on a regular basis are so basic as to be taken for granted:
– trust in & respect for each other’s abilities
– clear, efficient, constructive communication
– absolute clarity in goals
– complete flexibility in execution
– a comfort with continual iteration

In this day and age, the rest can learned, negotiated, or rolled into the project as needed – whether it’s a project management philosophy, a unique software application, or a greater understanding of the subject matter. Presuming the four tools listed above are present, prior experience in the expected deliverables, vocabulary, or value chain of a specific domain is not only unnecessary but actually be counter-productive. Counter-productive to delivering the compelling innovation the creative team was assembled for.

Throughout its history, Apple – regularly cited as one of the most innovative and creative organizations – regularly dropped components presumed required for all computers; 3.25″ floppy drives, ethernet ports, optical drives, the ability to run arbitrary code.

At the time Google started getting becoming popular, having ads and headlines and other ‘portlets’ surrounding the search box was a presumed requirement for search engines.

Uber, Lyft, AirBnB dropped the presumed requirement that drivers/hosts needed to be licensed by the government.

Telsa, recently surpassed GM in market value, doesn’t have dealerships – a presumed requirement for an automotive brand by many states.

Yes, every one of these organizations is controversial for any number of reasons – but the very first one, the one deep down in their DNA is their bold dismissal of a presumed requirement around their core product.

So, yes I was disheartened when a Director at major employer confessed to me, “We don’t kill projects here.” For it meant a significant part of the organization was not yet boldly willing to separate the presumed requirements from the actual requirements far enough to spot the energizing, clarifying, innovation hidden in-between.

One of your presumed requirements is keeping you from growth. Do you know which one?

Red Flags? What Red Flags?

This was going to be a crappy project. The red flags were there from the very beginning.

The first: when my my buyer said, as I was about to sign the contract, “Today is my last day.”

I should have set the pen down right there, replied with a ‘Thank you for letting me know’ as I walked out the door. But I didn’t. I shook it off as a quirk. A minor curiosity. A small hiccup between me and their payment for my services. Definitely not a loud and flashing DANGER sign. Definitely not the high-point of the engagement.

With each day that followed, delays on the client’s end chewed away at my estimates and our agreed upon timeline until my side of the project heavily overlapped my family’s summer vacation. It’s my penance I told myself. My penance for committing to this project, for not firmly renegotiating when the timelines slipped, then slipped agin. A painful price for saying ‘Yes’ to something I shouldn’t have. So I, buckled down and resentfully, dutifully, worked through my vacation. A day or two from the completion the client called to say, “We had to bring in someone else to finish up.”

Oh, I was completely pissed. Pissed I wasn’t able, with all the odds against me, to make this project successful. Pissed I didn’t walk out on that first day. Pissed I didn’t say GTFO first.

Mostly though, I was relieved. Relieved I was now off the hook. Relieved I could now wash my hands of the project, the client, and their entire industry, with a long swim in the Wisconsin River.

Like an addict in a slow recovery, I began measuring time in the days. Days since I was kicked off that project.

This wasn’t the only project shouldn’t have worked on over the past 20 years. I could easily rattle off three more over a flight of Belgian beers. There’s probably a dozen mild and wholly forgotten failures. Even more that weren’t bad, but simply crowded-out better-fitting projects.

I’m sure you’ve had some painfully bad projects as well.

There were any number of points across all of these projects where someone needed to stop the line – and no one did.

Over the past few weeks, I’ve had a number of conversations around the client/vendor relationship. I’ve heard stories of six month projects being stretched out to a year – with the outcome barely distinguishable from the starting point. I’ve heard stories of software developers (inadvertently?) sabotaging a client’s project. I’ve heard of clients stiffing their vendors for no other reason than agreeing to a larger fee than they could pay within the project’s timeframe.

Sure, I’ve also heard stories of vendors flying executives cross country the very first hiccup of an implementation and stories of that elusive project that turned out better than anyone imagined.

Knit through all these conversations, there’s an unfortunate thread;

  • The absolutely best case scenario, is everyone doing what was expected when it was expected.
  • This is rare.

It doesn’t matter which project management process is followed; some bastardization of Agile, a traditional waterfall, something Scrum-like, or a more structured EOS. Too often both the client and the vendor have incentives and biases encouraging an unwavering march to an disappointing end, rather than a constructive, successful partnership. This doesn’t need to be the case.

There are many places to look for improved alignment:

  • Clearer articulation of the client’s business goals, measures of success, and business value of the project.
  • A better cultural fit between the client and the vendor.
  • Clearer tying of the vendor’s solution to those goals and returns.
  • Improved communication throughout the project.
  • Someone (everyone?) on the team feeling comfortable stopping the project at the slightest hint of things going sideways.
  • Fee structures encouraging maximizing business value rather than delays, low quality work, & maximizing hours.
  • A culture focused on success of the project, not which teams the players are on.

In the real estate world, there are Buyer Agents, advocating and representing the buyer’s interests, gathering their requirements, researching an array of options to select from, in ensuring every step of the process is successful for the buyer.

In the B2B technology world there is no equivalent, similarly well-understood role. The account manager usually isn’t involved in an ongoing basis, the project manager usually doesn’t have enough gravitas, and the remaining team members are usually so stretched they don’t notice if one project drags a little – let alone that it achieves the desired business goals. Neither side has an incentive to clearly and honestly communicate delays, unforeseen challenges, and mistakes to the other side. There’s no one with the incentive to keep both the buyer and the seller accountable for their sides of the partnership successful.

No wonder technology success stories are few and far between.

I want this to change.

This kind of work has been an underlying thread of my consulting and advising for the past five years;

  • from helping a multi-million dollar foundation select and implement a CRM,
  • to helping a non-profit selecting a vendor for a massive custom software development effort – leading to their successful multi-year partnership.
  • to introducing clients to vendors based on cultural fit.
  • to working with clients to start capturing the perceived business value sooner than they anticipated.
  • and leading the hard conversation on stopping the project when the pre-cursors of success weren’t evident.