Thursday, December 23, 2010

A Journey Through the Village

Thinking about the "One Village' where all of us can enter into the conversations, from all sides of the digital divide, it's still a distant vision.  At the turn of the year, we may be cognizant of the goal in the distance.  And we press on to reach it even when the climbing is steep and the steps are labored. Yet the view ahead and behind offer many surprises and satisfactions.  If we take the time to stop and see.

I was reminded of this during a recent trip to Taiwan.  Wulai Village is a famed stop for visitors, located in the mountains south of Taipei.  It is a twisty bus ride up the mountain from the last station on the red line train to Xindian.  Here on a crowded main street, the journey begins.

Past the shops and across the river, the climb begins on a gentle paved path, called the Lover's Walk.  It is an apt metaphor for the "honeymoon period" in a new job or project, when aspirations are high and the way is smooth.  But there are precipitous drops and large rocks along the way.

At what seems to be the end of the path, there are steps to climb and a gondola ride to the top.  A brief rest in the journey, waiting for the next leg.

Always gaining altitude, the air is crisper here.
And when what we thought was the summit, there are yet more stairs to climb!

Finally reaching our destination.

And a clear pond, teaming with life.

Looking back, we have come a long, long way.


And so the story: leg-after-leg of the journey, at times exhausting, but turning around, we see how far we've come.

So we who journey the strategic plans in pursuit of our lofty goals, are wise to stop and look back at the vistas.  We have come far; we have accomplished much! As the poet said, "gather ye rosebuds while ye may."

Merry Christmas and Happy Holidays to all.


"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."

Tuesday, November 16, 2010

Decision Yardsticks

Here is an article in a continuing series of "IT Think" papers I wrote for my IFRC audience, but which applies equally to many organizations.

* * * *

Developing a set of decision rules, I call "yardsticks," may help everyone in our organization make better decisions and assess the priority of each project and request in a way that a senior manager would.[1]  

The goal of developing an organization's yardsticks is to enable managers and staff at all levels to (a) make decisions about projects and activities with a more senior management mind-set, and (b) to constructively question all projects and activities to assess whether they are aligned with the organization’s key bets, or strategic goals.  When the goals and rules of the game clear, it is possible for teams to be empowered to accomplish objectives with a high sense of mission and ownership.

With a shared set of yardsticks we can assess each project and approve it, reject it, or send it back for additional work.  By using this process of rationalizing the project list and clarifying the yardsticks, front-line managers gain a clear picture of the project development process, and a greater sense of ownership.  

From high-level, I see some key principles to which we should aspire and on which our IT decisions should be based.  I have divided these into two sections, first are general business decision-making principles and second are those which are more specific to technology decisions.

