Milestone Planning: A Participatory and Visual Approach

Eduardo Miranda, PhD

Institute for Software Research – Carnegie Mellon University
mirandae @ andrew . cmu . edu
First published: November, 2018
Cite as: MIRANDA, E., Milestone Planning: A Participatory and Visual Approach. The
Journal of Modern Project Management, North America, 7, oct. 2019. Available at:
<https://www.journalmodernpm.com/index.php/jmpm/article/view/488>

Abstract
This paper introduces a participatory and visual approach to milestone planning called the
Visual Milestone Planning (VMP) Method. VMP promotes involvement and commitment,
through the reification of the planning artifacts and their direct manipulation by team
members who collectively create the plan. Once a project scope is defined via a work
breakdown structure and relevant milestones identified, a novel construct called the milestone
planning matrix is used to systematically and visually capture dependencies among
milestones and map WBS elements to the milestones they help realize. The milestones due
dates are later determined by accommodating sticky notes representing the work to be done
on a resource and time scaled milestone scheduling canvas. The method is applicable to
traditional as well as to agile projects.
Keywords
Milestone planning; participative planning; collaborative planning; milestone planning
matrix; visual planning; agile project management
1 Introduction
Milestone planning is a planning approach pioneered by Andersen (Andersen E. , 1996) and
Turner (Turner, 2004) in which projects are planned in terms of their outcomes, the
attainment of significant process states, external dates and customer commitments, instead of
on the basis of the tasks to be performed. Milestone plans are more robust, comprehensive,
easier to understand, and accept and confer great flexibility in terms of how to achieve the
milestones, which makes them a very apt tool to be combined with agile approaches.
According to both authors, milestone planning should be performed by the group, as “it is
important that a sense of community develops around the plan” (Andersen, Grude, & Haug,
2009) and “developing the plan in a group session builds greater commitment than if the
project manager develops it on his or her own and tries to impose it on the team” (Turner,
2004), but they do not offer a systematic method for how to do this. This paper address that
gap by proposing a participatory and visual approach to construct milestone plans called the
Visual Milestone Planning (VMP) Method.
While thinking and expressing a plan in terms of milestones rather than tasks certainly
contributes to the plan’s robustness, comprehensiveness, understandability and acceptability;
these three properties are mainly the result of the how the plan is constructed and who is
involved. Restating Turner’s words, a milestone plan developed in isolation by a project
manager and later communicated or simply handed down to those responsible for its
implementation, would not be as comprehensive, understandable and acceptable as one
developed with the participation of the team using visual techniques.
In the context of this paper, participatory planning, is a practice in which the people
responsible for the execution of the plan is actively involved in its formulation. Successful
examples of this way of working are numerous: the pull planning process in the “Last Planner
System” used in the construction industry (Ballard, 2000) and “Blitz Planning” (Cockburn,
2004) and “Cards on the Wall” (Phillips, 2001) on software development to cite a few. The
benefits of participation in the planning process are many: better and more comprehensive
plans as consequence of the involvement of a mixture of people which brings different
perspectives to the process, greater commitment as plans are talked through and advance the
thinking of the group, the development of a common framework and vocabulary for decision
making which extends well beyond the “high” of a successful planning session and an overall
higher probability of success as people that participates in the shaping of the plan better
understand the needs, the goals and where their responsibilities lay with regards of those of
others (Moss Kanter, 1989).
Visual planning is an approach by which a team plans its work and controls its progress
through the use of physical representations of tasks in combination with frequent and
interactive meetings. Visual planning provides cognitive, social and emotional benefits
(Eppler & Platts, 2009). The cognitive benefits of visual representations include facilitating
elicitation and synthesis of information, enabling new perspectives to allow better, more
exhaustive comparisons and facilitating easier recall and sequencing; the social benefits
include integrating different perspectives, assisting mutual understanding, and supporting
coordination between people; and the emotional ones include bolstering involvement and
engagement, providing inspiration, and aiding convincing communication. Visual planning
variants are being used in a number of different contexts, e.g., lean product development
(Lindlöf & Söderberg, 2011) and (Jurado, 2012) and construction projects (Tjell & Bosch-
Sijtsema, 2003) among others.
VMP implements participatory and visual planning techniques through the reification of the
planning constructs: work packages, milestones and schedules employed in the planning
process and their direct manipulation by team members who collectively create the plan.
While the article will provide a cursory explanation of all artifacts and techniques mentioned
in it in an effort to make it self-sufficient, the focus will be on the proposed method and the
novel constructs employed. We encourage the interested reader to consult the original
literature describing VMP’s constituent techniques. The rest of the paper is organized as
follows: Section 2 describes milestone plans, Section 3 explains the proposed method,
Section 4 provides a detailed example that illustrates the use of the method and serves as
validation, Sections 5, the linkage of milestone plans to planning waves and iterations in agile
projects and Section 6 an initial evaluation of the method.
2 Milestone plans
Andersen (Andersen E. , 1996) defines a milestone not “as the completion of an activity,
usually an especially important one” but as “a result to be achieved, a description of a
condition or a state that the project should reach by a certain point in time. A milestone
describes what is to be fulfilled, not the method to fulfil it”. Figure 1 shows a typical
milestone plan. As can be observed, a milestone plan is short, typically confined to a size
which will allow it to be grasped at once and written using a vocabulary a project sponsor can
understand. The plan comprises a sequence of states the project will go through, from its
inception to its successful conclusion, and not the activities the team needs to perform to
achieve those states. For example, the “Design concept approved” milestone, defines a state
where the project team has presented an idea that satisfies the needs of the sponsor and he has
acquiesced to it. The plan does not estipulate how the team will get there. Will they build
 Figure 1. A typical milestone plan showing due dates, responsibilities and milestones’ descriptions

