Initiative Roadmaps

“Just enough planning, just in time.”

There is something seriously wrong with the way we are planning and running Digital initiatives. Research shows that we spend one-third of our project budget developing detailed plans and yet 70% of our projects are troubled or fail, and 50% to 80% of the features we develop are rarely or never used.

One solution is to move away from project funding to continuous funding of product development, but few organisations have done this. If we are going to continue to do discrete initiatives, the solution is to plan them in an Agile way. Initiative Roadmaps provide just enough planning, just in time; allowing you to plan initiatives in less than half the time and half the cost, which means that you can deliver benefits much faster and catch up when you’ve fallen behind.

The Problem

We spend one third of our effort on planning.

Research and experience show that organisations spend more than half their time and one-third of their effort (and therefore budget) developing detailed business cases, requirements, architecture, designs and project plans. See Phase Distribution of Software Development Effort, 2008.

Most projects are troubled or fail.

Research by the Standish Group shows that 51% of Digital projects go substantially over time, over budget and deliver less scope than expected, and 21% are cancelled or not used. Everyone who has worked in this industry for a while has seen this many times. As a consultant, it’s rare to see a large digital initiative that is not seriously troubled.

Most features aren’t used.

At the same time, Standish Group research on internal products shows that two-thirds of the features we develop are rarely or never used. Standish research is supported by recent research by Pendo, which shows that 80% of features in the typical cloud software product are seldom or never used. This research shows that we are wasting 50% to 80% of our effort on most digital initiatives.

Why this happens

Research and recent experience shows that most organisations are delivering digital initiatives in stages with or without Scrum, as shown in the Water-Scrum-Fall diagram below.

Refer to:

• Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today by Dave West,
• Is There Really Such a Thing as a “Hybrid Agile” Method? By Mirco Hering
• Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices

The problem with staged projects is that each group optimises their part of the process at the expense of everyone else. During the business requirements phase, stakeholders add every single process, feature and rule they can imagine because they know that this is the only chance they have to get them built. Architects and UI Designers create intricate designs to deliver all these features without any consideration of time or cost. Development partners underestimate the work because they want to win it and know they can make a profit on change requests. During development and testing these projects always find out that a lot of their requirements, architecture and design assumptions need to change. These essential changes lead to significant quality problems, descoping and time and cost overruns towards the end of the project.

This happens because most Agile methods are Delivery Frameworks that address development-related tasks. They don’t have much to say if anything to say about budgeting, recruitment, resource management, sales, procurement, contracting or aligning with the company strategy. Hence, traditional approaches are used to provide a basic structure and a framework for project organization and to provide interfaces to the rest of the organisation.

In my experience, this “Hybrid Agile” approach creates a lot of conflict, confusion and change requests that are just as bad if not worse than a traditional staged development process.

Plans and designs decay

Despite the substantial investment in upfront design and planning these initiatives typically go off the rails when the world changes or they find their planning assumptions were wrong. Projects go wrong because designs and plans decay as the environment, scope and priorities change and as we learn what the requirements and solution should be.

Agile Roadmaps are a better approach

In this article, I will show you how to bring people together for two weeks to build a roadmap that provides objectives, goals and maps for the next three to twelve months. A roadmap that builds a bridge between Agile leaders and business decision-makers so that sponsors can feel comfortable giving you the funding you need to start and lead an Agile project: a roadmap that you update continuously and every iteration in a rolling wave.

Initiative Roadmaps

“Plans are worthless, but planning is everything.” President Dwight D. Eisenhower.

Plans are critical because they set expectations on the goals, the strategy and the resources you need. They justify the organisation’s expenditure on the initiative. They allow you to consider the problems you are likely to incur along the way and develop ways to avoid them. With a plan, you can prepare for different eventualities to improve your chance of success. With a plan, you can get the commitment and resources you need to achieve your objective. Without a plan, it’s improbable that people will give you the funds you need.

Some people argue that project planning is so unreliable that there should be no projects at all. But plans are still real. Organisations still spend buckets of money on improving a product or process. This surge of work must be managed and done. The reality is that most companies have not abandoned projects and programs so we must help them do initiatives in a more Agile way.

Initiative Roadmaps

Over the last few years, I have developed and refined an Initiative Roadmap process that allows you to define, design and plan an initiative in weeks instead of months or years. In an Initiative Roadmap, you set your goal, strategy and direction in a high-level plan so that you can get the necessary funding and support you need to build a delivery team. When the development team starts, they evolve the plan with business stakeholders to deliver the maximum business value possible within the time and budget available.

Initiative Roadmaps are useful for anyone who needs to get resources for the development of a digital product or service. They are helpful for people in general management, product management, sales, marketing, account management, project management, analysis, design and software development in a company, consultancy, Digital Agency or service provider.

