I’ve been thinking about how to plan not just a large development project, but multiple large development projects together on a timeline and allow for interrupt work.

We’ve managed to put together a roadmap for the next fiscal year. It looks nice, and it conveys useful information for our plan for the year. But it has some flaws, and I’ve been mentally taking a step back to try to understand the purpose of having a roadmap, and what useful results it feeds.

We need a way to queue work so that we’re preparing for work that is valuable. There’s a tendency to list out all of the things that we could be doing and assume that we will do all of them. It’s a little odd, but it seems like there is a never ending stream of projects that could be done that are valuable. New projects appear all of the time. We avoid certain projects because dependencies aren’t clear or ready, and then as time passes, those dependencies clear and allow us to move forward.

Ordering the work so that we’re accomplishing things that are important to the business early is useful, and setting up some kind of roadmap for this purpose is a tool to visualize the results of this effort.

We need to ensure that we’re allocating people to the work efficiently. Each person on the team could be working on a different project, but that’s likely not the most efficient allocation of resources, nor would be focusing the whole team on a single small project. We need to know the size of projects and requirements for them in terms of allocating resources and personnel, both in terms of number of people to apply to a project but also in terms of which people have the skills to accomplish each project.

If we allocate the wrong number of people or the wrong people, projects will take longer than plotted, or will be completed in a lower-quality way than desired in the same time.

We need to roughly predict when we might accomplish certain projects to keep our stakeholders informed. We are sometimes a dependency for some other teams, and so they would need to be able to expect when certain features will be ready for them. Many of our features are delivered to an in-house team for use as users, and so training on those new features must be developed and provided. Some features support features being developed by other teams.

There is a huge hole in how roadmap planning for interdependent projects works. Different units within our business keep their own roadmaps and rarely share their plans until after their roadmaps are firm. Also, their roadmaps tend to be firm as opposed to living artifacts. Perhaps rather than simply informing our stakeholders of when (or just in what order) we might accomplish a project, we should work with them more closely to collaborate on releases. There is definitely a danger here of having our work driven completely by external parties and never accomplishing value for our own unit’s internal stakeholders.

We need to ensure that certain hard deadlines are met. Not all of our projects have external deadlines, but a handful do. For the ones that do, we need to be able to find a date by which we must start in order to meet the deadline.

There’s a bit of irony here, because when I think about it, I feel like most other business units in the company have this same situation, or even fewer deadlines than we do. Often, the contracts that require them to do things by a certain time are the same ones that require us to also be compliant. Very few other teams have hard deadlines that are given by contracts, and yet there is a lot of driving force that comes from those teams. This seems like something to consider more heavily.

We need to be able to fit in important work that was unexpected, and know when we must defer less important work than what we currently have in queue. This happens to everyone. It wasn’t but a month after completing our initial roadmap than we had three new project-sized concerns that would require reallocation of time in our roadmap. Some of that work came with external deadlines. Some was hypothetical business case. Some provided obvious value for our stakeholders. Comparing these objectively to our existing work, knowing what we could and could not move within the timeline, would be helpful for planning, and for potentially saying “no”. It also belies the need for the roadmap to be flexible enough to be adjusted based on need.

We need to be able to shuffle the queue at any time based on changes in priority from our stakeholders. Things change very quickly, and our ability to adjust to aim at the most important thing is one of the most vital ingredients in our project planning workflow. One of the symptoms of the problem we have here is that after you spend so much time developing a roadmap, you’re reluctant to change it. In spite of most of the timing being educated guesses and knowing with little certainty what important projects might lie undetected in the future, we hold on to that initial plan and resist changing it. I’m seen project managers reject new, important projects (literally company-ending “you must complete this or violate contracts” projects) simply because there was no time left in their roadmap. That’s catastrophically stupid.

Protecting the important work makes sense, but not at the expense of even considering whether new work is more important or the cost to catch up if the project was undertaken later. I don’t want to be caught having completed something irrelevant when I could have been doing something that keeps the company afloat.

We need to understand what space there is in the schedule for maintenance work, and to ensure the correct amount of this space exists. Too often, we pack the schedule tightly with project work, and forget to make time for tackling the basic maintenance that keeps things running. Often, people will liken this to changing the oil in a car, but that implies that 1-4 times a year is all the maintenance that is necessary. This should really be much more regular, and if done at a proper pace - in my opinion - it should be continuous along with other work.

Sometimes maintenance rises to a project level. When this happens, you know one of a handful of things: Either the project was unanticipated by everyone, your developers have revolted against developing more features until conditions in the code base improve, or you’ve simply allowed maintenance to accumulate to the point that it must be addressed. In two of those cases, maintenance has been ignored to the detriment of feature work, since the pace of feature development is negatively affected by a codebase that is poorly maintained. And yet for some reason, teams allow this to happen frequently.

Well, I’m glad I got a few thoughts down. I’m not sure yet what solutions will solve for all of these issues. The one conclusion that has been growing in my head is that roadmaps, at least as how you typically see them, are insufficient tools for solving these problems. They lack some of the specific flexibility to approach some of the issues above. Even if it’s just the mindset of the people that employ them that’s flawed, the tool is encouraging that mindset, and a better tool could encourage more correct thinking.

I suggested yesterday that we remove dates from our roadmap entirely. I also suggested that we potentially take “samples” of the calendar, and estimate (by percent chance) what projects we might be working on at that time. The samples would decrease in frequency and certainty as they got farther away from the present date. I’m not sure that these are the best suggestions, but I think they’d help frame what could be a useful tool going forward that is not a traditional roadmap.