Just enough planning, just in time.

By Murray Robinson, MD Evolve

Murray works with organisations to design digital projects and organizations capable of realizing them. He has 30 years experience in IT starting as a software developer, 20 in digital, 20 in project management, 16 with Agile and 3 in UX. Contact Murray at murray@ev0lve.co if you would like to find out more about planning and running Digital projects.

Executive summary

There is something seriously wrong with the way we are planning and running Digital Projects. Research shows that we spend one-third of our project budget developing detailed project 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 projects, the solution is to plan them in an Agile way. Agile Project Roadmaps provide just enough planning, just in time; allowing you to plan projects 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 project that is not seriously troubled.

Most features aren’t used.

At the same time, Standish Group research on internal projects 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 product development projects.

Why this happens

Research and recent experience shows that most organisations are delivering digital projects 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 projects 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. 

Agile projects

“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 to pursue an initiative.

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 business 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 projects in a more Agile way.

Agile Project Roadmaps

Over the last few years, I have developed and refined an Agile Project Roadmap process that allows you to define, design and plan a project in weeks instead of months or years. In an Agile Project 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 project team starts, they evolve the project plan with business stakeholders to deliver the maximum business value possible within the time and budget available. 

Agile Project 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 Agile Project 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

Agile Project 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 projects 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 a Project Roadmap, you need to get funding and resources to do planning. In most cases, the Project 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 Agile Project Roadmap because the Roadmap creates a detailed business case for the project.

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

What are Agile Project Roadmaps?

An Agile Project 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. Project Roadmaps integrate product planning, UX design, technical architecture and project planning into a viable strategy to meet stakeholders expectations. Agile Project 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 Agile Project 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 project 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 Agile project roadmap is an alternative to the traditional staged project analysis, design and planning process that takes one-third of your project budget and half your project time. Agile Project Roadmaps replace Design Sprints, Project Inception, Business Case, Project Plan, Detailed Business Case, Business Requirements Phase, Solution Architecture Phase, UX Design Phase and 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.

Agile Project 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 Agile Project Roadmap defines the:

• Business Problem;
• Objectives and Key results;
• Customer Experience Roadmap;
• Solution Architecture Roadmap;
• Product roadmap prioritised by value, size and dependencies;
• Project risks and issues;
• Project 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 projects are shown below.

How do you develop an Agile roadmap?

An experienced team led by a skilled facilitator can create an Agile project 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 project 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 project 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 project plan with stakeholders

In my experience, an Agile Project 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 project yet, then you should bring together the people that you expect will be taking the project forward. 

I estimate that there are about 70 days of work in an Agile Project 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 business leader who is the Project 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.

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 project roadmap into a fixed scope, fixed-price contract for the delivery of everything defined in the Project 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 Project Roadmap, the sponsor can use it to request funding for product delivery. Or they may decide that the project is too expensive and they need to find a cheaper way to solve their problem.

An Agile Project Roadmap is not a one-time event that creates a fixed scope that must be delivered without change. A Project 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 Agile Project Roadmaps

You can use Agile Project 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 projects 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-project 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, project and budget roadmaps for the next six to 12 months. This team has a Product Owner, Project 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 Project Roadmap for new projects making sure to include the people who will deliver if it is approved.

Benefits 

Plan quicker, plan better.

Agile Project Roadmaps define an approach that a Product or Project Manager can use to quickly and effectively determine the product plan, solution architecture and project funding for a new project. 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 project 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 project yourself. 

Agile Project 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 project 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 Agile Project Roadmap. The Project Sponsor for a Knowledge Management project 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 Agile Project 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

Agile Project 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 thanks 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.