Projects and Cots

I attended a kick-off meeting today for a large project at Save the Children (SC.) We are upgrading our donor management system (DMS, for short) and were hosting a senior project team from a major nonprofit software provider. (I'm judiciously avoiding names in this Blog so the focus is on the content rather than the organization, or individual.) We made a major step in this direction with our Capital Campaign project that was launched in August 2006. It was a significant improvement, but still relied on our legacy DMS as the database of record.

We've learned over the long haul that legacy systems become an anchor that gains weight over time; eventually they hold you back while competitors using commercial off-the-shelf (COTS) software zoom ahead. It is difficult to accelerate when you are carrying lots of baggage. There is no way I've seen yet for a nonprofit--with a modest technology budget--to keep pace with a software vendor. It's not our core business, and it is the vendor's.

There are a number of reasons why COTS is so important. I’d like to emphasize one: that COTS applications represent the best practices across a variety of customers. These vendor-authored applications that have been sold to many customers and enhanced over the years represent an accumulation of best practices across that client base. That implicit knowledge base is greater than the knowledge base of any one customer.

One of the things I like to say at the start of SC project meetings is: “the application needs a seat at the table.” What do I mean by that? Software project models tend to first identify client needs and then design or purchase software that meets those needs. That’s common sense. But there’s a flaw in this approach. It assumes that client needs are best practice, when in fact they may be worst practice. From where will come the challenge to rethink our business practices and therefore redefine our needs? The mature software application may have some things to teach us.

In our meeting with our DMS vendor today, I was reminded of the opportunities of COTS software. After all, one of our strategic plan planks at SC says that we need to be increasingly adaptable. My point here is that vendors, especially larger ones, have the resources to keep pace. Nonprofit IT staffs do not and should not. (The latter is a topic for another day.) Being able to change and enhance software quickly is one side of adaptability. Shorter projects are another. A telling question we've asked of larger projects is: if it takes three to four years to complete, how will it impact a five year strategy? Answer: it won't.

With these thoughts in mind, I've challenged the DMS team to comply with a number of design and implementation principles. I want to call out two here: (1) Identify project value points that can be realized sooner than later (i.e., deliver user value throughout the project rather than solely at the end), and (2) Identify the minimum product implementation with which we can go live and add components later. This may be counter intuitive when trying to maximize meeting user needs, but is essential to long-term success.

For further reading, I recommend comparing the open letter Convio posted last fall to NTEN members on the NTEN web site at http://nten.org/blog/2007/10/23/an-open-letter-to-the-nten-community

I think that’s enough for one day. I’ll come back to some of these issues again. A number of them apply to some of the research I’ll be doing at Tuck.