Since 2011, I coordinate the IT activities of a small, but growing food cooperative. This post is a tale from the long tail of IT management. Things are necessarily different than in organisations that are profit-oriented or have a large pool of possible contributors or consist to a large extent of IT-minded people. In our case, none of these conditions holds true. The theme here is an alarming lack of control over available resources (e.g. time and skillsets) and decision-making ability. How to make sense of this specific kind of battle?

Background I: our organisation

Vokomokum is an organisation to collaboratively order organic food directly from wholesalers and farmers. The resulting organisational workload is surprisingly high (well, you go and try and replace what supermarkets do for you).

Some parts of our infrastructure require configuration and maintenace, for instance a web server, our content management system and the public website. The more interesting parts are software for our internal workflows that we develop ourselves ("in-house"). There is not much software out there for food cooperatives and we found that the workflows we wanted need to develop over time (which is much better supported by in-house software development).

In particular, we wrote our own web-application for collaborative ordering from wholesalers and are now working on our own member-, workgroup- and shift-management application. We also need to order veggies with an actual web-app instead of a shared Excel-spreadsheet, but as you'll understand soon, that may take a while.

Background II: Healthy IT management

Overseeing IT infrastructure and software development are complex tasks as it is. Every organisation is different. However, there is usually agreement as well as widespread observation that the speed of development and the composition of teams should be within certain ranges, in order for the organisation to receive effective IT management.

In the following, I will argue by means of a simple list that small and local volunteer organisations operate outside of these healthy ranges. The issues themselves happen as well in IT management in business, of course. What I'm trying to say is that all these issues happen at the same time, by definition, and that the level of control over them is frustratingly low.

An unordered list of hardships

  • People The first issue is that the pool of possible contributors is small (we're a local initiative by definition) and not IT-centric (people join because they care about food). As a result, there is high variation in age, motivation and background, as well as IT level and experience, and almost never will two people find each other and be able to talk on the same level or topic from their experience. There are some people who claim to have some web design knowledge, but very few with serious understanding of IT, such that they could maintain or develop. People that do have an understanding will differ in what they are using. For instance, the ordering web app was written in Perl, because at the time (I wasn't around yet) that was the fastest way for the sole developer to get something done. There is no time to rewrite, and for now it works. Deal with it. In the meantime, I develop our new stuff in my own preferred language: Python. Should I've used PHP, because the probability is higher that newly-arriving members have some knowledge? Who knows.
  • Time People volunteer for this. The rule is that every member should contribute a couple hours every other month (called a "shift"). This rule is used for all members who are not among the most important contributors. These contributors actively contribute a lot more of their time anyway, for instance as workgroup coordinators. This concept of a shift might work for activities in other workgroups (e.g. the setup group receives the wholesale delivery and sets it up for members to come pick it up), but in IT you can hardly put someone to use who spends this little time per month. IT systems are complex. A few hours is spent fixing one bug or, more probable, remembering the way things work before you can actually go ahead and be productive. In addition, people who take on bigger tasks than a shift will seldom put their contribuition to our organisation on top of their priority list. We will always come behind their real job that has a salary, their families and sometimes behind their hobby, as well. That's the way it is. Time is not only scarce, it is fluctuating and uncertain.
  • Horizons Setting milestones in software development is hard as it is. But given the above points about people and time, it becomes even harder to estimate when a project might actually reach a milestone or even be put into production. For instance, I haven't been able to put a new Wordpress website online, because I first waited several months for the input of member A, who started his own company and couldn't find the time to set a basic site up. When he finally gave up, I found the time and set up a Wordpress site. However, I need to talk to our communication workgroup to get their approval and show them how to edit content. The responsible person, member B, was totally swamped organising festivals all summer. As a result, the ugly old website has been sitting online needlessly for almost a year now.
  • Narrative It is very important to document states, tests, error reports, READMEs and plans for the future. One problem here is, again, available time; but the biggest is involving the users (all members, coordinatoers of other workgroups). Installing a self-sustainable documentation mindset in such a diverse crowd requires a lot of effort. I've almost given up by now... One problem is simply that they don't have to use the ticket system I chose or email me readable error reports if they don't want to. I can't make them. Which brings us to:
  • Populism It is a volunteer organisation, with a culture of consensual decision-making (which many, but not all volunteer organisations have). Big decisions should be supported by organisation-wide consent, small decisions can of course be taken in a more straight-forward way. However, an IT infrastructure tends to touch the organisation as a whole and also even to influence its future development. For instance, we are working on an application to manage the shifts of all members in all workgroups in a unified way. We need some level of consent here, at least from group coordinators. But getting consent for an IT project in such an organisation is very time-consuming, all the more since most members cannot take the time to understand what the options are or what they mean to them. The same holds within the IT team. To make an unpopular decision can have grave consequences, for instance the loss of a contributor.

(Early) lessons learned about strategy

I do not yet have the experience under my belt to give sound advice on how to successfully do IT management in such an organisation. I currently am in the stage of acceptance :)

However, it seems to me that this setting requires a unique set of management qualities to be the center of strategy, among them patience, perserverence and still being open to adaptation.

Another quality seems to be to pick your battles. More often than I would want to, I have had to settle for "good enough", even on important issues like choice of programming language for a project, quality (or existence) of documentation or web design. But a local volunteer organisation is a different game. Just like a guerilla warrior, the challenge is to realise that setbacks are not necessarily a sign of weakness. This is the way we are and thus the only way we fight. As long as the organisation is alive and the team is learning instead of hesitating, outlooks are good.

After all, the main threat in our setting is not other competing organisations, but members losing their motivation and quit being a volunteer.

Consider the following question: Below which speed of progress in their workflows is a volunteer organisation not doing well anymore (according to their means), but should probably be considered dead? It is not easy to answer. It also doesn't sound like an appealing challenge to people interested in managing IT. But it seems to me an important one, if we

  1. find local volunteer organisations to be important
  2. realise that they need IT to remain important

At the moment, I can find the appeal in attacking this new kind of problem.

follow comments per RSS     
  on25 Sep 2012 - 9:24 fromJan www

To me the consensual decision making process was the biggest down side on my shot as a volunteer political Sambista.

Many people's roles seemed to be what I'd like to call the »watchdogs«. They didn't contribute much – neither in terms of musical skill nor otherwise – safe questioning every- and anything other people did for the crew. And boy did they love the principles.

As you already mentioned: job, family, friends come first, and then I have other hobby horses, too. So when I volunteered to organise gigs (negotiating money/transport/food, assuring we turned up with a crew that could actually play some of the tunes some of the time etc.), I cut my career short pretty emmedieately because the watchdogs made an efficient organisation impossible: they made it hard to pick gigs that were eligible: the events had to be not for profit, even though we asked for quite a substantial amount of money. The sponsors had to be clean and were not allowed to be connected with political parties, even if the party in question had pretty much the same agenda.

All this usually only surfaced and became a problem after someone had gotten the »go ahead« from a previous consensual decision. So in addition to an imense overhead decisions were never reliable and could be taken several times with several outcomes.

As an organiser, I can't worlk like that and as a programmer it sure is even more impossible.

In the end, I guess what I'm saying is that consensual decision making easily can turn into a euphemism fo decision making grinding to a halt, killing the rest of enthusiasm there is. Big, dangerous problem.

  on26 Sep 2012 - 12:28 fromNic

Yes, consensus is maybe too simple a concept, at least because it removes accountability. You can always blame the group. Here is an interesting article on moving beyond consensus (from someone who was a CEO in a software development company, nonetheless):

You are seeing a selection of all entries on this page. See all there are.