wireframe diagrams? Develop high fidelity prototypes? Make a PowerPoint presentation?

Perform user testing? Employ focus groups? At some point, these issues will certainly have
to be addressed by the team, but they have no place in a milestone plan.
The focus on states rather than on activities results in a more robust plan since independent of
what tasks are performed to get there, when and by whom, the project sponsor would like to
approve the design concept before it is implemented and that is unlikely to change.
The dependencies between milestones are typically “Finish to Finish” relations, meaning that
if “Milestone B” depends on “Milestone A”, “Milestone B” cannot be completed until
“Milestone A” has been completed. Finish to Finish relations are easy to spot and provide
great freedom as to when the activities leading to the realization of the milestone could start.
Milestones could be hard or soft. Hard milestones are milestones, that if not accomplished by
a set date, lose all or most of its value or results in severe penalties. The date a government
resolution which the system under development is supposed to address goes into effect and
the start of the holidays shopping season are examples of hard milestones a project might
need to satisfy. Soft milestones on the other hand, have completion dates that result from the
planning process. They might be associated with penalties or other liabilities after a statement
of work is agreed, but in principle are discretionary.
3 The Visual Milestone Planning (VMP) Method
Figure 2 depicts the VMP Method. The first step in the process is to create an outcome
oriented work breakdown structure (WBS) defining the project scope. Each WBS element
will have associated with it the estimated effort required for its realization. These estimates
will be later used to establish windows of opportunity in which the anticipated work could be
performed. A project whose final outcome is not well defined could be scoped in terms of
learning activities such as running a design sprint and planning packages that have a definite
purpose and budget but whose exact content has not yet been decided.
 Figure 2 Participatory approach to milestone planning

