“All Projects Are Business Projects”

I read this somewhere recently – I think it was the CIO of Intel, Kim Stevenson (quoting IT folklore). But it stuck in my mind, long after the link that I harvested it from had evaporated. I like it since it gets to the heart of the discussion . . . what’s the business problem you are trying to solve. So often I find myself fielding queries where the people on the other end of the phone have decided on a technological solution (a hammer), and are now looking for a problem (the right nail).

The business doesn’t want a hammer or a nail; they want something of value – the house. It’s not important that your solution has this product or that techno buzzword. They don’t care for how cute your big data credentials are, or whether your mobile mojo has trumped your social ace in the hole. These sorts of trends – big data, mobile, social – are just like, well, like the context within which the house sits.

Of course, we need that application delivered to our customers on a digital device nearby to them. Of course, we want that engagement to leverage the history of what we’ve done with that customer in the past – their wants and preferences taken into account. Of course, we want to leverage what we know others in the same context considered the right choice. But we also expect the customer to channel-hop to the Web, and then perhaps wander into a branch or store, and ring up about it to see where things are at (WISMO – what is the status of my order).

The customer expects that you are going to maintain that context across all those channels. The customer doesn’t care for how you are organized by departments and product lines. The customer doesn’t give a damn about the fact that your system of record always does things like that. Customers tend to find the decisions taken long ago by programmers quite irrelevant. In the end, they vote with their feet and go elsewhere.

Let’s face it – technology is the easy part. The real challenge is how you bring the people with you . . . how you get them to imagine a different way of engaging customers. How do you get all the processes and people aligned to deliver consistently compelling experiences?

Point is that it’s much easier to reimagine the future than it is to reengineer the past.

In the end, just like all projects are business projects, all problems are people problems. People want to be engaged in co-creating the solution rather than having it imposed on them. If you do that right – the engagement part – then the technology component becomes easy. Instead of it being your change project, it’s their business development agenda. Instead of resistance to change, the challenge becomes one of channeling their enthusiasm.

In business architecture, it’s those soft skills – empathy, facilitation, and coaching – that are the keys to success. Helping managers see the world differently is critical – creating the alignment and engagement usually starts at the top. If you’re really good at it, then you could end up coaching the senior executive team.



"Let’s face it – technology is the easy part. The real challenge is how you bring the people with you… "

Couldn't agree more. Arguably, not only is the technology the easy part, it's relatively inconsequential. Or, at least, the technology doesn't need to be a major discussion-point of the most important part of software development, the "engineering" (or "journey-mapping" ) phase. The focus should always be on conceptualizing the simplest, most user-centric, and "problem-solviest" application, and then finding the right technology to enable that solution.

I'm with an open-source tech-agnostic custom software shop. So I come to this discussion of technology v. problems/people having participated in dozens of conversations with clients where step one is simply re-setting priorities and expectations. In most intro meetings, my team and I reiterate some variation of the following: "Yep, I hear you... but we're not building a native iOS mobile app, we're solving a problem for your sales-reps/customers/[insert demographic here]... so let's start there and focus on what they actually want..."

I admit that one of our biggest challenges is not necessarily working with a client to reorient expectations/priorities. Instead, it's getting them to buy-in on the process required to achieve that people-centric end goal; to spend significant time/money/energy on an "engineering" or "journey-mapping" phase as a precursor to actual software development. This discussion takes time, but once we're able to reinforce that value of that pre-development work -- this process prevents feature overload, saves development time, ensures your people will actually use this software, etc. -- we see the client's perspective, and their paradigm for understanding the value of software, begin to shift.

Enablers should be almost invisible

Agree with your perspectives. A few quotes come to my mind:

"People don't want to buy a quarter-inch drill. They want a quarter-inch hole!" - Management guru Ted Leavitt

“At 60 miles an hour the loudest noise in this new Rolls-Royce comes from the electric clock” - Ad doyen David Ogilvy.

Similarly, enabling technologies should focus on outcomes, not inputs.

There was a time when a VP in a consulting firm threatened to walk out if he can't use "AquaLogic". Ahem!