Transnational project management is a key feature of all European projects, comprising a range of more or less formalized tasks and activities, that shall allow for the smooth and efficient implementation of projects. Over the past years a broad range of methods and tools have been developed, with a view to support the day-to-day and strategic management of EU projects. The bulk of those however is dedicated to planning, monitoring, documentation of results and outcomes, accountancy and evaluation.
Although those tools can be helpful at certain stages of a project, they show of very limited value when it’s about the a) creation of shared meaning of the project, as well as objectives and tasks, b) building of common ground for collaborative action, c) ensuring commitment, ownership and active engagement of everyone involved in the project and d) promoting exchange of experience and knowledge. In my opinion many of the problems that occur during the course of projects can be attributed to the absence of one or more of these conditions. The reasons may vary, as do the problems caused by them.
Project management software comprises tools, which work pretty well for projects taking place within organisations, but often show inefficient and bulky if applied to projects that operate across organisations and multi-stakeholder environments (typical for most European projects). Another shortcoming can be seen in the fact, that they require full control over all project parameters from the first to last second. The project design is supposed to be exactly right from the beginning, and within some narrow confines to remain unchanged until the end of the project. But, the most crucial downside is the fact, that most of those tools don't grow with the project needs.
In response to these limitations many of my colleagues including myself over the past years have searched for alternatives, which we finally found in WIKIs. Since 8 to 10 years we now work with WIKIs, with the help of which we build common workspaces and collaborative environments for European project partnerships.
WIKIS quite often are confused with Wikipedia, and people think of them mainly as tools for building knowledge repositories, such as encyclopedias or glossaries. However, WIKIs can do a lot more. They are real-time collaborative editing system, based on the wiki concept, which can be shaped in various ways to meet the needs of projects. One major advantage of WIKIs is that they can change to respond to the project's needs as they arise. This makes them attractive for project collaboration, especially when working in distributed project teams.
WIKIS help project actors on fitting their activities into the bigger picture
WIKIs gives project actors visibility into their work process and, more importantly, gives individuals and project partners a clear sense of where their work fits into the big picture, work and efforts of the team, questions they are grappling with and the complexity of tasks. Thus, WIKIs not only support a better understanding of the whole R&D endevaour, but help to break down any ‘them and us’ thinking. Moreover, WIKIs showed a much better means of coordinating contributors than the usual cumbersome method of e-mails and file attachments. And last but not least, WIKIs helped us to bring together all conversation and materials in one place. Jenny Mackness
A technical advantage of wikis over other document management tools is that there are plenty of good open source versions available at little or no cost. Plus, such wikis are usually extensible, so you can customize them to your needs. WIKIs are available as stand-alone software packages, which with the help of plugins can adapted to different needs. Those software packages are available for free, but require installation on a server (for example MediaWiki). So, some technical knowledge is required in order to make the WIKI work the way wanted. On the other hand there is various web services, such as pbworks, which offer free WIKI spaces, with an option to add extra features for a small fee.
Basic structure of the WIKI
Although some preliminary work (around 3 days) will be necessary to set up a WIKI, this investment pays off during the lifetime of the project and beyond. When creating a WIKI, the first step usually is to develop an overall structure and to define the areas and categories of utmost relevance for the project. All that should be kept as simple as possible.
Based on past project experience, I’d like to recommend the following basic sections:
- Information section, where all official project information is stored (original application, overview of aims and objectives, work programme, specifications of tasks and deliverables),
- News section, which holds updates on milestones reached, changes of the work program or partnership, calendar of forthcoming events and, any relevant third party news related to the subject area of the project,
- Repository of results, holding draft and final versions of products (needs some conceptual planning. Especially when outputs are developed iteratively, and there's many versions of the same item.)
- Library of documents (literature, materials, recommendations for further reading etc.)
- Documentation section (minutes of online and face-to-face meetings)
- Progress section, which at a glance provides an overview of upcoming, ongoing, completed and postponed tasks and activities, each of which should be linked up with the person(s) or team responsible for carrying out the activity.
Needless to say, that project managers should always bear in mind that, it’s first and foremost persons who come together in projects in order to share their experience and expertise towards solving a problem or developing innovations, while partner organisations by and large remain black boxes for those collaborating on a daily basis. But that's another story.
Over the years WIKIs for us turned out a quite valuable tool, helping to support the project actors towards developing a sense of ownership for processes and results , as well as building common ground and shared meaning for collaborative action.
Adding visibility
WIKIs also offer a variety of tools, which can be used to visualize virtually every aspect of a project. For example, our wikis start with a picture of the team, taken at a workshop all participants felt comfortable with. This reminds people of both, that they are part of a bigger team, and in a more subtle manner, of successful collaboration in the past. Moreover, we add photographs of key actors to each single task and activity. So, everyone in an eye-catching manner can see who's engaged in a certain piece of work, team mates sharing the work, persons with leading roles, peer reviewers involved etc. Photos show that a real person is behind each activity. Nothing is sadder than tasks lists with a bunch of partner logos, indicating the organisation a person represents in the project partnership.
The photograph is followed by both, a short and detailed description of tasks and activities. We usually spend plenty of time on breaking down „abstract“ tasks into concrete activities because of two reasons. We often have the situation that applications were written by one or two key persons, who built the project on assumptions, ideas and concepts most of which remain implicit and thus, there is a certain risk that people come to different interpretations of the same text. Also at this point WIKIs can be of great value, because they allow project actors to add their point of view or make comments on conclusions drawn by others. So, step by step the partnership can build common ground for the project.
WIKI page: News section
WIKI page: Repository of project outcomes and results
WIKI page: Monitoring progress