The second step in the process is the definition of milestones. Milestones are chosen to signal
the taking of a major decision, the delivery of key components or assemblies, the completion
of important process steps or to mark a commitment made to the team, e.g. a customer makes
proprietary equipment or technology required by the project available to it. Notice that in the
diagram there are arrows back and forth between steps 1 and 2. This is so because although
the WBS will normally inform the choice of milestones, sometimes the selection of a
particular milestone might result in the creation of a new task or outcome that must be
incorporated in the WBS or leads to its rearrangement.
In Step 3, the identified milestones are first written down from left to right as column labels
in the header row of the milestone planning matrix, ordered according to a logical sequence
of completion. Beware that in the presence of multiple paths through the project this
sequence might not be unique. Finish-to-finish non-redundant pairwise dependencies between
milestones are captured by placing a dot at the intersection of the diagonals corresponding to
the related milestones in the roof section of the planning matrix. The roof of the matrix could
then be used to unravel the list into a milestone diagram, Step 5, which communicates the
milestone sequence in an easier to read format for the team to validate.
In step 4, the WBS elements are associated to the milestones they help realize via the body of
the milestone planning matrix. The association is done by labelling a row in the planning
matrix with the name of the top most WBS element whose descendants all contribute to the
same milestone, and recording the effort required by it at the intersection of the said row and
the column corresponding to the milestone with which the element is associated. A milestone
can have multiple WBS elements associated with it, i.e. several WBS elements must be
completed to realize the milestone. In most cases a WBS element would be associated with a
single milestone, there are however a few instances, which will be discussed later, in which is
convenient to allocate fractions of the total effort required by the WBS item to multiple
milestones. The set of WBS elements associated with a milestone is called its work package.
In Step 6 we mark hard milestones in the scheduling canvas and black out non-working dates
such as holidays or known vacation periods. Hard milestones will act as anchor points for the
plan.
In steps 7, 8 & 9 we build the project’s staffing curve by posting sticky notes on an empty
space in the milestone scheduling canvas such as all effort required by a milestone’s work
package could be fitted to the left of it while respecting the milestones’ order. As will be
explained later, sticky notes reify the effort required by a work package. Each sticky note
would correspond to a fixed number of person-hours of work with the horizontal edge of the
note corresponding to a unit of time commensurate with the size of the project, e.g. week or
month and the vertical edge corresponding to one full time equivalent resource. The physical
dimensions of the sticky notes must match the scale of the milestone scheduling canvas axes.
Sticky notes cannot overlap as this would imply that a resource would be performing two
tasks at the same time. The position of a work package’s rightmost sticky note on the canvas
indicates the earliest date by which the corresponding milestone could be completed. If
somehow the plan is not feasible, e.g. there are not enough resources or the hard milestones
dates cannot be met, the project scope should be renegotiated, the work approach
reformulated or the constraints lifted.
In Step 10, we complete the plan by reading the due dates for all milestones from the
milestone scheduling canvas, assigning responsibility for their realization and properly
formatting them.
3.1 The outcome oriented work breakdown structure
An outcome oriented work breakdown structure (WBS), see Figure 3, also known as
deliverable or product oriented WBS, is a hierarchical representation of all the work a project
needs to do constructed using the project’s results as main decomposition criteria.
The importance of accurately identifying the scope of work in a project cannot be overstated.
Accurately does not mean we need to know every last detail at the beginning of the project.
Accurately means that if there are things we think we ought to know, but at present we don’t,
we acknowledge them and make provisions to learn and perform the work with the
understanding, that if things exceed our allocations, the plan will need to be revisited.
We prefer to call this type of WBS outcome and not deliverable or product oriented to force
teams to think that a project could be expected to produce results that are not products, for
example a project might be about organizational change, that is after the project is
successfully concluded the organization performs at a new, higher level. We find useful
thinking in terms of four types of outcomes a project might be expect to deliver: products,
services, processes and capabilities. From the point of view of the WBS construction, all
outcomes are treated the same.
An outcome oriented WBS will contain the expected project results and the activities
necessary to realize them (National Aeronautics and Space Administration, 2007). The first
level of the hierarchy defines a set of outcomes and activities that collectively and exclusively
represent 100% of the project scope. Outcomes might be broken down into lower level
outcomes and activities or tasks. Activities can only have other activities and tasks as
descendants. Tasks are not decomposable. The convention used in building the WBS, is that
integrative and common activities support all the WBS elements with the same ancestor and
that, whenever and activity or task applies only to one element it should be subordinated to it.
Correctly positioning activities and tasks is critical to establishing the true effort/cost of
producing a given WBS element. This is important because this information will be used to
support scoping, staffing and scheduling decisions. For example, if an architectural activity
supports the whole project it should be positioned at level 2 of the WBS, however if the
system under planning is made up of a number of subsystems which could be implemented or
not depending on the available funding or some other factor, each of them including
significant architectural work we will include the subsystem’s architectural activities under
each of them, so in case a decision not to implement a subsystem is made, removing the
subsystem from the WBS will also remove all the direct costs associated with it without
affecting other parts of the WBS.
The Practice Standard for Work Breakdown Structures (Project Management Institute, 2006)
defines two types of activities:
 Discrete Effort. Work effort that is separate, distinct, and related to the completion of
specific work breakdown structure components and deliverables, and that can be
directly planned and measured.
 Level of Effort (LOE). Support-type activity (e.g., seller or customer liaison, project
cost accounting, project management, etc.), which does not produce definitive end
products. It is generally characterized by a uniform rate of work performance over a
period of time determined by the activities supported.
The distinction is important, because as will be explained later, it affects the way in which
WBS elements are mapped to milestones.
Consistent with the idea of deferring the elaboration of the specific tasks to be performed to a
later stage, a WBS to support milestone planning only requires decomposition of its elements
for the purpose of:
 Making clear the scope of the project, e.g. what is the project expected to deliver
 Estimating the effort required by the project or a WBS while avoiding gaps and
double counting for lack of specificity, i.e. avoid vague activities such as “develop”
that do not communicate what is included or excluded from an estimate
 Supporting scoping, major scheduling and allocation decisions, e.g. we can do this but
not that, we can do this now and that later, or we can do this and outsource that
 Help isolate riskier elements, e.g. elements that somehow should be treated differently
 Have to be separated for administrative or compliance reasons, e.g. CAPEX vs.
OPEX, industrial benefits, etc.
 Figure 3 WBS example (Adapted from NASA’s System Engineering Handbook, 2007)

3.2 The milestone list

Correctly identifying the set of milestones to include in the plan is essential to its acceptance
as these would become the vocabulary that will be utilized to explain the work logic to the
project sponsors and other team members as well as to gauge its progress. A good milestone
set will include, as a minimum, the things the sponsors care about. For example, in a software
development project, if the project sponsor wanted to have a review of the user interface
before moving forward with the rest of the of the software, it would make sense the milestone
set include a “UI Approved” milestone.
A milestone describes an event that needs to occur not later than a certain date at risk of
delaying other milestones or the whole project. Typically, milestones will fall in one of three
categories: the realization of an outcome, the attainment of a relevant project state or the
satisfaction of a commitment made to the project team by an external party. The first two
types of milestones are achieved upon the completion of all work items included in its work
package. In the case of a commitment to the team, the milestone is achieved when the party
responsible for it fulfils its obligation. These last milestones tend not to have a work package
associated with it and are an excellent instrument to synchronize work across multiple teams,
each working according to their own plan.
The following are examples of the different types of milestones:
 Outcomes: a document, a partial or total system capability, a prototype, the results of
