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.

Monday, September 12, 2005

Like pulling teeth


Software Engineering texts often talk about “extracting requirements” from users. The dental analogy is painful. The implication is that the requirements are all right there - - but the users are oddly incapable of just spitting them out. A tray full of nasty-looking instruments will be necessary to grab onto them and yank.

I’ll tell you a story. We were working with a new client, a membership organization, to develop a specification for the customizations they’d be needing to MEMBERS ONLY. We held a three day series of meetings to work it all out. One of things that came up repeatedly was their dues billing process.

Each time it came up we were told that there were exactly two ways a member could handle his dues. The member could get an annual invoice, or he could have a monthly amount charged to his credit card. If he wanted to be invoiced, he had to pay the full annual amount at once. If she wanted to pay monthly, it had to be by automatic payment. End of story.

On the third day of the meetings, one of our client’s staff corralled me in the corridor. “I’m afraid we may have given you the impression that we do not allow members to receive monthly invoices.” Given us the impression? They had practically sworn to it. But it turned out hundreds of members received monthly invoices and paid them by check.

So there were three billing plans, not two. We had finally extracted the requirement! But why was it so difficult to learn this? In this case, it was because the monthly invoicing was in contradiction to the organization’s stated policy. But the membership folks in the trenches knew they’d lose members if they dropped the monthly invoice plan. Now they had a dilemma. Tailor the new application to reflect the board’s reality, or the staffs?

Each time it seems we will need to use Novocain to find out what the users really want or need, it turns out there is an organizational development issue festering beneath the gum line. And often the group assigned to work with us to deploy MEMBERS ONLY does not feel that they are empowered to tackle these deeper issues. When this empowerment exists, the software “Business Integration” process can be an exciting journey moving the mission of the nonprofit forward. But when the group can’t take on these issues, the process is about as thrilling as an hour in the dentists chair..
Tags: ,

Comments on "Like pulling teeth"

 

Anonymous Anonymous said ... (September 12, 2005 at 10:00 AM) : 

Michael,

I totally agree. It is imperative that the people with the power to decide, be it explicit or implicit, be included in the decision process. In this case folks on the board, the "customer-facing staff," and to some extent the members themselves. Someone has to say to the board "the emperor has no clothes..." and the "someone" in this case may be the members. They are silent but powerful constituency.

 

Anonymous Anonymous said ... (September 13, 2005 at 2:25 AM) : 

Great article. This is typical of a nonprofit. Often times top leadership is clueless of the actual workings of the organization. Having worked with several both on staff and as a consultant, I seldom rely on what top management tells me - the staff can be far more helpful in finding solutions and implementing policy that actually makes a difference.

 

Anonymous Anonymous said ... (September 19, 2005 at 11:02 PM) : 

I'm not sure who said it first, but these are words to live by: "strategic I.T. planning in the nonprofit sector is stealth organizational development."

 

Blogger Mubeena Mohammed said ... (October 7, 2005 at 4:25 AM) : 

As an aspiring Organization Development consultant this incident is common occurance (and good for the consulting business lol).

To avoid scenarios like this, the meetings need to include representatives from all those who will be affected by the final product. This is an uncommon practice which needs to be made more salient in today's business world. A frequent customer of the client should be invited to test out the application if you will, and it would be ideal to have him/her be in meetings so that communication is covered on all aspects.

 

post a comment