General Business Yardsticks

  1. The Field (National Societies) is our #1 Customer.  We need to continually ask: How does this project benefit fieldworkers?  Our #2 customer is the Zones, and #3 is Geneva departments and workers.
  2. Think personal, extra-mile service in all that we do for our customers.
  3. Partner internally and externally (v1).  That which is routine and commodity should be handled by other experts.  We need to focus on the value-added functions.  This is not outsourcing; it's partnering.
  4. The digital divide is as much about learning skills as it is about making connections.  If we build it, they won't come unless they own it from the outset and understand it.  They is us.
  5. The brand is a key driving force.  For our web presence, our branding look-and-feel needs to be a shared driver for all sites.  A user who Googles "Red Cross" or "Red Crescent" should have a sense wherever they land that this is the same organization.  See how UPS ( on the for-profit side and OXFAM ( for the non-profit example, have handled this.  Customers don't understand federations.
  6. Partner internally and externally (v2).  We are one organization and partnering with each other will be critical to strengthening us and closing the digital divides.  This means having one email system and one shared directory (think rich, user maintained address book for finding people anywhere in the National Societies and Secretariat based on shared interests-- the most fundamental building block of knowledge management, and the key driver for our future email system: the directory is the driver. [Think Identity Management and Active Directory]) 
  7. Discover and harvest.  (See my Blog posting on "Discover and Harvest" for my thoughts on this.)  We need to look for best and better practices among the National Societies and take to scale and share that which we can.  Don't build what we can harvest!  This requires humility, openness and beginner’s mind.
  8. Stop-gap, ad hoc solutions are fine as long as they have an expiration date, and we replace it with something more principled and supportable for the longer-term.
  9. Decide questions of local versus central based on local capacity to build and run. We may need to stratify our National Society audience by capacity to develop, support and extend tech platforms like intranets, web sites and even email. Our answers may be different depending on local capacity.
  10. Don’t boil the ocean.  Solve the immediate problem and evolve to the ultimate one.  Pilot first, then scale.
  11. We are one Federation; our systems need to reflect, support and encourage this.
Technology Decision Yardsticks
  1. The Internet is our network.  We should be planning support and architecting solutions expecting connectivity and its reliability will continue to improve in the Field ("Don't bet against the network," and "play to where the puck is going to be." [think hockey])
  2. We need to work in a sometimes-connected world.  Somewhat in tension with the Internet is our network, but the interim reality.  Applications need to work as seamlessly as possible when offline and then online.  Outlook and Groove are examples of this architectural approach.  Interim solutions need to be reasonable throw-aways once strong Internet connections are available.
  3. We need to leverage out-of-the-box applications.  I'm a SharePoint advocate, but I'm wary of a growing base of custom applications built on SharePoint.  Think 3-5 years out with a growing base of these to support.  Most National Societies will not have the skills (or time) to build SharePoint app's.  We are not in the software business; our technology partners are.  A corollary is that applications need to start simply, and extend as needed.  We will likely need web sites in-a-box for the smaller National Society offices.
  4. Build for the Cloud. Get out of commodity operations and support businesses.  Let others run what they are best at and let us run where we add the greatest value.
  5. We support what we share, at a minimum supporting the local or regional IT/application supporter.
  6. The vendor always owns the code. Upgrades are the vendors problem. For custom code, that would be us; so we need to ensure the vendor owns the customization. [Also see Off-the-Shelf!]
  7. Small is beautiful.  Large applications and systems are harder to maintain, upgrade and enhance.  It’s easier to deliver, maintain and replace small systems 
  8. Fit-for-Purpose applications over large enterprise systems.   Related to small-is-beautiful, a more agile organization is build on systems that are quick and easy to change, and faster to deliver.  Those applications that meet a specific need are more likely to succeed.
  9. Don’t overestimate the need for connecting and integrating systems.  Sometimes a manual transfer of data is sufficient.  Often a simple export and import of data will do. One-way integration may be needed.  Two-way integration should be avoided.  The key questions are: how often does the data change, how much of the data changes, and how many users are impacted.  A small scope demands a small solution.
  10. Redundant data is not a problem.  Storage is cheap.  They key is being clear about who owns the data definition and maintains the originating database.

These principles are open to debate.  There are more yardsticks to consider, and they will evolve as we learn.  I believe truth arises from the dialog.  Without push-back and debate, we are likely to get it wrong. Together we will get it right.

[1]  I wrote a similar article on Yardsticks during my sabbatical at Tuck/Dartmouth here.

"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."

Friday, November 5, 2010

Six Views on Innovation

To kick-off NetHope’s 19th Summit at Santa Clara University, I talked about six views of innovation. It’s an appropriate topic as we met in Silicon Valley and had the honor of co-sponsoring the laureates for this year’s Tech Museum Awards. I am continually renewed by the innovations I see from students and social entrepreneurs who are applying technology to solve problems in the most challenged areas of the world. Hearing and seeing what each team has done is itself a creative surge for thinking about new ways, new approaches.

As I talk about each view of innovation, I will be wearing two hats: one as NetHope’s chairman and co-founder; and one as the Global CIO at IFRC. And I will be challenging you to shift your minds.


If we have learned anything over the past two years of recession, it is that change is hard. And yet change is all around us, especially in the nonprofit IT world. I believe if you connect the dots on the challenges NGO CIOs face, it is evident that we cannot follow in the footsteps of corporate IT changes during the past decade. We lack the funding and time to do it; and we need to work in places where even electricity is an option. I've written about these challenges in other places[1]. As projects get larger and maintenance costs grow on the one hand, IT budgets and staff are contracting on the other. We are on a collision course that requires new ways of thinking.

One of the mind-shifts that needs to happen is the data center mentality. We often take pride in our racks of servers and air-conditioned rooms. If we ask ourselves what would we create if we started with a clean slate, none of us would repeat what was built in the past. What does the NGO Data Center of the future look like? Lights-out! The datacenter for NGOs in the future should not exist. We need to get out of that business.

CIO’s need to do some soul-searching here and ask themselves if they want to be a part of the change or its victim. Ask yourself: “who will pull your chain? The market? Donors? Your boss… Or you?” The conclusion is obvious: change is not an option; change is a must.


Thomas Alva Edison is one of the American heroes of innovation. A recent cover story in Time magazine featured the familiar story of how the light bulb was created. It took hundreds of attempts of trial and error. As the authors note “It would take years of experimenting with platinum, paper and bamboo before Edison found his way to a durable filament, carbonized cardboard.”[2]

Before this breakthrough, he was asked why he hadn’t gotten any results. Edison famously said, ““Results? Why, man, I have gotten lots of results! If I find 10,000 ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is often a step forward...”

The point of Edison’s story is that failure is an important part of innovation. Fail fast, fail often is a hallmark of entrepreneurial companies. That means taking risks.

How can we take on the risks? I believe it was Bill Sharpe at Stanford who pointed out the relationship of risk and return when it comes to investments. Essentially the more risk you take on, the greater the return (when things are going up!)

One problem: at NGOs we are playing with donations not venture capital. How can we experiment and fail our way to success, when our stakeholders want and need our success. This requires a mind-shift about risks in IT.

To continue the investment metaphor, one of the ways to reduce the specific risk on any one bet is to diversify into a portfolio of many bets. This is why mutual funds work. What does a mutual fund have to do with NGOs or IT?

I believe we need a mutual fund of experiments. The NetHope I4D pilots can be seen as our innovation lab. We participate based on our membership; it’s not a variable cost and risk for us. What works, we can harvest. What doesn’t, we can ignore.


I've been a judge for the Microsoft Imagine Cup Competition for two of the past three years and have written about it in this Blog. The Imagine Cup can be seen as a funnel of taking a huge participation to a few winning ideas. In a recent year, the competition had 400,000 student applicants; 3,000 country competitors; 400 went to the finals 27 winners make the final cut in 9 categories.

The question this begs for us in and across our organizations is: How are you gathering the good ideas?

I've written about the “Discover and Harvest” approach and how we can apply it in our IT organizations (see my May 2010
Blog entry on the subject.) Discover and harvest is based on the work of Jerry Sternin, who I knew at Save the Children (for a longer discussion, see my Blog entry). What Jerry discovered was the value of discovering the positive exception, what he called “positive deviance.” He discovered and amplified what mothers did differently in a society where malnourished children were the norm.

Discover and harvest is the opposite of our traditional way of meeting IT needs. We usually take an “assess and build” approach: assess the situation, gather requirements, specify the project, build it, test it and deliver it. The problem with this approach is that it has a dismal history. A recent Standish Group report notes that only 32% of all IT projects succeed (delivered on time, on budget, with required features and functions). 44% were challenged (late, over budget, and/or with less than the required features and functions), and 24% failed outright (cancelled prior to completion or delivered and never used.)[3]

The discover and harvest approach is about finding those applications and uses of technology in the far reaches of your organization that are already working. This approach has a number of benefits:

  1. It’s already working somewhere; it leapfrogs over getting a new system to work. The pilot has already been run.
  2. Some group has already adopted it; it doesn't need to be sold.
  3. It's field-tested. Especially for international NGOs working in challenged rural settings, it works where technology is rare.

However, for discover and harvest to work, you need to believe in two things: (1) Headquarters Humility – that innovations will come from the far country; and (2) Good Enough Technology – that 80% solutions get the job done. This requires a change in our IT worldview.


I’ve talked about the IT Strategic Pyramid for nonprofits for a number of years. Our strategic imperative as CIOs is to move the IT agenda "up the pyramid" to applications that touch our beneficiaries (see below.) Our job is to get into the top (mission moving technology) and get out of the bottom (lights-on technology.)

An example of getting into the top is the IFRC SMS-Texting communications project in Haiti. The bottom line of this program: the beneficiary is at the center of communications

An example of getting out of the bottom of the pyramid is the IFRC BPOS/Office365 initiative, moving IFRC email to the Cloud. Why are we doing this? Consider this:

  1. We are not in the data center business
  2. We need to redeploy people, time and money up-the-pyramid
  3. We need to have impact on 60+ National Societies who have little to no IT
  4. We are a Microsoft-centric shop with many inter-application and platform dependencies
  5. We need a more fluid path from premises to off-premises computing
  6. Bottom line: We are about partnering with those whose business it is to do things that it is not our business to do

NetHope is moving in similar directions, branching out to I4D pilots to support development programs at the top of the pyramid, and sharing support services at the bottom of the pyramid. The common point is that we are both managing IT as a portfolio. We both have a related, diversified portfolio of projects and pilots that are focused on moving our mission forward.


Clay Christensen has done important research at Harvard on disruptive innovation[4]. I asked him at a roundtable discussion, "can you think of any cases where an organization was able to embrace disruptive innovation in headquarters?" His answer? No.

Tom Peter’s, another management guru, talked about the Law of Proximity: Innovation is directly proportional to the distance from headquarters. He pointed to the case of the IBM PC, whose design and success was due in no small part to fact that the development team was in Boca Raton, about 2,000 miles for IBM’s Armonk NY headquarters.

When thinking about innovation, a question we should ask ourselves is: what’s our far country? For NGO’s the answer is clear; it’s the Field. We should constantly be scanning the remote areas of our organizations for applications of technology that are working in ways that would surprise us.


Core to NetHope’s values is collaboration[5]. We believe we learn by collaborating and –to quote our paper on collaboration—"insights come by doing projects together. To accomplish this we partner with leaders from governments, donors, business and education.” “By dialoging and debating with the best minds from inside and outside our organizations, and challenging each other with ICT and other innovations, we can develop new ways of working that benefit those most in need[6].”

* * *

Six views of innovation: embracing change, taking risks, harvesting, being strategic, going to the far country and collaborating. Each requires a shift in our thinking from traditional to new ways of doing IT. If we are going to be relevant in our organizations and our sector, we need to challenge ourselves to change.[7]


[1] “The Good Enough Principle – What we can learn about technology from the pragmatic solutions of nonprofits,” an unpublished paper , Tuck/Dartmouth , June 15, 2008. Send me an email for a copy.

[2] Jill Jonnes, “
Let There Be Light,” Time Magazine, Wednesday, Jun. 23, 2010.

[3] See the Standish Group April 23, 2009
press release.

[4] Clayton M. Christensen , The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, Harvard, 1997

[5] The six NetHope Values and Guiding Principles are:

  1. Technology (ICT) Matters (NGO Missions depend on effective technology & capacity building);
  2. Benefiting all benefits one (Benefiting one also Benefits All);
  3. Learn through collaboration (Learn by doing);
  4. Build for the Field (IT solutions are deployed solutions);
  5. Bias for action (The need for speed, especially for emergencies);
  6. Trust above all else (Trust comes through open dialog and working together over time)

[6] NetHope Principles for Nonprofit Technology Collaboration (See my Relevant IT Manifesto).

[7] A copy of my slide deck for this year's NetHope summit is available on my web site.

"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."

Monday, November 1, 2010

Principles for Collaboration

This week marks the beginning of NetHope’s 10th year. It's hard to imagine that a small group of us met here in Silicon Valley in the fall of 2001 around the vision of together using technology to reach out the last 100 kilometers to the most challenging parts of the world in which we work. From that initial vision of a connected humanitarian village we have expanded to have 34 international members and ever greater impacts of applied technology to help move our missions forward. It would be an understatement to say we are the organization at the intersection of technology and humanitarian work.

From the beginning, the NetHope vision has been "to be a catalyst for collaboration in the International NGO community and enable the best use of technology for connecting in the developing parts of the world." These two "C's" of collaboration and connecting have been at the core of what we do. Initially this was about bringing connectivity to the places where our programs are delivered. It has grown to be ever-stronger partnerships where we are connecting people into the broader conversation of what technology can accomplish. Our partnerships have grown from the trust we have with each other to the wider circle of our corporate, foundation and government partners who we are proud to call colleagues in impact.

For each NetHope Summit I review our core values or principles, highlighting one that connects with the conference theme. I thought it may be interesting to pull these comments together into one document of principles that we reviewed during our Board meetings earlier this year. Here is the draft of that document, for which I invite your comments.

NetHope Principles for Nonprofit Technology Collaboration[1]

We are uncovering better ways of applying technology to solve problems of emergency relief, development and conservation by working together at home and in the field. Through this work we have come to value:

  • Working as one group more than as individual solo organizations;
  • Technology as a means of moving missions[2] and delivering program scale more than delivering support services;
  • Technology as core to connecting our communities, field workers and beneficiaries to the rest of the world more than simply an optional peripheral service;
  • Developing for those who deliver programs in the Field more than those who work in headquarters;
  • People and interactions more than processes and tools;
  • Piloting and testing locally more than adopting what works for headquarters.

While there is value in all of the items on the above continua, we value those on the left hand side more. We believe these emphases allow us to have the greatest impact on our members’ missions and, in turn, on individuals, wildlife and the environment where our members operate.

* * * * *

Guiding Principles behind NetHope’s IT Collaboration

We follow these principles:

  1. We believe that technology matters. Information and Communication Technologies (ICT) have impact on the work we do as international Non-Government Organizations (NGOs).Our effectiveness as NGOs depends on our ability to effectively use technology both to build capacity and provide new venues for the work that we do. Most importantly, we believe ICT can move missions, which is the most strategic application of ICT to which we can aspire.
  2. We believe benefiting all benefits one. Doing things together enhances what we do as individual organizations. And what we do individually can be shared for the good of all. We support what a small group of members can do as well as what we do for the larger group. Each is an opportunity to learn and benefit our individual missions, while sharing the risk.
  3. We believe we learn by collaborating. While technology can facilitate collaboration, we believe in face-to-face conversation for building relationships. Insights come through the dialog. It also comes by doing projects together. To accomplish this we partner with leaders from governments, donors, business and education. By dialoging and debating with the best minds from inside and outside our organizations, and challenging each other with ICT and other innovations, we can develop new ways of working that benefit those most in need.
  4. We believe in building for the Field. The field workers delivering our organizations’ programs are our primary clients. Our IT solutions must work in the most remote and challenging parts of the world. In this, field workers are our most important teachers and critics. We seek to deliver technology that improves program design, delivery and impact in the Field. Demonstrating measurable impact is the building block for what we do.
  5. We have a strong bias for action. This is especially so for emergency response work, where speed is paramount. It is also true for the pilots we run and prototypes solutions we build; we learn from the doing. Lessons learned help us become better prepared. We are therefore impatient to see early results and indications of what will work and what needs to be improved. And getting to what works is a primary measure of our progress.[3]
  6. We value Trust above all else. Trust comes through open dialog and working together over time. This means trust in working with each other as NGOs and with our corporate partners, funders and vendors. It also means we value each other’s expertise and have the humility to seek and accept approaches and solutions outside our individual organizations. We trust the small group as well as the larger group to get their work done.

[1]For a comparison document, from which lessons have been drawn, seen the Agile Manifesto, here: . A sample Agile principle worth pondering: “Simplicity--the art of maximizing the amount of work not done--is essential.”

[2]Each NGO has an impact-based mission statement, such as IFRC’s “to improve the lives of vulnerable people by mobilizing the power of humanity” and Oxfam’s “to fighting poverty and related injustice around the world.” IT leaders at NGOs must constantly ask how technology is helping to achieve this mission.

[3]Nonprofits refer to this as program pilots that are repeatable and scalable (for greater reach and across multiple countries.

Saturday, October 9, 2010

Launch Day

This week marked the end of my 100-day plan and the launch of our new IT Strategy. We started with an international food day[1], followed by announcing our new structure, and then a half-day of team building exercises offsite. It was a full and exciting week.

I'd like to take the next half-dozen or so Blog entries and talk about our strategy and how it has unfolded. I'll start with questions, and the importance of thinking through what you are trying to answer before you talk about your vision and what you are going to do. It was Rilke who taught me the value of learning to love the questions.[2]

Questions to Frame an IT Strategy

Strategy is about setting a destination and having a clear vision about what that destination looks like. One of the ways to frame a strategy is to think about the questions that we cannot answer today, or find difficult to answer, that our implemented strategy will make easier to answer. Here a dozen questions I've heard or thought about that in three years I envision IFRC using technology to answer[3]:

1. How can we double or triple our impact on the lives of vulnerable people in all regions of our work without doubling or tripling our staff or budget?

2. How can we deliver new programs in disaster relief, preparedness, and health for less cost and greater reach?

3. How can we remove steps and approvals from our business processes to speed the delivery and lower the costs of our internal and external services?

4. How can we report the impact of our programs more quickly, with better data, as well as more transparently to our stakeholders?

5. How can we reach people with the technology they have already adopted? (e.g., mobile phones)

6. How do we include the survivors of disaster as members of the team, participating in the assessment and delivery of relief services?

7. How can staff in all offices and other stakeholders readily find each other based on expertise and interests?

8. How can all our National Societies reach more of their donors for less cost to raise money? How can they leverage online fundraising applications and be able to raise funds via cell phones and the web?

9. In how many member-locations do we operate for each sector of program delivery and each area of fundraising? How many offices are there in the Federation? How many have improved their operations and use of technology?

10. How can National Societies afford current technology and learn how to use it? How can we level the playing field more for the “haves” and “have-nots” among our National Societies?

11. How can we collaborate more with other INGOs and other partners sharing basic commodity IT services like help desk and procurement?

12. How do we motivate the greater use of technology, with a converging set of standards to increase our ability to Move Forward Together?

These questions suggest technology goals that are achievable if we can imagine solutions together and commit to an exciting shared vision that inspires us to invest in new ways of working as a nonprofit.

Questions and Projects

Framing the questions is also a good way to start thinking about technology projects. As with strategy, challenge your business project sponsors to think about the questions that they cannot answer today, or find difficult to answer, that the application will make easier to answer. Coming up with the 10-20 questions to answer will help focus the project. It will also provide a more interesting and relevant acceptance test. If the new system can answer the questions, you’ve arrived.

Keep an open and inquisitive mind. It’s the most important thing we learn from our children.

[1] See my 2008 International Food Day entry for some thoughts on the importance of this event.
[2] Ranier Maria Rilke, Letters to a Young Poet.
[3] For a more complete list of questions, send me a note.

Friday, September 3, 2010


Now there’s a word to start a conversation. “Encrustment.” It naturally brings about a cringe, as if we forgot to wash our hand before a meal. However, in the world of shellfish, it’s a natural course of events, and it suggests a way to think about how simple things grow complex, and beg for renewal.

One definition of “shell” is a “hard outer covering secreted by an animal for protection.”[1] Imagine the layers that get built up on a shell over time, all with the good intention of protection. With some shellfish, this process happens again and again until the shell doesn’t fit anymore, and it must be shed and the process started anew.

Don't Legislate Exceptions

A story may illustrate how encrustment happens in our organizations. In his book, Growing a Business, Paul Hawken writes:

"Mrs. Green buys your widget and six months later returns it and wants her money back.

[1] New policy: 'All goods must be returned within thirty days of purchase.'

Mr. Jones brings back your widget and says he bought it twenty days ago; he wants a refund. But you know that the discounter up the street just had a close-out sale on the item, and you suspect that Jones might have bought the widget cheaply there and now wants a full refund from you.

[2] New policy: 'All items must be returned within thirty days and accompanied by the original receipt from this store.'

John Doe brings back one of your widgets and it looks as if it fell out of his car, or something equally serious. The widget is useless.

[3] New policy: 'Damaged items will be exchanged only within thirty days of purchase, only if accompanied by original receipt from this store, and only if defect is a manufacturer's defect.'

Mrs. White orders a widget and asks you to ship it to her home upstate. Three weeks later it's returned to you in unrecognizable shape. The customer wants her money back but the trucker says she signed for it in "good condition" and he won't accept an insurance claim.

[4] New policy: 'This merchandise left our store in first-class condition and shall not be returned for any reason without proper authorization. We definitely are not responsible for any damage whatsoever incurred at any time to any of our products while merchandise is in transit. Any merchandise returned to us will be refused. You must file a claim for damage, cost of repairs, shipping charges or replacement parts.'"

"This last new policy is not a joke. That statement accompanied $17,000 worth of file cabinets delivered to our offices. It was on a sticker glued to the front of every file cabinet."[2]

Hawken provides an amusing case for how simple things get encrusted with layers of policies until the whole organization gets weighed down and sinks to the bottom of the process sea.


This week I attended a workshop on business processes. As in the Hawken story, I’ve been thinking about how well-meaning organizations become so encrusted with processes on top of processes that they begin to ossify and lose their vitality. In my part of the world, we call this “bureaucracy.” I’ve been playing with a definition of bureaucracy that may point the way to how we can begin to shed the shells and revitalize the organism. I’ll offer two definitions:


  1. Any more than the minimum steps and approvals needed to accomplish something and not bankrupt the organization or foreclose on its the mission and values.
  2. Any process that no one can remember why it's needed and how it improves the mission and the lives of our customers

We would do well to put ourselves in our customers’ shoes and ask “how easy are we to do business with?” (If you don’t work with customers, you serve someone who does… and they just may be your “customer!”) If the process doesn’t make it easier, then it’s time to shed some shells.

Who do you serve?

At the workshop, I gave a brief presentation in which I told the story of the London bus drivers.

It seems the city was hearing a growing number of complaints about the bus service from the city riders. So like all good organizations, they hired consultants to study the problem. The wise team began riding the bus lines and immediately noticed a problem: the buses were passing by stops where would be riders were waiting patiently. When they gathered the bus drivers together at the end of a day they asked them why? The answer from one bold chap: “If we stopped at every bloody stop, we’d never make the schedule!”

This is an amusing response that begs an important question: who is your customer? Is it the schedule… or the rider? Substitute the word “process” for “schedule” and you can begin to see the problem. Processes are not the customer. And when the processes get so thick that we shut out all the light to the simple things that customers want to do, it’s time to shed the shells and start anew.

If you are clear about who your customer is, start asking yourself how you can help them get what they want done in a way them makes them smile. And for those who work mostly with internal customers, keep in mind another Hawken gem: “service in, service out.”

[1] The Free Dictionary, , accessed September, 2 2010.

[2] Paul Hawken, Growing a Business, Simon & Schuster; reprint edition (October 15, 1988), pp. 191-92, emphases and numbering added.

Monday, July 26, 2010

Next Chapter

The last two months have been a page turner. I am delighted that a new chapter has begun with the opportunity to have a growing impact at the intersection of humanitarian work and technology. I began a new job on June 15th as the Global CIO at the International Federation of the Red Cross and Red Crescent Societies (IFRC; see And I just completed a move to Geneva, arguably one of the humanitarian centers on the planet.

So what have I been doing? I'm at the half-way mark in my "first 100-days plan," a sprint of immersion that is also known "drinking from the fire hose." My 100-day plan has four parts, with a strong emphasis on "beginners mind," listening and learning as the newcomer:

  1. People: Meeting 1:1 with everyone on the IT team, both at headquarters and in the field. Hearing what's working well and what needs to change; what are people's vision for the team and themselves; and getting a handle on morale. I'm also getting a sense of "the bus," to use a Jim Collins metaphor: do we have the right people on the bus and are they in the right seats. I'm looking for strengths that everyone brings to the table and how we can build on those strengths. I'm also meeting 1:1 with senior managers and heads of departments, asking similar questions and hearing about their objectives and needs.
  2. Strategy: Thinking through the new ten-year strategy and asking how the IT strategy can be best aligned with it so that we move the mission and 2020 strategic goals forward. The 1:1 meetings with IFRC leaders in Geneva and the Zones (our name for regions) is a critical part of this thought process. Testing out "strawman" strategies is a good way to develop the thinking. I find that the truth comes out of the debate, so I want to provoke the conversations and see what resonates.
  3. Funding: Understanding the IT and IFRC business models. "Follow the money flow" is the objective. This includes the budgeting process. And each organization has it's own budget culture; learning this quickly is part of the orientation. This is taking a bit of parallel processing, as budget revisions for 2010-11 were needed before the strategy and assessment were done. There’s a bit of aligning needed here also: are our aspirations matched with our willingness to invest? For non-profits, as with most organizations, that’s a continual trade-off.
  4. Projects: Ensure that IT project portfolio is strategy driven. This entails a top-down review of all our technology projects as well as our existing base of systems and applications. The key question is which of these are contributing, or will contribute, to the new strategy. The analogy I've used is that we need to turn the Queen Mary around in the Rhone River. That’s a significant challenge, and we need to ensure that the engines keep running while we do so; otherwise we drift in the wrong direction. And we need to remember as we keep things running that the goal is to turn the ship around.

That’s the plan. Stay tuned for how the IT strategy develops. These are exciting times!

Tuesday, May 25, 2010

Discover and Harvest

I met Jerry Sternin at a conference at Save the Children five years ago. He was encouraging me to look into his work on “positive deviance[1].” My first thought was how could deviance be positive? Of course, he was referring the common bell-shaped curve and the 2% of the population on any given metric who lived out in the tail two or more standard deviations from the mean—statistical nirvana.

What Jerry found in his work in Vietnam, was the value of discovering the exceptions. When faced with rampant malnutrition and an impossible timeframe to have an impact, he was forced to look for families whose children were healthy and figure out what their mothers were doing differently. Simple variations in diet, adding rice-paddy shrimp and sweet-potato greens, resulted in healthier children. Having discovered these exceptions, he shone a spotlight on them, turning these mothers into evangelists and teachers. He reached 2.2M children over the first two years of the program.

Jerry discovered the power of what I call the “discover and harvest” approach to solving problems. Nothing could be further from the approach our organizations tend to take, especially in technology. The traditional approach is more an “assess and build” approach: assess the situation, gather requirements, specify the project, build it, test it and deliver it. The problem is that this approach has a dismal history. For example, 57% of ERP projects don't realize their ROI (Nucleus Research) and 66% IT projects fail (Standish Chaos DB). More often not, what we assess and build misses the mark.

Enter the “discover and harvest” approach. It’s all about finding those applications and uses of technology in the far reaches of your organization (and sometimes under your nose) that are already working. As Jerry would say “somewhere in your organization, groups of people are already doing things differently and better. To create lasting change, find these areas of positive deviance and fan the flames.[2] Imagine finding a really useful application being used in one of your rural field offices.

Why don’t we see more of this in our approach to technology? It requires headquarters humility. The best answers, especially if it involves change, need to be from the inside out. “Maybe the problem is that you can't import change from the outside in. Instead, you have to find small, successful but "deviant" practices that are already working in the organization and amplify them.[3] Perhaps the CIOs role is one of "Chief Amplifier." Find what’s working and can be taken to scale, and then shine the spotlight on it.

"Discover and harvest" has a number of benefits. First, it’s already working somewhere; it leapfrogs over getting a new system to work. The pilot has already been run. Second, some group has already adopted it; it doesn’t need to be sold. Third, it’s field-tested. Especially for international NGOs working in challenged rural settings, it works where technology is rare.

So how do we take a “discover and harvest” approach in our organizations? Run a contest for people to submit their applications and uses of technology. Then recognize and reward them (it doesn’t need to be a cash award.) Finally, put their name on the application. Most people take pride in what they do and want to be recognized for what they achieve.

Give it a shot. Let me know what you find.

[1] See the Fast Company article on Jerry’s work, “Positive Deviant,” by David Dorsey, November 30, 2000; here: . Compare the chapter on "Bright Spots" (easier-to-explain than positive deviance) in Chip and Dan Heath's, Switch: How to Change Things When Change is Hard, Broadway, 2010.

[2] Richard Tanner Pascale & Jerry Sternin, “Your Company’s Secret Change Agents,” Harvard Business Review, May, 2005.

[3] “Positive Deviant,” Fast Company.