One of the challenges that every community faces, particularly teams inside a larger community, is the ability to coordinate what goals and ambitions the team is going to work on. Traditionally this has always been somewhat ad-hoc: people join a team and work on whatever they feel like. Ideas are ten-a-penny though. For most teams that work on larger projects (such as events, software, products and more) to actually be productive, coordinating this work can be complex: some projects require coordination across many people with different skill-sets, time-availability and resources.
Something I would like us to work towards in the Ubuntu community is encouraging a culture of best-practise in how we plan our work and coordinate our awesome teams to work together on projects. I believe this kind of coordination can help our teams increase the opportunity for success in their work, feel more empowered and productive and provide greater insight to people outside those teams on what the team is doing.
An effective way of doing this is to build a *Roadmap* for each cycle. This provides an opportunity to capture a set of goals the team will work together to achieve in each six-month period. This article outlines how to build such a Roadmap.
## Creating Your Roadmap
While at first a roadmap can feel a little like a nod to the gods of bureaucracy, they actually possess many benefits:
* **Direction** – one of the biggest complaints teams often report is a *lack of direction*. If a team gets into the habit of creating a roadmap at the beginning of a cycle, it gives the team a sense of focus and direction for the coming cycle.
* **Documented commitments are more effective** – a common rule in Project Management training is that actions assigned to people in a shared document are more effective than ad-hoc or private commitments. By documenting who will work on what in a cycle and putting their name next to an action can help seal a sense of accountability for their contributions to the project.
* **Feeling of success** – regularly revisiting a roadmap and checking off items that have been completed can develop a strong feeling of progress and success. It makes a team feel productive.
I spent some time recently putting together a little bit of infrastructure to help making roadmaps as simple as possible. This is how it works.
### Step 1: Decide what your team wants to do
The first step is to open up a discussion with your team to talk about things that the team would like to do. As an example, a LoCo Team may want to organize a booth at a given conference or work together on marketing materials, a documentation team may want to work together on a book or guide, a software team may want to work together towards a first release, and a translations team may want to work together on documentation to help translate a particular language and organize translations events and sprints.
The most effective of way of having this conversation is to produce a wiki page in which people can jot down their ideas and this can form the basis of converting key popular ideas in the team into roadmap items. Keep the discussion focused on the next cycle (which lasts six months). You should make sure you have these discussions out in the open in your team communication channels, be it mailing lists, IRC channels or otherwise.
It is important to note that *not every contribution has to be on the roadmap*. Roadmaps are great for larger projects and goals.
### Step 2: Create your roadmap document
To make things as simple as possible, I have created a roadmap template and place to store roadmaps. This is how it works:
1. Go to [https://wiki.ubuntu.com/Roadmaps/Lucid](https://wiki.ubuntu.com/Roadmaps/Lucid) and create a page in that namespace that reflects your team (e.g. https://wiki.ubuntu.com/Roadmaps/Lucid/ExampleTeam). Be sure to add a link to your new page on https://wiki.ubuntu.com/Roadmaps/Lucid by using this markup: `[[https://wiki.ubuntu.com/Roadmaps/Lucid/ExampleTeam|Example Team]]`.
2. Open up a new browser tab and go and view [the roadmap template](https://wiki.ubuntu.com/Roadmaps/Template). Click on *Edit* and copy the content from the template into your new team page that you created in the previous step.
You are now ready to start building the roadmap.
### Step 3: Capturing projects in your roadmap
The roadmap is broken into a set of sections, each of which points to a particular goal you want to achieve. Each goal then has an *Objective* block which provides a task that needs to be completed to achieve part of the goal. Each goal can have *many objectives*.
The *Objective* block is structured like this:
* **OBJECTIVE**: An Objective is a goal that you want to achieve. Summarize your objective here in one sentence (e.g. ‘*Exhibit Ubuntu at OSCON*’ and ‘*Create Lucid Marketing Materials*’).
* **SUCCESS CRITERIA**: This is a statement that can be clearly read to determine success on the above *Objective*. This needs to be as clear as possible and not vague: it will indicate if you achieved the *Objective* (e.g. ‘*A successful exhibition at OSCON*’ and ‘*Lucid website buttons, banner ads and wallpaper provided for LoCo Teams*’).
* **ACTIONS**: This is a set of steps that need to be executed to achieve the *Objective*. It is recommended that if someone volunteers to commit to delivering on an action, you put it in brackets (e.g. *Print out LoCo logo on a banner (Jono Bacon)*). There can be multiple actions for each Objective.
* **BLUEPRINT**: If a Launchpad Blueprint applies to this Objective, link it here (*optional*).
* **DRIVER**: If someone is coordinating this objective and helping those involved to deliver on their actions, list that person here (*optional*).
The aim here is to try and capture what your team wants to do and who will be contributing to the goal. Let’s look at an example of organizing an event:
> * **OBJECTIVE**: Exhibit Ubuntu at LugRadio Live 2009
> * **SUCCESS CRITERIA**: A successful Ubuntu exhibition complete with demonstrations and materials.
> * **ACTIONS**:
> * Confirm booth space with LugRadio Live organizers (Steve Harris)
> * File a request for CDs from ShipIt (Bruce Dickinson)
> * Develop artwork for main banner sign, staff badges, flyers (Janick Gers)
> * Provide demonstration laptops (2 x laptops) (Dave Murray and Adrian Smith)
> * Prepare demonstration speaking script (Nicko McBrain)
> * Promote our presence on LugRadio forums, Planet Ubuntu and Full Circle Magazine (Steve Harris)
> * **BLUEPRINT**: N/A
> * **DRIVER**: Steve Harris
The goal of a roadmap is to capture as many of these projects and apply the same structure that no only communicates what needs to be done, but also who has volunteered to work on which actions.
At the [Ubuntu Developer Summit](https://wiki.ubuntu.com/UDS) next week I will be working with many teams to talk more about this approach to roadmaps and encouraging our various teams, LoCo teams and councils to start experimenting with a roadmap to see how well it can help the team be successful.