a survey
 Desired states: a major decision, an approval, an attainment of some kind, e.g. number
of transactions per second, number of users trained
 Satisfaction of commitment: delivery of proprietary equipment necessary to test the
software under development a special hardware is delivered to the project team,
publication of an API specification by another team
The criteria by which to judge the realization of a milestone is known by different names in
different contexts: exit criteria, definition of done and conditions of satisfaction but they are
all about the same thing: having an objective test to determine whether the milestone has
been reached or not.
Typically, a completion criterion would include the list of work items to be finished, a
description of its state and, if applicable a quantity of items to be delivered, demonstrated
performance such as transactions per second or power efficiency, and a definition about the
quality those things need exhibit at, e.g. defects counts, tolerances, weight limits, power
consumption levels, level of coverage, etc.
Many times writing the completion criteria will bring up or force the breaking down or the
re-estimation of activities already on the WBS. This is a good thing because the early
identification of these gaps helps prevent problems later in the project. Working on the
definition of done also helps the team develop a shared understanding of the work to be
performed.
The number of milestones chosen must balance visibility with robustness and ease of
understanding. Depending on the size of the project 10 to 50 milestones will satisfy the needs
of most small to midsize projects. Given the visual nature of the method every effort should
be made to confine the plan to a size which allows to have it in sight at once.
Once the milestones have been identified, the team will order them in the approximate
sequence in which they must be completed.
3.3 Milestone planning matrix
The Milestone Planning Matrix (MPM), see Figure 4, resembles the matrix known as the
“House of Quality” in the Quality Function Deployment method (Hauser & Clausing, 1988).
Strictly speaking, the MPM is made up of two matrices: A triangular matrix1, the roof of the
house, which captures finish to finish dependencies among milestones and the body of the
house, which is a multiple domain matrix (Maurer, 2007) (Browning, 2016), mapping work
items in the WBS to the milestones they help realize. The beauty of the approach is that the
construct provides a straightforward mechanism to make visible these relations to everybody
involved in the planning process. Visibility is the key to prevent gaps and overlaps in the plan
and in the development of a shared understanding by stakeholders.

1
We propose the use of a triangular matrix because it provides a nice, compact and directly manipulable
representation but other representations are possible if the triangular representation gets to complex. The author
has experimented with Design Structure Matrices (DSM) and directly creating the Milestone Sequence Diagram
Most of the time, work elements will map naturally and on its entirety to a single milestone,
but in practice the author has found some situations in which this is not the case. Two of the
most common are level of effort activities and outcomes involving a preliminary and a final
delivery. Of course, it is always possible to breakdown the “offending” element into as many
WBS elements as milestones it maps to and associate each of them with the corresponding
milestone, but this could be seen as something artificial that unnecessarily complicates the
WBS just to satisfy the choice of notation.

Figure 4 The Milestone Planning Matrix

For the level of effort activities, we employ two tactics: When dealing with an activity such
as integration in which the level of effort task could concurs to the realization of multiple
milestones, we allocate a weighted fraction of its effort to each milestone to which it
contributes. In the case of activities such as project management and quality assurance whose
effort contributes to all milestones we do not allocate hours to any milestones and treat this
effort as a work package that extends across the length of the project.
For outcomes that have a preliminary and a final delivery, e.g. the delivery of a draft
document followed by a review and some later work to obtain final approval, and for which
is important to highlight both events, we do one of two things: allocate a fraction of the WBS
element’s budget to each milestone like we do for the level of effort tasks, or assign all the
hours of the work package to the last milestone in a given milestone chain and discretionarily
position the precursor milestone on the staffing curve.
3.4 Milestone scheduling canvas
Figure 5 below shows a typical milestone scheduling canvas. The canvas is a key piece of the
process since it is there, that the plan materializes. Since the planning involves the physical
positioning of sticky notes on the canvas, there has to be a correspondence between the work
hours represented by each note and the canvas’ physical dimensions. If for example, we
choose a 3”x 3” sticky note to represent 40 hours of work, each three inches on the time axis
of the canvas will correspond to a week and three inches in the resources axis will correspond
to a full time equivalent (FTE) resource. Had we chose a lower granularity, e.g. a sticky note
to represent 150 hours of work, which would be useful in the case of a larger project, each
three inches on the time axis would correspond to a month instead of a week. One could rip
off sticky notes to express fractions of effort or time but this should be hardly necessary given
the resolution of the plan.
In constructing the staffing curve, we will assume the distribution of competences in the plan
matches each work package needs. If one wanted to know or was somehow limited by the
resource availability, it would be possible to break the work into competency lanes and assign
the corresponding effort to each lane. The same approach could be applied when working
with multiple teams.
The distribution of the sticky notes corresponding to a given work package on the scheduling
canvas will delineate an imaginary time box for the associated milestone. Time boxes must
exhibit the following properties: 1) they are totally located to the left of the corresponding
milestone, 2) there are not overlapping sticky notes, 3) their time box contour reflects the
nature of the work required, e.g. front loaded, back loaded, flat, early peaked, late peaked,
etc. and 4) their height at any point does not surpass the amount of resources available that
could reasonably be applied to the execution of the work package.

