Members Only Logo  
XML

or Subscribe by Email by entering your address below:


Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Sunday, May 20, 2007

Keeping the magic in technology consulting relationships

There are obviously some real benefits for a non-profit in building lasting partnerships with its technology vendors and assistance providers. But as in any long-term relationship, the are also special challenges that can emerge after a long association.

When an organization puts in a new enterprise software system, the process spurs excitement, collaboration, and communication. Users from all over the organization are sought out for their input, and leadership strives to win a high-level of buy-in from stakeholders of all sorts. The users are galvanized, attending requirements sessions, reviewing documents, participating in walk-thrus, and coming to training.

But fast-forward five years. Many of the staff who brought in the current vendors have moved on. To new staff members in leadership positions, the technology seems no longer a taste of the organization's future, but just what they found in place when they were hired. Upgrades and enhancements are made to the hardware and software without much fanfare, and without much end-user involvement.

And the excitement fades for the vendor too. The big new client everyone pulled together to win is now just another user with a support contract. As in a marriage, the technologist and the users have begun to take each other for granted. And this starts to take a toll on the solution itself. How can the old magic be put back into the relationship?

Here's what we've learned over the years:

1. Increase the opportunities for communication. Don't only hold discussions about specific requests or problems; sit down at least once a year -- developers and users - to evaluate the work done in the recent past and look down the road together at what is coming up in the near future.

2. Frequently re-assess requirements. Remember as staff has changed over the years, neither party any longer has the project history at its fingertips. Seven-year old user requests may be seen by today's staff as just the weird way their software works. Periodic discussions about specific domains - financial reporting, membership tracking, program management, etc - can make sure these processes are re-engineered before they lead to frustration.

3. Weed out needless complexity. Don't just focus on new requirements: Stay on the lookout for parts of the system that are no longer used. Software projects have a tendency to grow over the years, since user requests are almost invariably to add - almost never to remove - fuctionality. Pruning away functionality that is no longer required makes the entire system easier to use and friendlier to users. Remove needless fields from forms, tables from databases, columns from reports, and functions from menus.

4. Get physical. Webinar software and remote support tools have made it ever more easy to support technology from afar. But it's hard to maintain a relationship of such critical importance without sitting across the table from one another from time to time. Have a meeting. Go to a restaurant. Sit at the same workstation. You'll be surprised at the level of communication you've been doing without.
image originally uploaded as http://www.flickr.com/photos/bb_matt/306544780/

Labels: , ,