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.