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