Figure 5 The Milestone Scheduling Canvas

After blacking-out any known non-working periods involving the whole team such as
holidays, closings, and special vacation periods, the process of populating the milestone
scheduling canvas will start by accommodating the work required by the level of effort
activities such as project management and quality assurance that stretch over the length of the
project or phase at defined manning levels. The next step would depend on whether or not the
project contains hard milestones. If it does, we first post the work corresponding to them and
after we move backwards to the start of the project (back casting) accommodating the work
packages corresponding to the soft milestones in the order imposed by their dependencies. If
there are no hard dates, the easiest way to proceed is to accommodate the work packages
from left to right, starting at the beginning of the project and moving forward to the end along
the most logical path. Sometimes the team might feel the need to introduce schedule buffers,
which are not covered here for reason of space, to protect important milestones. Once all
milestones have been layout, the due date for each milestone could be found by reading the
corresponding dates in the horizontal axis of the scheduling canvas.
4 Detailed example
This section is organized around the method’s steps shown in Figure 2 and serves two
purposes: illustrate the application of the method, and validate it through its use in a made-up
but not unreal project.
Imagine your company is bidding in a contract to develop an ecommerce site for a small book
publisher and after some discussion with your customer you sketched the following notes:
a. The customer wants to include a beta testing period to validate the site design.
b. He will not accept deployment until a system wide acceptance test is satisfactorily
completed.
c. Customer sign-off will follow satisfactory deployment of the system.
d. He would like to have at least three software releases: one to collect users’ feedback via
beta testing, another one to confirm the progress of the system towards the launch date
and the final one to complete the system with minimum risk to the launch date.
e. In the first release he would like to include the following functionality: Category List
(CL), Book Details (BD), Add to Cart (AC), Check-Out (CO) and all Data Base
f. In the second, the Category Book List (CBL), Remove from Cart (RC), Shipping Method
(SM).
g. In the final release: Payment Details (PD), Process Payment (PP)
h. The customer is preparing to launch its business in April of next year so he would like the
system to be ready at least one month before that.
For its part, your company:
i. Cannot start the project until the end of September and has only three developers and a
project manager available to work on the project.
j. To minimize the risk of rework, it does not plan to start programming until the
infrastructure is selected and the user interface and information architecture design are
well underway.
4.1 Step 1
Based on the requirements above and its professional knowledge the development team
created the WBS shown in Figure 6 describing their understanding of the contract’s scope of
work and estimated the effort required for its execution. The required software capabilities
were grouped into four categories: Browsing, Buying, Paying and Data Base to increase the
readability of the WBS as the team felt a grouping based on Releases would have difficulted
the comprehension of system functionality. Website design, beta and acceptance testing could
have been made part of the Website Software deliverable but the team chose to put them at
the first level of the WBS to highlight its understanding of the customer wishes.
4.2 Step 2
After obtaining concurrence for the WBS from the client, the team started choosing relevant
milestones and produced the list in Table 1. Beware that the solution is not unequivocal.
While there are self-evident milestones like project kick-off, software releases and the client
request for a beta test, others are created by the team based on its best judgment as to what is
important and what is not. The completion criteria associated with each milestone defines its
meaning and helps identify which WBS elements should be mapped onto them. The
milestones are organized in what seems like the most logical sequence to make the list easier
to understand and search for.

Figure 6 WBS fot the AmazonLight Project

4.3 Steps 3 &4

During step 3, the dependencies between milestones are defined and documented in the roof
section of the milestone planning matrix and during step 4, the WBS elements are associated
with their corresponding milestones. This is a pretty mechanical process whose value resides
on the visibility it brings to the planning process. As discussed above, a WBS element can be
associated with more than one milestone as shown by element 1.a in Figure 7. While this
technique relieves us from creating WBS elements just for the sake of having each element
map to a single milestone, abusing it obscures the mapping. Milestone “Cloud Infrastructure
Available” has no WBS element associated with it, because although the work to select the
infrastructure is part of the scope of the project, the effort to provision it, is not. The reason to
include it as a milestone is that it represents a commitment made to the project team by the
customer so they could beta test the system and to signal that a delay in fulfilling this promise
could affect its completion date. Elements 1.c.5 and 1.g in in Figure 7 are level of effort tasks.
In the case of “Integration & Feedback” a certain number of hours were allocated to each of
the three milestones representing the completion of the software increment according to the
amount of functionality to be integrated. In the case of project management, the effort was
not allocated to any milestone to be later spread over the life-span of the project according to
a uniform profile.
4.4 Step 5
This step corresponds to the drawing of the Milestone Sequence Chart and is not included
here for reasons of space.
4.5 Step 6
By definition, a successful plan must satisfy its hard milestones. So in the case the project had
contained such milestones, we would had started by marking them on the canvas as they
would have constrained how the work packages' effort could have been distributed.
4.6 Steps 7, 8 & 9
The goal of these steps is to establish a time frame in which the work represented by each
work package could be executed. To do this, the team will label or somehow mark as many
sticky notes as needed to cover the effort required by each work package and accommodate
them in an appropriate empty space on the milestone scheduling canvass. The team starts by
accommodating the effort corresponding to all cross-cutting work packages, then that
corresponding to the work packages connected to hard milestones and finally that
corresponding to the rest of the work packages in the order dictated by the milestones’
dependencies. If necessary, the team might intersperse buffers to protect milestones deemed
critical.
Figure 8 shows a possible plan for the AmazonLight project. Notice that due to the holiday
period, extending from late December to early January the effort for the Release 1 work
package was spread over two months by splitting the sticky notes. Another interesting case is
beta testing, where the effort distribution for the work package follows a double hump
pattern, some initial work for part of the team members at the beginning of the testing,
followed by a lighter period while the users exercise the system, followed by an intense
period to analyze the data and dispose of any findings.
As shown by the figure, with the constraints put on the available resources – three developers
and a project manager – it is unlikely that the system could be deployed by early April as the
customer wanted. At this point the team could ask for additional resources, reorganize the
work, e.g. relax the condition of not doing development work before the design concept has
been approved, negotiate the scope, change the completion deadline or just take its chances.
 Table 1 Potential milestones for the AmazonLight project

