What is good in a project?


Where to start again on this blog after such a long interruption? Not with a digression (*) straight away!

Anyways, I’ll start again with a question that has been tickling me for a long time:

What are the good parts of a project to keep and use?

Development, oops rather aid (i.e. donor-driven development) is largely structured around projects. This is how many of us out there work. We end up cooperating for three, four, five years in a given place, with a group of people and institutions, following semi-random streams of activities sometimes called ‘work packages’. And throughout the project years we come up with ideas, principles plans, activities, approaches, tools, reports, templates, lessons, publications to do what we think we have to do. And then one day the party is over, alliances fade, activities stop, the flow of knowledge and information dries out. And then comes the question: what really makes sense to keep track of at the end of the day, other than the great moments spent together and the nuggets that have pleased project beneficiaries, staff and/or donors?

Much like there are various beef cuts that can be used in a cow (sorry for any vegetarian or vegan reader out there), what are the parts of the project that we can use (in this case, again) because they could be useful?

Beef cuts and project nu(gge)ts - what should we keep? (Photo credits: global wildlife warriors)

Beef cuts and project nuggets - what should we keep? (Photo credits: global wildlife warriors)

What is there to ‘capitalise’ on afterwards? This question is becoming crucial for me as I’m involved in a soon ending project and am puzzled as to what to do with all the process information we have collected through the years.

We have of course, like many projects, the official documents – the emerged side of the iceberg: the papers, newsletters, websites and the upcoming book we’re writing… the flashy documents we have happily commit to produce as agreed in the contract.

But hidden all around, are the guidelines, templates, checklists, information sheets, how-to’s, process reports etc. that we have developed in the past five years.

Usually these documents do not make it to the official ‘documentation’ of any given project. And yet perhaps what might be precisely most useful to others, more than the results of the project even is that process information describing how a project has looked at certain activities and proposed to go about them. This is what can be re-used, learned from, integrated. So that next time a team starts similar work, they focus on slightly better sets of questions and issues…

What do you think? What is good to keep? Does it make sense to keep track of all the ‘process’ outputs of a project? Is it worth investing time to polish them so they can be understood by an external audience? How shareable are they compared to the project outputs?

I hope you can shed your light on this, as this may be an important KM question for development projects… And that specific project I mentioned is about to be cooked up so it might as well be useful and inspire others…

(*) It probably doesn’t matter much where I start blogging again, since I suspect only few people are checking this page after several very quiet months. Besides, those that do visit this blog sometimes tell me they don’t always understand what I am saying. So, for you puzzled reader, read my profile. And by the way, and I always welcome questions, so share your puzzles!

Related blogposts:

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s