I have used Initiative Roadmaps to:

• Plan a new eCommerce site for an Auto Manufacturer that allowed users to customise and price cars before going to a dealer;
• Improve the speed and performance of a Telco self-service mobile phone ordering and management portal for business customers;
• Enhance a self-service network management portal that a Telco provides to Banks and other Enterprise customers;
• Design and plan a knowledge management website for a Health Insurance company’s call centre staff and
• Design and plan a new travel website for a travel company.

Before we start

Understand the problem

Initiative Roadmaps help us develop a plan to solve a known problem. If we don’t understand what problem to solve or question to ask, then we need to discover the right problem to solve. To do this, we take the brief, question the brief, develop hypotheses and plan and conduct research.

Research can be qualitative or quantitative and behavioural or attitudinal. Qualitative research might involve interviews, usability studies and business process maps. Quantitative research includes analysis of your business processes, customers and product data. Most initiatives benefit from combining insights from multiple research methods.

The objective of Discovery is to get a clear business challenge summarised in a “How might we ?” statement. A how might we statement should be short and memorable with a character, goal and direction. It should be narrow enough to let you know your context, and broad enough to give you room to explore different approaches.

If we were talking about building a new suburb, the challenge might be:

“How might we provide first homeowners, young families and retired people with affordable quality homes in our new suburb as soon as possible?”

Get funding and commitment to develop a plan.

Before you start developing an Initiative Roadmap, you need to get funding and resources to do planning. In most cases, the Sponsor will prepare a presentation for executives that explains what the business problem is and why the organisation should commit resources for a few weeks to develop a plan to solve it. Some organisations may require the sponsor to go through a formal project inception process. It is not necessary to do a business case before you start an Initiative Roadmap because the Roadmap creates a detailed business case for the project.

Initiative Roadmaps are an intense process that requires a significant commitment and rapid decision making. Before we start an Initiative Roadmap, we need to book people in and make sure they are committed to the process.

What are Initiative Roadmaps?

An Initiative Roadmap defines where you are trying to go and how you plan to get there. It describes the team, budget, time and resources you will need. Initiative Roadmaps integrate product planning, UX design, technical architecture and initiative planning into a viable strategy to meet stakeholders expectations. Initiative Roadmaps bring senior stakeholders together with relevant experts to rapidly design and plan a new product so that you can get the funding and resources to develop it.

Roadmaps are about the end to the end-user experience, business process and system architecture. They define multi-step processes, and multi-system data flows. Roadmaps provide teams with a context, direction and strategy for the detailed design done in sprints.

The Product Backlog in Scrum is a product roadmap that defines what the team is going to do in the next few weeks. Each Sprint, the team, refines the product backlog by adding detail, estimates, and order to the high priority items they are planning to do next. In Scrum, we avoid planning more than a few weeks ahead because we assume that any work to detail items in the backlog “depreciates quickly and must be frequently re-estimated.” The Product, UX and Architecture roadmaps we are talking about here provide the big picture to inform and integrate the Product Backlog in Scrum.

With an Initiative Roadmap, we aim to avoid delay and waste by doing just enough Technical and UX architecture, design and planning just in time. To achieve this, we create a high-level product and Initiative Roadmap for the next 12 months, UX and architecture roadmaps and models for the next 3 to 6 months and detailed designs for the next 2 to 4 weeks. Our goal is to review and revise these plans every day and every Sprint. As the program and teams learn, they change their roadmaps and models.

An Initiative Roadmap is an alternative to the traditional staged analysis, design and planning process that takes one-third of your budget and half your time. Initiative Roadmaps replace Design Sprints, Business Case, Project Plan, Detailed Business Case, Business Requirements Phase, Solution Architecture Phase, UX Design Phase and the Technical Design Phase in Traditional and Hybrid Agile projects.

Why you need to plan further ahead

In my experience, teams that focus on planning stories for the next few weeks often produce narrow solutions that work well for small features but don’t work well when applied to other areas of the product. So instead of developing consistent and reusable UI styles for a website, each developer creates a version of the UI style for the component they are working on, which leads to a disconnected and fragmented solution with a lot of duplicated effort.

Local optimisation plagues organisations and is very common in AI research. A team that advances in small steps can get easily trapped in a local optimum that is sub-optimal overall. In contrast, a group that looks at the bigger picture can see over the local optima to the global optima more easily.

Initiative Roadmaps allow you to develop higher-level roadmaps that let you look further ahead so that you can more easily get to the optimal solution without getting stuck in local optima.

Refer to: Ayoosh Kathuria, Intro to optimization in deep learning

Designing Roadmaps