Rationale
(from notes Hard
Milestone above) date Completion criteria
Project kick-off i October Development team assembled, meeting with
this year project sponsor concluded
Design concept j Information architecture and UI designed
approved and approved by sponsor
Infrastructure j Cloud provider selected. Consider AWS,
selected Azure, Google Cloud and 2 others
Design Proposed Feedback from sponsor incorporated into
completed by team design
Cloud Proposed Cloud production environment available
infrastructure by team
available
Release 1: CL, d Indicated functionality is ready and tested at
BD, AC, CO, 90% coverage and working in production
Data Base configuration. No broken menus or links
Beta testing a Release 1 software made available to beta
launched users. User behavior hypotheses defined.
Website instrumentation working
Release 2: CBL, e Indicated functionality is ready and tested at
RC, SM 90% coverage and working in production
configuration
Beta testing a All insights arising from the beta testing
results reviewed disposed
Release 3: PD, f Indicated functionality is ready and tested at
PP 90% coverage and working in production
configuration. Changes resulting from beta
testing implemented
Acceptance b Acceptance test suite approved by sponsor.
testing procedure Includes at least one positive, one negative
approved and one invalid test case for each
functionality
Acceptance test b All acceptance test passed with no objection
completed from sponsor
System deployed c May All functionality running in production
next environment, operators trained. System must
year run for at least 15 consecutive days without
a fault attributable to software
Customer sign- c Customer accepts ownership of the software
off
Project closed Project postmortem executed, all records
archived
Figure 7 Milestone planning matrix for the AmazonLight project
 Figure 8 Staffing curve showing the chosen milestones for the AmazonLight project

4.7 Step 10
In Step 10, the milestone plan is completed by reading from the milestone scheduling canvas
the approximated date in which the work associated with each milestone will be completed
and assigning it as the due date for the milestone.
5 From milestones to tasks
A milestone plan is not directly “executable’ as it does not prescribe the tasks to be carried
out. Its purpose is to serve as basis for making rational commitments, provide an organizing
principle for the project and goalposts for synchronization across the many actors that could
be involved in the project. To make the plan executable, the project team will progressively
refine each milestone’s work package content into the tasks necessary to complete it within
the time and resource frames established by the work package’s time box. As work
progresses, the milestone plan could be updated to reflect new circumstances arising from the
work completed or from changes in the project context, but since milestones are basically
states or goals to be attained, the plan tends to be pretty robust.
Depending on the project context, e.g. traditional, hybrid or agile these planning sessions take
different names, e.g. planning waves (Githens, 2007) (Project Management Institute, 2017),
iteration planning meetings (Wells, 2019), sprint planning meetings (Rubin, 2013) and look
ahead planning (LCI - Israel Chapter, 2019) among others.
Typically, these sessions will include a review of the current state and vision, a determination
of the team capacity over the planning horizon considered, a selection of the work to be
tackled as informed by the milestone plan, a decomposition of this work into tasks and if
necessary, an instruction to update the milestone plan. The planning session might include a
task allocation step depending on whether the team follows a push or pull model for task
assignment.
In a rolling wave planning context, the planning sessions could be made to coincide with the
achievement of a relevant milestone or at discretionary times over the life of the project, see
Figure 9, but in a Scrum context they are scheduled at regular intervals, see Figure 10,
coincident with the length of iteration chosen.

Figure 9 The rolling wave planning approach

Figure 10 The iteration planning approach

