longterm-group-processes-and-project-management

E. longterm group processes and project management

Now you know a lot about single and regular meetings and documentation.
But maybe you are going through a longterm process you need more longterm tools for. You need to find strategies? You will find some key planning tools here…

E.1. clear goals

As for a meeting, before you can start a project, make sure that you have collected all your goals you want to reach. It is important, that you define reachable and clear goals. “Change society” would not be a clear goal. When have you reached that stage? When you changed within your group? Your village? Your country? The whole world? And what kind of change is that?

“Take care about each others needs in within the community” would be a bit more clear, but still quite vague. What is it exactly, that you want to reach for yourself and together?

When you have defined clear goals, you can use e.g. “backcasting” to find a way of realising them. There is different ways of doing backcasting and you can probably find a lot in the internet. Backcasting is used for instance in the “future workshop” (see C events) and in milestone planning :

E.2. milestone planning

Milestone planning is the most basic tool of project management, and it is easy.
You have defined clear goals, where you want to go. Now you go backwards and try to find subgoals which you have to have realised first, before you can reach that goal. Those are called milestones.

Word the goals and milestones in the past-form, “DONE”.

For instance:
The goal would be: “Brochure printed”.
Milestones could be, in backwards order:
“Layout ready”. “Know how to use layout program”. “Pictures chosen”. “Translations done”. “Articles written”. “People informed and motivated to help”. “Lots of emails written”. “Fundraising done” … and so on…

You arrange them onto a timeline. One method is to do it on a big wall. Draw a timeline onto the wall (should be a longterm timeline of at least a few months). You use small colourful papers in different colours and forms. Like, for instance: blue round ones for goals, red square ones for milestones.

Then you start to arrange milestones onto your timeline. Take care about which milestones have to go first, before others can be realised.

Each milestone can be splitted in several to dos then. That would be, for instance “send email to Jaqueline”. or “Translate article about permaculture”.

You can use e.g. small white papers to stick the single to dos onto the timeline, too.

Of course you can do different goals in rows under each other. So you can create your personal milestones plan for different projects for the next half a year.
It is pretty good to use this method together with different people, too, for a common project.

E.3. clearing out strategies

It is really important in project management to clear out different strategies, and ways how to reach your common goals, which you defined before.
Analyse different approaches you have towards challenges on your way, and help each other with finding ways to realise different strategies.

Important, central questions might be, for example:

  • How open to be towards cooperation with other people outside of the core group
  • How to integrate new people
  • How to do publicity and get people involved
  • What steps to take next / which goals to realise first
  • When you want to see your project in which phase
  • What skills, ressources, contacts you need and how to get those
  • How to organise as a group (including roles, tasks, structures, and responsibilities, as well as legal forms)
  • How much money to put into a project, and at which point
  • How to get that money

There might be very different opinions on many points – in no case it makes sence to fight about those strategies. Try to help each other out in making the strategies as clear as possible, and check together which ones are the most realistic ones. Collect the basic questions and different ways to answer them. Draw strategy plans and compare them. Which strategy has which positive and negative effects. Make clear what everyone could and would want to contribute to which part of which strategy. Which solutions seem to be most realistic in the end?

E.4. clear responsibilities and availabilities

I found it quite important to have clear responsibilities and availabilities in the organisation team. I like the concept of foculizers and facilitators a lot:

A “foculizer” is someone who keeps the focus on something getting done. Which does not mean that (s)he has to do all to dos him/herself, but that (s)he keeps an overview about something. You could for instance have a foculizer for Public Relations, that would be the person who has the overview about all contacts and publicity of your project. Someone else could keep the overview about finances. All the other people are doing P.R and finances as well, but the foculizer knows what all the others are doing and centralises the information. (S)he also serves as contact person for new people who are interested in this part of the project, for instance.

A “facilitator” is someone who cares for facilitating that things happen. Like for instance if I would facilitate a meeting, I would take care of finding a place and time, and preparing it nicely.

Make sure that you have foculizers and facilitators for the most essential tasks of your project, and that everyone involved in the project takes at least one of those roles.

E.6. agile development/agile meetings/scrum

This is a dynamic way of planning projects, which comes from project management in commercial entreprises. Scrum is one important method used in agile sofware development, it is also already getting used in the creative scenes (among designers, etc). I find it pretty interesting and inspiring tool that the tools have more potential, and I would like when people experiment with using it in other contexts, too.

Agile development is a very flexible and productive process, that values the dynamic interaction of individuals, the process and outcomes more than bureaucratic framework. In the agile process teams and individuals are working in a selforganised way and are communicating crisscross.

The basic philosophy behind agile development is:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The basic idea of agile development is that you plan every single step of a project “agile”, that means: in a way so you can use the results every step immediately. Like one example: You have an idea, you wanna make a website. Now don’t wait until the designer has made a colour concept and logo in a week or later. Try to get something you can use immidiatly. Make a flexible layout and concept, which you can improve later on. You can just add in that logo later on work on usability and contents in the meantime. Draw some webpages on a notepad and ask some people if they understand the structure. Don’t waste time for doing a perfect draft, which nobody will use cause later on there is a basic mistake about understanding in it. Create something that you can use, as early as possible, and get some feedback!

My first “scrum teacher” explained to me, that the main concept was a quick cycle: “… Inspire, ideate, implement. Inspire, ideate, implement. Inspire, …” He explained that for developing an idea it is important to get as many opinions as possible of as many people as possible as early as possible. And then to improve the idea, test it, improve it, test it, improve it, test it… Over and over again.

In the begiining before you start a project, you prepare the “Product Backlog”. The “wishlist” for what would make the project great. Then you split it into “Release backlogs”. That is all the things that you want to reach in one cycle, until the next “release”, (in Software you have different “releases”, in other projects this could be phases until the next big change, you can use mlestone planes to find out about your “releases”).

Time of a Release Backlog then is divided into short cycles called “sprints”.
A sprint can last from 7 to 10 days in commercial software development, in other projects I guess his number could vary.

One more essential thing is “Burndown Charts”. This is a tool that helps you to estimate the time you need until the next “Release” (cycle), and to prove if your plan about getting things done is realistic.

Meetings:

There is very short so-called “standup-meetings” each day, when all members of a team come together. The participants are standing, to make them go quick and really keep it short. The basic questions for a standup-meeting are: “What did you do since yesterday?”, “What do you plan to do today?” and “Do you have any problems accomplishing your goal?”

Each day, there also is a meeting of members of different teams, answering the same questions, plus: “What has your team done since we last met?”,“What will your team do before we meet again?”, “Is anything slowing your team down or getting in their way?” and “Are you about to put something in another team’s way?”

After each "sprint (=every 7-30 days) there is a meeting to "select what work is to be done, prepare the “Sprint Backlog” that details the time it will take to do that work, with the entire team, [to] identify and communicate how much of the work is likely to be done during the current sprint

After each sprint, there is 2 meetings to review the sprint: One meeting of maximum 4 hours to “review the work that was completed and not completed” and “present the completed work to the stakeholders (a.k.a. “the demo”)”

Another meeting of maximum 3 hours where “All team members reflect on the past sprint”, “Make continuous process improvements”, with the two main questions “What went well during the sprint?” and “What could be improved in the next sprint?”

Thanks wikipedia, thnaks youtube, and thanks to my nerdy friends for the beautiful inspiration. Ideated. Implemented. In under 1 hour.

Scrum and Crabgrass Dev