How do you create a road map for a non-development department? [closed]

Question

I recently started a new position as manager of a department in a small software company. I was project lead at my previous position, but our setup was much less formal and relaxed than it is here.

Not long after I started, my supervisor asked me to create a road map (we're not a development team) for what our department will prioritize and to specifically make two different versions of the road map for a team of 2 and a team of 4 (hoping to expand the team in the near future and use this as ammo to do that).

I have never created a road map, and the first two passes I've taken are clearly missing a lot of what he is looking for. I'm not sure exactly how to proceed when my best guess at what he's looking for is not in fact what he's looking for.

Anyone here have experience with this? Is there a formal definition of what a road map should look like or include?

Answer 1

Think about what a road map, a real one, provides you. A road map has your current location on it, your desired location, various types of roads that offer different things of value, costs, and risks to get to your desired location, and possible exit ramps (pun intended) if you were to run into an undesired situation, places to see, places to rest, etc.

These concepts can be walked over what you need to build a road map for business reasons. You can see how a real road map comes before establishing your strategic and tactical plans. In fact, it comes before you build your business case.

Same thing here for your purpose. It needs to outline where you are; where you want to go; the alternatives to get there; the benefits, costs, and risks for each alternative; escape possibilities; and places to pause and replan, etc. This enables you and your team to establish your business case, your strategy, and then your tactical plans.

Answer 2

sounds like the underlying question is how to deal with your supervisor. You've got 2 choices really.

The first is ask to have a 45 min meeting with him and where you can share some templates and get down to detail about what is expected.

The second is to create a quick version and present it as a first draft for his feedback so you can do a second or third more finished version before you deadline.

If your supervisor has other line reports, you might be able to get their guidance.

Apologies if I've mis-read the question, hope that helps.

Answer 3

I can say for sure that the problem here may not be that you are not writing the proper roadmap but his vision for your department may be different from what you envision.

I will suggest you organize 30 mins meeting with him to gather full details of what his visions for products are. This will help you kickstart in the right direction and prepare the roadmap on what matters to the department.

Answer 4

A roadmap is simply a list of activities and milestones, presented on a timeline, designed to reach certain goals. There can be ramifications, and there can be several levels of detail (e.g., the roadmap for the team can additionally contain the roadmaps for each member of the team).

Graphically, there are many ways to do it, it is just a matter of preference, or a matter of company culture (if there is any). However, you miss the real information (see below), not the way to present it.

---

the first two passes I've taken are clearly missing a lot of what he is looking for

The most important thing before you start designing the roadmap is to understand the requirements, what is expected of you. Please spend some time with your manager and ask him what eh wants, and ask questions until everything is clear. Take notes while doing so, in order to have the information when needed later.

---

I'm not sure exactly how to proceed when my best guess at what he's looking for is not in fact what he's looking for.

That is the same thing with different words. You do not need to guess, you have to find out.

Answer 5

There isn't a formal definition of a roadmap, mainly because roadmaps are used to communicate information, and the amount of information that people want to show inside a roadmap varies depending on the working environment and the target audience.

A roadmap should show the WHY and the WHAT of your next goals (Where you are headed? What are the things on your path to get there? Why is that important?).

They might look like this for example:

But many of them end up looking like this:

A lot of tools show them similar to a Gantt chart because they are easy to draw, and because it's easy to attach dates to the boxes. Much more so than with a free floating format as in the first images.

This is where the lines between a roadmap and a timeline start to become blurry and you end up with a mix of two concepts:

• your next goals, and
• the outputs needed to implement those goals within a given time frame.

So now it starts to become about the HOW and the WHEN.

This tends to happen because most tools facilitate it, and also because the first question you always get asked when looking at any roadmap, is "When will it be ready?"

A roadmap can include time frames for sure, but they are usually in quarters or months. If you end up with things like "the 15th of September", then you might not just be looking at a roadmap.

I'm not sure what kind of a roadmap your supervisor wants, but since the last model is the most commonly used, and since he told you to make two different versions of the roadmap (for a team of 2 and a team of 4), I'm suspecting it's this last one. Maybe as far as turning the roadmap into a real Gantt chart to show a breakdown of the work, with sequence of activities, dependencies, and assigned deadlines (i.e. "If we have 2 people working on it, how long will it take? If we had 4 people working on it, how much sooner could it be ready?").

The best way to find out your supervisor's expectations would be to ask. Maybe he has some older examples of what he expects that he can share and you could look at. Like I said at the beginning, roadmaps are visualizations used to communicate information, so find out what kind of information your supervisor wants to extract from the roadmap and you will then know how to build one and what to add to it.