6 Initial evaluation
An initial evaluation of the method, from the process perspective, was performed through an
independent assessment of its usability (Fontdevila, Genero, & Oliveros, 2017) and by
surveying a small number of graduate students using the method in their capstone projects.
The first evaluation aimed to assess the method’s learnability, understandability, visibility,
adaptability, controllability and attractiveness through its description and the second, the
claims of comprehensiveness, understandability and acceptability, through the actual
experience of using it. Tables 2 and 3 respectively summarize the results of the evaluations.
Although a single assessment and the results of a small survey, 10 students were asked to
complete the survey but only 6 responded, in an academic environment might raise concerns
with regards to the generalization of any conclusion, both attest to the merits of the method in
terms of its ease of use and the promotion of collaboration and buy-in.

Table 2 VMP Usability Evaluation

Characteristic

Assessed
measured

value
(Possible
Metric Definition values) Comment
Appropriateness Measures how Appropriate The name describes the
of name appropriate the (Deceiving, essential aspects of the
name is for Ambiguous, method, that is is visual (and
describing the Partial, reified) and that it is milestone
purpose of the based and that its purpose is
Self-evident purpose

Appropriate,
process or practice. Accurate) planning
Purpose Measures the Complete The method is a team level
alignment for alignment of (None, Low, planning method, and uses
stakeholders purpose for all Medium, visibility to enhance "shared
stakeholders. High, understanding by
Complete) stakeholders"
Volume of Measures the size 6500 The word count for
information of of introductory (Number of "Milestone Planning: A
introductory material as defined words) Participatory and Visual
material by authoritative Approach"
sources, e.g. for an
authoritative
introductory
course.
Standard Measures standard 8hs Informed by the author
Learnability

introductory course duration in (Number of [Miranda]

course duration hours, as defined hours)
by authoritative
sources.
# of elements Measures how 15 Outcomes, Milestones,
many components (Number of Dependencies, Milestone
make up the elements) Planning Matrix, MIlestone
definition of the Sequence Diagram, Milestone
process or practice. Effort, Cross- cutting Effort,
Understandability

Milestone Dates, Soft

Milestone, Hard Milestone,
WBS. Milestone work
package, Effort unit of time,
Milestone scheduling canvas,
Milestone list
 Conceptual Measures the level High It is a participatory planning
model of correspondence (Low, activity, were the team is
correspondence between the user’s Medium, responsible for carrying out
conceptual model High) the plan. The meaning of
of an activity and milestones and due dates is
the conceptual fairly straight forward, aa is
model of that same the rest of the conceptual
activity that the model.
process or practice
implies.
Data model Measures the Medium In general the data model has
complexity subjective (Low, low complexity, but specific
index complexity of the Medium, elements like the pair-wise
data model. High) dependency matrix "roof", the
existence of two types of
milestones and two types of
effort makes the overall data
model less simple.
Cost of error Measures the cost Low The focus on milestone
of error as overall (Low, planning makes plans "much
impact. Medium, more stable and practical"
High) than task or activity oriented
plans [Miranda]. The cost of
modifying milestones is lower
than that of modifying tasks.
Making the plan and its
elements visual also make it
easier to detect issues and
gauge the impact of
modifications.
Safety Measures how safe High The team participates in
perception is it to use the (Low, planning its own work. That
process or practice. Medium, provides a safer environment
High) for establishing commitments
since they are not imposed
from the outside. Depending
on the culture of the
organization around the team,
and the level of autonomy that
the team has in planning and
executing the plan, the cost of
error may vary.
Use of Measures whether Yes The scheduling canvas scale
restraining the process or (Yes, No) to the sticky notes size offers
Error tolerance

functions practice provides visible hard restrictions on

hard restrictions to milestone planning to avoid
prevent risk resource over allocation and
materialization. help validate milestone
viability
 # of indicators # of indicators N/A Progress is reflected in the
(# of degree of completion of the
indicators) items being produced. No
additional indicators
Use of Use of information Yes Scheduling canvas, Milestone
information radiators (Yes, No) Planning Matrix
radiators
Audience Audience alignment Yes There is no specific mention
Visibility

alignment for for information (Yes, No) of information tailoring

information
Degree of Degree of control N/A The method does not define
control concentration by role roles nor state how are made
concentration by decisions among different
role stakeholders
Level of Level of autonomy Medium Teams have a say and are
autonomy (Low, involved, not necessarily
Medium, self-organized
High)
Controllability

Control Control granularity Fine WBS items and work