Experience shows that a small number of smart people who come together to sketch models and develop prototypes can define a viable solution design in two weeks, that is 70% to 80% right. This is an example of the Pareto principle, where 80% of the benefit is gained from 20% of the effort. The team can then iterate to 95% right through trial and error in a few months.

Refer to Scott Ambler:Just Barely Good Enough Models and Documents

Refer to Scott Ambler: How Architects Fit in on Agile Teams

Deliverables

An Initiative Roadmap defines the:

• Business Problem;
• Objectives and Key results;
• Customer Experience Roadmap;
• Solution Architecture Roadmap;
• Product roadmap prioritised by value, size and dependencies;
• initiative risks and issues;
• initiative budget based on the resource plan;

In a traditional project, each of these deliverables would be an 80 to 100-page document with detailed and comprehensive models, spreadsheets and prototypes that takes six weeks to develop and two weeks to review. We won’t be doing that.

In an Agile Roadmap, each of the deliverables will be a couple of pages of text, illustrated with 1–2 slides and illustrated through recordings, models, prototypes and spreadsheets. The aim is to provide just enough detail to allow the team to develop a plan that defines a viable strategy and reasonable time and cost estimates.

The Customer Experience Roadmap will map the end to end process flow, illustrated with black and white wireframes of critical interactions with 1 or 2 colour mockups to test the graphic design. It will not provide finished art, working code or a comprehensive blueprint for every user interface.

The Solution Architecture Roadmap will be a simple working prototype that passes data from one end to another to show how the main technical components work in our environment. It will not be a complete, detailed technical design, and it will not provide production-ready code.

Some examples from different initiatives are shown below.

How do you develop an Initiative Roadmap?

An experienced team led by a skilled facilitator can create an Initiative Roadmap in 2 weeks. On the first day of Roadmap planning, we explain the approach, set the objectives, determine the customer journey and the feature roadmap and develop the design and technical briefs. Then we simultaneously design the product, the user experience and technical architecture. At the end of Roadmap planning, we bring it all together to estimate, prioritise the features and document our findings.

The main activities are:

• Define the challenge and discuss the approach
• Define the business objectives and the key results expected
• Define customer personas
• Define the customer journey
• Define the product feature map
• Define the service blueprint
• Define the current technical environment
• UX sketching
• Recruit customers for testing
• Develop an architecture solution model
• Define the technical POC
• Define the UC POC
• Define the product features
• Develop UX wireframes
• Develop the technical POC
• Define the brand guidelines
• Define the initiative risks and issues
• Develop mood boards
• Review and integrate the UX and Solution models with the product features
• Develop interview scripts
• Conduct UX testing with customers
• Review the technical solution with architects
• Review the UX findings
• Review the features identified
• Estimate feature value and size and team velocity
• Develop a prioritised release plan
• Write up the results as a detailed business case
• Review the UX, Architecture and Delivery plan with stakeholders

In my experience, an Initiative Roadmap works best with a team of six to twelve people. Three to six people to run the process and three to six people to provide direction, share knowledge and make decisions. If you already have a delivery team for this product, then that team should do the planning with some help from experts. If you don’t have a product delivery team available or you haven’t set up the initiative yet, then you should bring together the people that you expect will be taking the initiative forward.

I estimate that there are about 70 days of work in an Initiative Roadmap spread across the team. The planning team should include a facilitator, designer, architect, business leader, business expert, technical expert and project manager. We can split each of these roles between two people if people are not available full time. For instance, the Sponsor could participate for 30 hours with the support of a Product Manager / Product Owner on their team who participates for 50 hours. And the UX/UI Design role could be split between a UX Designer and a UI Designer.

Role

Hours Effort

Facilitator / Agile Coach / Business Analyst

80

UX / UI designer

80

Solution Architect / Dev Lead

80

Sponsor / Business Unit Manager / Product Manager / Product Owner

80

Subject Matter Experts

80

Enterprise Architect / Integration Developer / Technical Domain Expert

80

Initiative Manager / Business Analyst / Documenter

80

Pitfalls to avoid

Traditional managers can inadvertently sabotage the Agile Roadmap by demanding all of the deliverables that they are used to in a conventional staged planning process. For example, they may insist on a detailed:

• Business requirements document
• Solution architecture document
• Technical specification document
• UI design document with finished wireframes and art assets for every page
• Project Plan with a Gant chart.

Traditional managers may also try to turn the Initiative Roadmap into a fixed scope, fixed-price contract for the delivery of everything defined in the Roadmap without change.

You can combat these problems by bringing traditional managers into the planning processes and using your time in workshops to teach people about fixed price, fixed cost, variable scope delivery with agile teams and explain what the deliverables will be.

