« May 2007 | Main | July 2007 »
June 21, 2007
Ken Orr on Malcolm Gladwell's "Blink"
I've often written about Malcolm Gladwell's work in my articles and in this blog, since so much of what he says also pertains to life in information technology. When I saw how my friend Ken Orr weighed in on Gladwell's book "Blink", I just had to excerpt it here. Ken's always incredibly insightful. If you want to get more of what he has to say on a regular basis, sign up for a trial of the Cutter Trends Advisory at www.cutter.com. You'll be "glad" you did.
Passing the Sniff Test
by Ken Orr, Fellow, Cutter Business Technology Council
I recently read the book Blink by Malcolm Gladwell. I had read pieces of his earlier book, The Tipping Point , and I also heard him on C-SPAN talking about his new book. Blink is about the instantaneous knowledge that we used to refer to as "intuition." In his book, Gladwell takes advantage of modern research into human intelligence. He begins with an interesting case. The incident has to do with a supposedly ancient Greek statute on which the Getty Museum performed extensive scientific due diligence and then purchased for US $10 million. Following the purchase, the museum invited a number of period experts to examine its new acquisition. One after another, the experts questioned the authenticity of the statue. The museum, though shaken, drew comfort in its detailed scientific study. But in the end, the experts were right and the scientists were wrong.
Gladwell's book has many other examples in which our unconscious (subconscious) minds make judgments about complex inputs much, much faster than our conscious minds. While this knowledge often leads to problems, Gladwell points out that we need to understand what the unconscious mind is trying to tell us and try to use it better.
I was thinking of Blink as I was recently talking to a client who had been involved in a project review of a very large project by a series of outside experts. The group was made up of about 20 experts in nearly every area of software analysis, development, and management. At the end of the first day, the group had nearly unanimous agreement that the project was in trouble. The group also listed its reasons for its conclusion.
The review process wandered about, as did the project. A couple years later, the project was finally canceled. During that recent conversation with the person who had been at the first meeting, this comment jumped out at me: "I wrote down the observations of the review group at the end of their first day," he said. "I went back when the project failed and dug up my notes from that meeting. Those observations were spot on! How come our internal controls didn't tell us the same thing?"
I mentioned this to another person who had been on the expert panel; his answer was blunt: "It was the sniff test!" he said. "When you've been the business as long as the members of that team had been, you know immediately when things are not going right. The signs that things were off track were everywhere and the signs that they were going to make it were nowhere to be seen."
I knew exactly what he meant. Large system failures tend to look alike. They typically make all their immediate deliverable dates with flying colors and then slowly start showing signs of stress. Then, the project starts missing serious due dates and top management starts looking for outside opinion.
I realized as I was reading Blink that I rely on my instantaneous knowledge when I'm doing systems reviews; unfortunately, I'm rarely wrong. I'm so convinced that this is not a unique talent that I think I would not want to employ a project manager or chief architect for a large project who didn't have the right nose.
Posted by Mike at 02:22 PM | Comments (0)
June 09, 2007
Formula 1 Racing in Montreal
Montreal has the nicest people in the world. Maybe it’s because springtime has shaken off the winter blues for all of us northerners. I’m here collaborating with my good friend Tim Lister for a client. They have a huge project with a tight deadline, and the risks are high. We’ve got a strategy to help.
Meanwhile – lucky me – it’s great to be here for work, but along the way I discovered that it’s also the weekend of the Canadian Grand Prix. All the world’s top Formula 1 race car teams have descended on this lovely cosmopolitan city – their cars will be screaming around the course, battling it out in front of thousands of international spectators lining the Circuit Gilles-Villeneuve. There were Honda Formula 1 adornments all over the streets, Ferraris parked curbside, young women wearing midriff-baring race team outfits, rock and roll bands, and everyone was speaking French into their cellphones, or English with French accents. How cool is that?
After a long work day (I awoke earlier that day at 3:30 am to make my 6:30 am flight), I decided to unwind for dinner in a cozy seat at the Sakura sushi bar on Rue de la Montagne, a short stroll from my hotel. I was exhausted, but I quickly forgot about my fatigue with the first bite. The food was superb, and the atmosphere inside was as though I’d stepped into a Star Trek transporter and beamed myself to Tokyo. The staff was speaking Japanese and the women were in traditional dress. A large group of about 25 young Japanese settled into two tables near me. I knew I was in the right place – the locals had descended in droves.
(I recalled a time when I once traveled to Tokyo to give a speech, and with my Asian descent, I was frequently mistaken for being Japanese in the shops and restaurants. People would start speaking in the native tongue, and I’d simply shrug my shoulders and say “English please…” To this day I remember their puzzled looks on why this “Japanese” couldn’t speak the language. That didn’t happen today though.)
After getting really happy on otoro, unagi, and hamachi, I paid my tab and strolled back into the chic streets of Montreal. Two streets down from Sakura was a big outdoor festival dedicated to the F1 race. A rock band was jamming on concert-worthy portable stage at the head of the street. Young and old were dancing. (One singer was an up and coming Canadian named Pascale Picard. She was like a young Natalie Merchant – amazing!) I looked to my left and the Budweiser race team girls (wearing tight midriff-baring outfits) were posing with people for pictures. Outdoor cafes were brimming with folks laughing and smiling.
Later on I text-messaged a family member that I had a brief moment, where I wished I were Canadian. (Cingular Wireless cell roaming rates were a buck a minute!) She asked why. I replied that Montreal was “very European and hip, but also Asian/multicultural, the people were incredibly friendly, the place was prosperous, streets were clean, and there were far fewer politicians flouting fundamentalist religiosity for votes, quoting their deity, and making war upon the world. She laughed with that “LOL” thing. All around me were people from just about every ethnic background you could conjure. French was being spoken everywhere. I wished that my multi-ethnic Asian/Irish/Greek English and French-speaking children were with me. They’d love Montreal; I promised myself to bring them here someday.
Back to Formula 1 racing.
I actually was driven (pun intended) to write this blog entry in part, because of an article I caught earlier in the Globe and Mail newspaper entitled “The Race for a Real Time Edge.” Did you know that an F1 team records and analyzes 8 gigabytes of data after each race, collected by 120 sensors placed in an F1 car? The Williams AT&T Toyota car for example, has a team of engineers following the race in real-time along with a dozen people in the pits. Streams of data on oil pressure, air pressure, engine temperature, and chassis stability are analyzed. They make instant decisions on when to pit-stop, how much fuel they should take to optimize power-to-weight, and countless other decisions to help them win a race.
By contrast, many IT organizations today have at least one big tech/software project spiraling out of control. Team sizes typically range from 12 engineers and business analysts to one project with (gasp) 350 people; all racing against the deadline. Some teams are in one physical location, but more often than not, many teams are split across vast distances, often experiencing extreme communication difficulties. There’s lots of overtime, as well as many missed birthday parties and kids' soccer games, and way too much travel.
My point is that few have anything close to “sensors on the race car” to obtain readings on the performance of their team, and the project. Many say they’re too busy to spend time on project measurements. Most are not making their deadlines. The smallest cost overrun is about $3 million. The largest looks like it will be about $100 million. Some (about 1/3rd, based on project cancellation statistics) will not finish the race.
Setting up an “instrument gauge” using automated software measurement methods can involve as little as a few thousand dollars for a given project. I often ask teams if they track even the minimal, basic, project measures like elapsed time, staffing/effort, amount of software built, and the defect counts (only 4 sensors vs. 120). Most only collect two. They keep records on time and effort, but not on the amount of functionality they'd built, or the number of defects found during testing, or after the system us deployed. Many IT teams I’m talking about here get stuck inside the debate on using progress measures and whether they need them, as their projects crash and burn.
After 20 years in this business, I sometimes wonder if we’re living in a strange movie. Thank goodness for things like sushi, race cars, street festivals, and rock and roll bands.
Posted by Mike at 12:12 PM | Comments (0)
June 04, 2007
Five Questions About the Flat World
http://www.projectsatwork.com/content/articles/236756.cfm
The world may be flattening, but it’s also clustering, as I described in this interview that I gave for projectsatwork.com. In this, I make the case for the “energy synchronization” of co-located project teams, describe why creativity and outsourcing are difficult bedfellows, why adding staff often exacerbates problems on high-pressure projects, and how offshore, in-house and agile-led projects fare on defect rates. You can read the full text at the projectsatwork website, but I've also included the questions and answer section here. Enjoy!
==========================
Five Questions - Agile Methods and Outsourcing in a Flat World
Is the world really as “flat” as proponents of Thomas Friedman would have us believe?
Yes and no. It’s true that globalization has enabled all kinds of work to become decentralized and spread across the globe, with workers being split geographically across 2 or more continents.
But on the other hand, people around the world are “clustering” together more than ever before. Fifty percent of the world now lives in urban areas. There are “megacities” like Seoul, New York, Mumbai, Shanghai, and others that boast 20 million or more people.
There’s a reason for this, according to people like the Nobel-prize winning economist Robert Lucas and George Mason University professor Richard Florida. It has to do with the powerful productivity gains that come from the “energy synchronization” that occurs when teams of people are co-located. You can feel this yourself when you’re with an enthusiastic person, working together on a new idea. Creativity flows, your excitement feeds off of one another, often both in and outside of work, and it’s more fun.
So the world is flat, but it’s also “spiky,” with clusters of people around the world getting larger and larger as rural populations migrate to urban areas. It’s actually creating a crisis in the countryside in places like rural China.
In the world of technology, this is coming down to two forces at play – the continued outsourcing and offshoring of technology work, but with increasing competition from people arguing the case for work being done in-house, using methods like Agile software development. The former argues to split people up, and the latter aims to bring them closer together. My work involves measuring and managing the outcomes of both approaches.
What are the primary forces that are driving outsourcing?
One primary force: the lowering of costs by using cheaper labor. We’re seeing more “forced outsourcing” when it’s dictated by the executives like the CFO and not the head of engineering or product development. It seems less about accessing skilled talent overseas and more about cutting costs. There’s plenty of talented people right here in the USA and North America, but if they can't be hired at third-world wages, they're sometimes out.
However, recent studies reveal that actual cost savings might be shrinking, and that it’s smaller than we thought in the first place. A survey by the Cutter Consortium of about 100 organizations showed that a typical IT organization was outsourcing about one-fourth of its work. On that one-fourth, they’re labor costs are about 20 percent less on average. So the net savings is 20 percent of the “one-fourth slice,” which comes out to five percent. That’s not a lot at the end of the day.
And unfortunately, we’re seeing that it’s hard to coordinate work across multiple continents and time-zones. Many projects slip their dates, and experience higher defect rates in spite of good intentions. That drives up costs. Teams often find it difficult it is to communicate with one another “through a wire,” and it sometimes drives the outcome of the project.
Isn’t there credence to the idea of a “software factory?” I thought you could take IT work and “chunk it, routinize it, digitize it, automate it, and then offshore it?”
Yes, some routine cognitive tasks can be done this way. It appears much harder when expert thinking, creative problem solving, and complex communication is involved. Simple maintenance tasks fall into the former. Innovation and cutting-edge software development “inventions,” fall into the latter.
In the words of Rob Austin, professor at Harvard Business School, “The future belongs to those who can create new things.” That is innovation and it is creative and non-repetitive. (Things like YouTube, Skype, and even iTunes are basically “killer software apps.” Remember that term? They represented new things - incredible innovations that no one had heard of before, and they blew the top off of the box in their respective markets.)
In manufacturing, we know what to do and how to do it. We automate the process. If we want to double the output or halve the time, we add another assembly line or speed up the machines. That is a factory, and lower labor rates are relevant.
However, when it comes to things that require creative expert thinking and complex communication, this applies: To some extent we don’t know what to do or how to do it. We spend most of our time, not building the system, but figuring out what to build and how to build it, by talking to one another. And adding more staff can have negative rather than positive consequences, because of communication complexity.
The difficulty some companies are finding with outsourcing is that “talking to one another” piece. Compounding the problem is talking through a wire when you’re fresh and they’re tired because of vast distances and time-zones, or talking when you’re tired and they’re feeling fresh.
The idea of a software factory tries to force a cost-cutting Frederic Taylor manufacturing philosophy - into a creative economy, killer-app, innovation culture. It’s totally paradoxical, and while we don’t hear it used by name very much these days, in practice the idea is still out there in force.
In software, the idea of “finishing the requirements” and handing them over to low-cost factory coders in another country is extremely rare, if nonexistent. In truth, during the design and build phase, the requirements constantly churn, often requiring lots of complex communication and feedback loops. Agile methods by design are intended to meet this challenge head-on.
What is industry productivity data showing on projects that are offshored, versus those that use Agile methods?
We have statistics on several thousand IT projects right up to the present. We’ve seen productivity and quality patterns on in-house projects, offshore outsourced projects, and now, patterns on agile projects are emerging.
We are seeing similar productivity numbers. But not surprisingly, the defect patterns are different. When offshore projects experience that “talking to one another” problem I referred to earlier, the bug rates are higher. Sometimes 2x to 3x higher. When agile projects successfully execute a co-located team strategy, the defects rates are 20 to 50 percent lower.
Is it possible to successfully outsource to an offshore vendor who uses Agile methods?
That’s a real tough one to answer. Let’s think about it. By definition, an agile method like Extreme Programming (XP) means “co-located teams.” Offshoring, by definition means splitting teams, often across 2 or more continents and multiple time zones. If someone can make those two definitions co-exist simultaneously, it would be a remarkable accomplishment.
I’m not sure that it can follow the “Reese’s Peanut Butter Cup” recipe – you’ve got chocolate in my peanut butter, or peanut butter in my chocolate. Software engineering might be more complicated than taking two different flavors and mixing them up.
But we don’t have to worry about the answer – people are bound to try it, and if they do, we can measure it. A few companies that I’m working with are attempting it. Stay tuned, the results are bound to be intriguing.
Michael Mah
Posted by Mike at 09:13 PM | Comments (0)