granularity (Fine, packages can be arbitrarily
Medium, decomposed
Coarse)
# of adaptation # of adaptation 1 Milestone sequence diagram
points points (# of points) is optional
Attractiveness Adaptability

Ratio of roles Ratio of roles N/A No roles defined

allowed to adapt allowed to adapt (0 to 1)

User User attractiveness 4 Assessor opinion after reading

attractiveness rating (1 to 5) the paper
rating

User experience User experience No rated The author reports anecdotal

rating rating (1 to 5) "positive initial responses
encountered" in both
User satisfaction

classroom and industry

settings. A more precise
measurement of satisfaction
might provide interesting
insights
 Table 3 VMP Comprehensiveness, understandability and acceptability survey results

Totally Somehow Somehow Totally

Comments
disagree disagree agree agree
The method allowed you to
have a say in the planning 1/6 5/6
process
After finishing the plan,
you felt you understood
why it was constructed the
3/6 3/6
way it was, even if you
might not totally agree
with it
You would feel
comfortable explaining the
3/6 3/6
plan to others outside the
planning team
The visual nature of the
method helped the team
1/6 2/6 3/6
find elements it might
have overlooked
The visual nature of the
method helped you
communicate your ideas to 3/6 3/6
other members of the
planning team
The visual nature of the One response had
method prevented you to be eliminated
4/6 1/6
from making mistakes because the student
marked all columns
You liked the method
1/6 3/6 2/6
before you started planning
Overall it was a pleasant
2/6 4/6
experience

7 Summary
Any project of any size or consequence needs an organizing principle that is understood and
shared by all members of the project team. Without it, project members struggle to know
what to do next and stakeholders with what to expect and when. While it has long been
established that a milestone plan can effectively fulfills this guiding role, its collaborative
construction as proposed here reinforces the well-known benefits of team members'
engagement, buy-in and ownership. The VMP method has evolved over three years of
classroom and consulting experience and has been put into practice in mid-sized capstone
projects, 2,500 to 5,000 person-hours long, and at two industrial organizations. Although
further experience and assessments are required, its initial evaluation and observations point
in the direction of the method’s ease of use and its value in organizing a project.
8 Bibliography
Andersen, E. (1996). Warning: activity planning is hazardous to your project's health!
International Journal of Project Management, 89 - 94.
Andersen, E., Grude, K., & Haug, T. (2009). Goal Directed Project Management, 4th.
London: Kogan Page.
Ballard, H. (2000). The Last Planner System of Production Control (Disertation).
Birmingham: University of Birmingham.
Browning, T. (2016). Design Structure Matrix Extensions and Innovations: A Survey and
New Opportunities. IEEE Transactions on Engineering Management, 63(1), 27 - 52.
Cockburn, A. (2004). Crystal Clear A Human-Powered Methodology For Small Teams.
Upper Saddle River: Addison Wesley.
Eppler, M., & Platts, K. (2009). Visual Strategizing: The Systematic Use of Visualization in
the Strategic-Planning Process. Long Range Planning, 42 - 74.
Fontdevila, D., G. M., & Oliveros, A. (2017). Towards A Usability Model for Software
Development Process and Practice. In M. Felderer, D. Méndez Fernández, B. Turhan, S.
Kalinowski, F. Sarro, & (eds), Product-Focused Software Process Improvement. PROFES
2017 (pp. 137 - 145). Innsbruck: Springer.
Githens, G. (2007). Using a Rolling Wave for Fast and Flexible Development. In A. Griffin,
& S. Somermeyer, The PDMA ToolBook 3 for New Product Development (pp. 397 - 415).
Hoboken: John Wiley & Sons.
Hauser, J., & Clausing, D. (1988). The House of Quality. Harvard Business Review(May -
June).
Jurado, M. (2012). Visual Planning in Lean Product Development. Stockholm: KTH Royal
Institute of Technology.
LCI - Israel Chapter. (2019, 3 1). Last Planner System: Business Process Standard and
Guidelines. Retrieved from Lean Construction Institute:
https://www.leanconstruction.org/media/docs/chapterpdf/israel/Last_Planner_System_Busine
ss_Process_Standard_and_Guidelines.pdf
Lindlöf, L., & Söderberg, B. (2011). Pros and cons of lean visual planning: experiences from
four product development organisations. International Journal of Technology Intelligence
and Planning, 269 - 279.
Maurer, M. (2007). Structural awareness in complex product design. Munich: Tech. Univ.
Munchen.
Moss Kanter, R. (1989). Foreword. In L. Spencer, Winning through Participation.
Kendall/Hunt Publishing Company.
National Aeronautics and Space Administration. (2007). NASA Systems Engineering
Handbook. Washington: National Aeronautics and Space Administration.
Phillips, D. (2001, 3 1). Cards-on-the-Wall Sessions. Retrieved from Dr. Dobbs:
http://www.drdobbs.com/cards-on-the-wall-sessions/184414750
Project Management Institute. (2006). Practice Standard for Work Breakdown Structures.
Newtown Square: Project Management Institute.
Project Management Institute. (2017). A guide to the project management body of knowledge
(PMBOK guide). Newtown Square: PMI.
Rubin, K. (2013). Essential Scrum A Practical Guide to the Most Popular Agile Process.
Upper Saddle River: Addison-Wesley.
Tjell, J., & Bosch-Sijtsema, P. (2003). Visual management in mid-sized construction design
projects. 8th Nordic Conference on Construction Economics and Organization (pp. 193 –
200). Tampere: Fannie Mae Foundation.
Turner, R. (2004). Managing Web Projects. Aldershot: Gower.
Wells, D. (2019, 3 1). Iteration Planning. Retrieved from Extreme Programming: A gentle
introduction : http://www.extremeprogramming.org/rules/iterationplanning.html