Complexity’s Rising Tide
December 1, 2005
Recently, I had the privilege of being a guest keynote speaker at symposiums for two of the world’s largest financial services companies, where I spoke about the people dynamics and success/failure trends of deadline-intensive projects – something near and dear to all our hearts. Between the two events (one held in Chicago and the other in Boston), there were about 700 technology professionals in the audiences. It was an exciting time.
Something struck me that both organizations had in common, which was touched upon in the opening remarks by senior executives who introduced me to their audiences. The paramount challenge before them — more often than not — stemmed from being a global company with geographically dispersed teams, dealing with the rising complexity of technology projects, while under higher pressure of ever-tighter deadlines.
This macro-challenge is one for the ages. It is especially daunting in today’s Information Age, because being a company that only uses technology as a peripheral aspect of its core business is an outdated paradigm. As a banking executive once told me, “We’re not a financial services company where we simply use IT. Today, more than ever, we’re discovering that we must be a TECHNOLOGY company that happens to be in the financial services business.”
With that shift in thinking, companies need to reconsider how they can win the game, within the context of solving the riddle of building harder stuff in less time. If you accept that you are now a technology company, then you might also imagine that whoever innovates the best under these circumstances, wins.
Clearly, those who *do not win* are the ones that fail to grasp the essence of this dilemma. Like it or not, everyone is in this box. When I give a conference talk, I often ask the audience whether what they design today is more complex or simpler than what they did five years ago. I also ask how many are given the deadline first, and whether they have more time or less time for their projects than they had five years ago. In all cases, the answers are: more complex, less time.
And yet, every time I read another project failure statistic about the percentage of projects that miss their date, deliver less than promised, or overrun by 100% or 200% or more, I realize that most of the IT world continues to be stumped by this riddle. Some leap onto the offshore bandwagon, thinking that smart and less expensive Indian programmers will know the answer. Others once swore never to write a line of new code again, figuring that buying software packages would differentiate them in the marketplace (huh?), and still others decided to turn over all their IT to an outside supplier and let them worry about it. (You might also reconsider where the “blame” may lie for projects that are deemed “failures.”)
A few – the Harry Potters of the IT world – realized the essence of the riddle. You might wonder whether the answer is contained in these paragraphs — and you might be partially right. Here are a few snippets that took me a while to uncover, after visiting a lot of places over the last decade or so and sifting through plenty of projects at clients who graciously invited me to do so (you don’t want to know how many).
■ IT projects are about blending the minds of a team. In this model, it’s possible that 1+1+1+1 doesn’t equal 4. It might be six or eight if you get the blending right, and discover how to make real magic happen.
■ Blending these minds is vital – especially since the things you’re innovating today are harder than the things you tried to innovate yesterday. (It’s called knowledge work for a reason.) Mind-blending is very communication intensive.
■ It is a lot harder to blend minds that live, eat, and sleep on different continents.
■ Harder projects don’t like to be time-compressed. They get angry when you try.
■ Adding people to compress time dramatically increases defects.
■ Because of this, you have to think about promising less, but getting it RIGHT and talking a lot with your clients about their needs and interests, every step of the way.
■ If you are in the technology field, chances are you are a compulsive multitasking, overpromising people-pleaser. Accept this and start healing.
■ If you discover a recovery path from this affliction, you will resist your inherent tendency to overcommit. Less can indeed be more.
■ If you don’t believe this, then attempting to cram 10 pounds of knowledge-work into a five-pound bag can actually lower productivity with energy-sapping rework and mind-numbing overtime, while driving defects skyward (by the square of the team size). Ironically, this will mean that your projects will actually take longer and cost more — the very opposite of what you were desperately trying to achieve.
■ Those who figure out the above, and understand how to execute in light of these truths, will eat you for lunch and deliver successful projects, while yours get canceled from missing dates, overrunning budgets, while slashing functionality anyway at the 11th hour.