Crossing the Street

During a recent presentation to our senior management team I was reminded of the power of stories. The topic was IT Strategy and our internal Digital Divide among our national societies. A recent study had determined about 40% of countries in the RCRC Movement were without adequate IT to fully participate as members of the Federation or within their countries. This required new ways of thinking if we were to address this problem in the near-term.

The story I told was about crossing a busy street in Cairo. When we think about strategy, a natural tendency is to think about being in front, ahead of the pack, encouraging others to follow. A friend who teaches part-time at a prestigious law school says you need to keep two steps ahead of the students, no more and no less. And it's this memory of the teachers and coaches in our life that sets our early benchmark for leading. But it may not be the image that serves us best.

Last summer I traveled to Cairo to be a judge in the Imagine Cup student competition. While we were there, we made plans to meet with a colleague who offered to show us his home country, the "real" Egypt he said. Farouk was one of our long-term Field Office Regional Tech's. He reported up through my US headquarters IT group.

As is the custom of his country, Farouk extended a hospitality that is rare in my part of the world. He took us on a tour of the old city in Cairo, we visited the Egyptian Museum, and we traveled to Alexandria. He made all the arrangements and would take no more than our thanks in return. It was humbling.

The traffic in Cairo is, by western standards, insane. There are few traffic lights in the city, and no one pays any attention to them. The painted lines on the street and highways are at best guidelines; if four cars can fit in three lanes, they do. One evening in Cairo we parked near the edge of the old city and walked to dinner. At the first main street, we experienced the drivers of Egypt, up close and personal. How were we ever going to cross this street? My New York instincts were to look for a gap in the traffic, and run for it. But there were no gaps.

Though I was the boss, Farouk took charge. "Hold my hand," he said, "follow my lead, and don't look!" It was a strange experience, a throw-back to early childhood, grabbing Dad's hand before crossing the street; depending on him to get us safely across. "Go now," he said, taking five steps forward and stopping, then five more. Cars were swerving around us like a river around some rocks. "Hold on," he admonished, "do what I say; now go." In a dance I did not understand, he guided us across the sea of chaos, to the other side.

When we caught our breath, and heart rates slowed down, I asked him how he got us across. In New York, we would have been killed. But these were Cairo rules. "When you step out," he said, "the drivers must take responsibility not to hit you." "...but you need to know when to step out," he added.

This story was a lesson I'll never forget, precisely because I needed to forget. I had to put aside my experience and preconceived notions of how to cross a busy street, and trust someone else to guide me through their country's rules. Letting others lead you and teach you is part of becoming a good leader. It is especially true of learning about other cultures--we will never get it as well as those who have it in their blood. This also applies to our areas of expertise. Sometimes we need to let others teach us.

Applying this story to our Digital Divide program, I encouraged our team to think about taking our lead from our national society countries. Some of them have already figured out how to solve the IT gap. We need to learn from them, harvesting the best ideas and taking these to scale. Letting others take the lead means learning to be a good follower

This is why a technology catalog is at the heart of our program. As we discover applications, services and deals that are working, we will add them to an on-line catalog from which our country leaders can choose. That's turning upside down the typical IT approach that wants to assess and build. It means taking someone elses hand, an openness to learn, and amplifying it for others to benefit.



"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."

Colliders, Postcards and BHAGs

Yesterday I joined a group of CIOs on a field trip to CERN.  Our mission was to see the world famous Large Hadron Collider that loops 27 kilometers through Switzerland and France.  We were also here to learn about the technology that runs it.  It was a trip through scientific imagination.  The facts and figures were incomprehensible.  Here are a few:

• 27 kilometers with 9,600 super-cooled magnets
• 120 tons of liquid helium coolant
• Particles travel at 99.99999% the speed of light
• 40 billion particle-packets pass a given point every second
• A pixel detector camera takes 40 million images per second
• A half-Yotta byte (10^24) of data stored each year
• Over 60,000 parallel processors

For a group that is not easily out-tech'ed, we were impressed.

CERN's Data Center

The highlight of the trip was traveling to the far side of the Collider, and descending 100 meters underground to see the Compact Muon Solenoid (CMS), one of the largest experiment centers is located.

The CMS 30-foot end disk

Yet when all the magnificent magnitudes were said and done, what stood out for me was what one of the scientists said.  

We were standing in front of the CMS collider asking a dozen questions.  The scientist answered them all with patience and good humor.  "Why don't the particles travel 100% the speed of light?"  "The additional energy would be enormous; remember E=MC^2." "What about the vial of anti-matter?"  "Fiction!"

But when we turned to the question about the missing particle, the Higgs Boson, he got serious.  "We've had a theoretical model for over 30 years.  It's withstood mathematical scrutiny and every experiment run to date.  But it's missing one element.  With it, the model is proven; without it, we have to rethink the whole thing."

Thirty years!  And then the hopeful and confident statement: "We believe we will find it in the the next two years".  "That will tell us what the universe was like a nanosecond after the Big Bang."

"The anticipation must be palpable for everyone," I said.

"Yes, very!" he replied with a twinkle in his eyes; "We are very excited!"