You may also have a problem with the behaviour of participants in the planning process. Some people may skip workshops or spend their time in the workshops on laptops or phones doing emails. The facilitator should bring this behaviour to the attention of the sponsor and the planning team, explain the impact and ask the group what they should do about it.

What happens after the roadmap

After the planning team has developed the Initiative Roadmap, the sponsor can use it to request funding for product delivery. Or they may decide that the plan is too expensive and they need to find a cheaper way to solve their problem.

An Initiative Roadmap is not a one-time event that creates a fixed scope that must be delivered without change. A Initiative Roadmap is a living plan that evolves through continuous review and replanning at all levels throughout the lifecycle of the project. At the next level down, there is sprint planning, then acceptance tests, all the way down to continuous development, integration and deployment. If the team discovers that one of the assumptions in the Roadmap is wrong, then they change the plan to maximise business value within the time and budget available. It’s not plan-driven, it’s adaptive and evolutionary.

Scaling Initiative Roadmaps

You can use Initiative Roadmaps to plan large programs by mapping out big chunks of work that can be done in 3 to 6 months and then planning each piece as a separate initiative. Research by the Standish Group shows that smaller project are much more likely to be successful than larger ones, so it is always a good idea to break an extensive program into smaller parts.

Scaling your program

Rather than starting a massive program in one go, it is best to start with one team, prove that it can deliver the value expected and then split it into two groups, which divide into four and so on through a process of mitosis.

You should split your teams so that each one has an external customer or an internal client. Some of these teams might deliver value to customers directly, while others provide platforms and features that support the business-facing product teams. The more independent the groups are, the better. Complex inter-team dependencies slow you down.

Growing your program over time substantially reduces risk and allows you to develop a coherent culture and strategy across teams.

Integration Team

In programs, an integration team manages the cross dependencies between groups by developing the integrated product, architecture, UX, initiative and budget roadmaps for the next six to 12 months. This team has a Product Owner, Initiative Manager, Agile Coach, Solution Architect, UX Designer and representatives from each of the individual groups. The integration team is similar to the one defined in Scrum Nexus but with a broader focus on budgets, resourcing, architecture and UX design. The integration team will lead the development of the Initiative Roadmap for new initiatives making sure to include the people who will deliver if it is approved.

Benefits

Plan faster, plan better.

Initiative Roadmaps define an approach that a Product or Project Manager can use to quickly and effectively determine the product plan, solution architecture and funding for a new initiative. With this plan, they can get budget and resources for the project, start earlier, deliver faster, increase customer satisfaction, reduce risk and realise benefits sooner.

Roadmaps put your customer at the centre of the initiative so that you can develop a solution that meets their needs. They allow you to define a realistic plan to deliver a valuable product quickly and efficiently, on time and budget. And they put you in control of the development process so that you get the best outcome from your suppliers or develop the initiative yourself.

Initiative Roadmaps cut your planning time and cost by more than 50%, allowing you to deliver benefits much faster and catch up when you’ve fallen behind. The chart below shows the plan for a mid-size website redevelopment compared to what usually happens and what could happen with an Agile Planning. As you can see by using Agile Planning combined with Agile Delivery, you can finish the initiative in the time it would typically take to plan it.

I have found this to be true in practice. For example, the Digital Director for a major car company we worked with told me that they saved 12 months and hundreds of thousands of dollars by doing an Initiative Roadmap. The Sponsor for a Knowledge Management initiative at a health fund told me that we got further in 2 weeks than their IT organisation had done in the previous 12 months with a Water-Scrum-Fall approach.

I have developed and evolved Initiative Roadmaps over the last seven years for many large and small organisations. If you would like some help to implement this approach, let me know, and we will run it for you.

Murray Robinson is Managing Director at Ev0lve. If you would like to plan your digital service much faster with much less waste, you should contact us, or just learn more about Ev0lve, here.

References and Acknowledgements

Initiative Roadmaps draw on ideas from a lot of different thinkers in the Lean, Agile, Scrum, XP, Agile Architecture, UX and Design community. I owe a lot to Kent Beck and Martin Fowler for Planning Extreme Programming, Mike Cohn for Agile Estimating and Planning, Jeff Patton for Story Mapping, Scott Ambler for Agile Architecture, Eric Reiss for Lean-Agile Product Development, Jake Knapp for Design Sprints, Jeff Gothelf for Lean UX and Henrik Kniberg for Scrum and Kanban in the trenches.

I would like to thank Dean Netherton for introducing me to Agile XP in 2004, to Ben Scown for helping me develop an Agile planning approach at Telstra in 2009 and to David Cox for introducing me to Design Sprints in 2016. I would also like to thank the many people who reviewed and provided feedback on this article.

I hope that you find that the planning approach that I describe here provides you with a better way to initiate and plan an Agile project.