Goal-Orientation and Milestones are Key to Performance Management in Traditional and Agile Projects

Goals are “ideas of future, desired end states.”ⁱ   Goals can be broken down into smaller “sub” goals.  Those “sub” goals can be used to measure progress toward the parent goal.  Traditional projects are completed in phases which end in a milestone.  A milestone, by definition, is a significant event in a project.  They mark progress toward the main project goal.  As such, milestones must represent a change in the “state” of the project…more aligned with the end goal for the project.  Thus, each milestone needs to contain a “sub” goal which reflects the progress toward the end state desired. 

Having a goal is not enough.  There must be objective mechanisms for the project team to know that they have reached the goal.  It is helpful to have predefined evaluation criteria which describe the characteristics and conditions which should indicate goal achievement.  It is always more beneficial to have the evaluation criteria defined in advance of the beginning of the phase.  Predefining evaluation criteria tends to make evaluation of the milestone more objective.  When the evaluation criteria are not defined in advance, there is a tendency for project team members to define successful achievement of the goal by criteria which coincides with the results produced within the phase (whether they have made the desired progress or not). 

Additionally, the absence of documented, predefined evaluation criteria leads to a situation in which “Many viewpoints exist from many people. And they change over time. This dynamic can often be the Achilles heel for a project. Without a dependable understanding of what constitutes success, the project is placed in the untenable position of being judged against differing criteria. ”ⁱⁱ  Thus, in addition to the sub-goal, a successful milestone should contain clear, verifiable evaluation criteria so that all stakeholders have the same understanding/interpretation of milestone achievement.

Keep in mind that one of the primary purposes of a milestone is to predict when the entire body of work will be completed.  Typically, each milestone is associated with an estimated date for delivery.  The team doing the work hypothesizes that if the work for the milestone is completed by the milestone date, then the entire project will be delivered by the delivery date.  Conversely, if the milestone is not attained by the milestone date, the Team hypothesizes that the project will be delayed by at least the additional amount of time that it takes to reach the milestone past the milestone date.  Thus, the milestone needs to have a 3rd component in addition to the “sub” goal and evaluation criteria.  Milestones need a milestone date.

The three components of a milestone form a nice acronym that I like to call the GED (i.e., “G” for Goals, “E” for Evaluation Criteria, and “D” for the milestone date).  Every milestone needs to have the three components defined and agreed to by the stakeholders so that all parties involved with the project outcome can make the same analysis and have the same interpretation of the gap between the current state and the goal state.  This is the only way to gain general consensus on project decisions (especially corrective actions).  Using all 3 components of a milestone are important for providing the clarity necessary to predict the project end date.

In Agile Scrum projects, the milestone date is not necessary.  Each sprint is required to have a sprint goal.  There is an expectation that the evaluation criteria for each sprint is defined in advance, when defining the sprint goal.  In fact, the definition of “Transparency”, one of the three pillars of Scrum Theory, according to the 2017 version of the Scrum Guide, is:

“Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard, so observers share a common understanding of what is being seen.
For example
• A common language referring to the process must be shared by all participants; and,
• Those performing the work and those inspecting the resulting increment must share a common definition of “Done”.ⁱⁱⁱ  

Each sprint should, therefore, have predetermined evaluation criteria and “standards” for criteria to be used during inspection to know whether the goal was accomplished.  Given that each sprint has an equivalent, fixed length, there is an implied “date” associated with the attainment of each sprint. Each sprint possesses a goal (i.e., the sprint goal), evaluation criteria (i.e., transparency), and a delivery date (i.e., the date for the end of the sprint).  Every sprint in Scrum has a milestone; the milestone is represented by a sprint goal. 

Understanding how the nature of Scrum’s structure can help Teams to use sprints to predict the future completion dates like any project milestone.  When the Scrum Guide describes the sprint, it states “Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.”^iv  This indicates that Scrum is designed to have a Product Goal be decomposed into sub goals for each sprint.  Then the Team is responsible for “inspection” of the gap between the current state and the Product Goal.  Product Owners can use this information, along with estimates of future goal attainment, to predict project end dates.  Burnup charts are a simplified way to institute earned value management within an Agile Scrum project to predict end dates.

The project management community has long suggested the use of goals as an alternative to activity-based planning, which was proposed to have deficiencies.  “To make an optimal choice among the alternative activities in the latter part of the project, the outcomes of preceding activities have to be known. One consequence is that decisions taken without this knowledge result in less-than-optimal solutions.”^v  As a result, the Scrum Community has taken the approach of NOT defining activities in detail for future sprints.  However, we have done a poor job in defining sprint goals.  Most sprint goals that I observe with Scrum Teams focus on activities (indicated by a verb) instead of a goal state (indicated by adjectives describing a noun).  Given this lack of clarity on sprint goals, it is easy to see why there are so many instances of Scrum Projects that do not have accurate predictions of end dates. 

Goal-orientation is the key to making Scrum work as each sprint has a milestone.  Once this goal-orientation is recognized, Teams will be able to trace Sprint Goals to Product Goals to Strategic Goals within the organization.  This will aid the organization in their ability to predict performance in the future.  Goal-orientation is the key to agile Performance Management and paramount in successful project delivery.

References
i. Locke, Edwin. A & Latham, Gary P. A theory of goal setting and task performance, 1990 Prentice Hall, Englewood Cliffs, New Jersey 07632
ii. Project success--what are the criteria and whose opinion counts? (pmi.org)
iii. The Scrum Guide (scrumguides.org)
iv. Scrum Guide | Scrum Guides
v. Milestone planning--a different planning approach (pmi.org)

 About the Author
Brian Levy is the President of BridgePort Digital, an organizational optimization firm specializing in bridging the gap between strategic goals and strategic execution. While others in the industry have avoided metrics, Brian has been able to consistently improve productivity by over 30% within 3 to 6 months of operation verified with predefined metrics by aligning an organization’s performance management processes to the appropriate strategic approach.

Brian’s real joy is in putting his Scrum@Scale Trainer status to use in the classroom and training others in the techniques which lead to organizational optimization. That joy is most often utilized via training underrepresented minorities in careers related to software development and using his 10-year- old daughter to explain Management by Acceptance concepts.  Contact Brian directly at blevy@bpdsolutions.us.