The professors answer our questions

Later on the bus, I asked another professor about this audacious goal.  "It sounds like the Apollo team 40 years ago, racing to put a man on the moon by the end of the decade."  "Yes," he said, " "We all have that kind of shared vision, that shared goal."

It occurred to me just how powerful a singular, defining goal can be-- especially when it's shared in common by everyone in the organization.  Jim Collins called it a BHAG: a "Big Hairy, Audacious Goal."  The Heath brothers called it a "Destination Postcard."  When people buy into the vision, almost everything else pales in comparison.

I asked about how the Collider teams dealt with conflicts, and difference of opinions.  Two things: "we run an experiment; we build many small prototypes before taking it to a large experiment"; and "we appeal to the goal to move things forward; it's always there in the background, reminding us."

There's something else they do at CERN: they have two teams who are competing to find the missing particle.  They each have separate designers, engineers, approaches, and separate teams of scientists. One chose the acronym we learned above: CMS; the other chose the primordial Greek Titan with the world on his shoulders: Atlas.  Fitting.

 

"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."

The Next Ten Years

Looking out ten years is an eternity for technology.   The pace of change and innovation has not abated even in the face of a tough economy.  In fact agility and the ability to ride the waves of constant change is an imperative for CIOs in the nonprofit sector as it is in the corporate sector.  This requires a healthy dose of humility, recognizing that we will often get it wrong.  But that is not an excuse for maintaining the status quo.  As I've described elsewhere, those who stand still get hit by the train.  We must embrace change, we must learn from it, we must look forward to it.  Change is not an option; change is a must.

NetHope is an amazing experiment that has worked beyond my dreams.   This year we turn ten as the collaboration at the intersection of technology and humanitarian-conservation work.  It is a time for reflection, of learning, and of anticipation for what we hope. 

Looking Back

NetHope was founded on two compelling hypotheses: (1) that INGOs would be able to get communication technology out the last 100 kilometers to where it could do the most good better, faster and cheaper if we did it together rather than each of us reinventing the wheel; (2) we would be a better, more interesting partner to technology companies if we came as a group rather than continued with the one-off grant requests.   Both have proven true beyond all initial expectations.

NetHope has branched out from its remote connectivity platform roots in two strategic directions: I4D application platforms that primarily benefit citizens, and shared services that primarily benefit members (see the strategy chart, below). 

 Looking Ahead

Looking out the next ten years, I envision three themes dominating NetHope’s evolution.  Asking what success looks like for NetHope and its members, these themes would indicate the next levels of success.

One theme that is front and center is what I am calling the “Relevant IT” initiative. The three areas I see for Relevant IT are (a) mission-moving projects such as I4D, (b) “good enough” agile applications such as smaller, fit-for-purpose applications, and (c) “lights-out” infrastructure such as cloud computing and shared services.  In short, this is about using technology more to move our member’s missions forward.  I’d like to see NetHope lead the way in mission-moving technology and shared-technology services among nonprofits. I call this the "get into" and "get out of" objectives: for non profits to be effective for the next decade we need to shift the IT agenda to get out of “lights-on technology” and get into “impact technology.”

Second, we will be the organization that empowers others in emerging countries to gain the skills to support their own social-benefit technology.   This is at the heart of the NetHope’s charitable purpose, to share technology knowledge locally so that the emerging entrepreneurs can enjoy the productivity gains we have seen in established economies, and the poor can benefit the poor.   In the next decade, we must move from a provider of technology to an enabler of communities.  This is as much about education (like the NetHope Academy) as it is about hardware and software.  In some senses this will mean working ourselves out of some jobs: a noble and necessary goal of charitable organizations.  It also means looking to the emerging countries in which we work for the technology innovations that will change the way we work at home and abroad.

Third, we will lead in becoming a new economic model for a self-sustaining organization in our sector.  This means a shift from dependence on the generosity of our partners to more services that fuel our programs.  This will be a significant challenge in balancing member-serving activities with member-services that come at a cost, and potentially compete with vendors.  I believe there is much to learn from the 150-year history of cooperative organizations in agriculture, banking, and other sectors.  The collective model can be applied to technology, both for NGOs and for local small businesses in emerging countries.   I will be writing about this during my upcoming sabbatical at the Rockefeller Bellagio Center.  

There are many other goals for growth, sustainability and impact of the work we do.  These three themes may serve as guide-posts to where the changes-of-impact for which we embark over the next decade ensure that we reach a destination that all would conclude that we have again exceeded our expectations.

As I said ten years ago, I renew today: The secret of success is getting started.  Let's go!

"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."

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.

Ed

"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."

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 (UPS.com) on the for-profit side and OXFAM (oxfam.org) 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."

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.

1. EMBRACING CHANGE

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.

2. TAKING RISKS

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.

3. INNOVATION IS ABOUT HARVESTING

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.

4. INNOVATION IS ABOUT BEING STRATEGIC

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.

5. GOING TO THE FAR COUNTRY

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.

6. INNOVATION IS ABOUT COLLABORATING

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."

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: http://agilemanifesto.org/principles.html . 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.