The last couple of years have seen an increase in discussions within the IT and management accounting communities comparing traditional (waterfall) project management and agile project management. Since analytics projects are similar to software and IT projects, those working on analytics projects tend to prefer agile project management to the traditional method. This month, I’ll examine the main differences in the project methodology, providing an introduction to agile project management and explaining some of the main definitions associated with it. Then in August 2019 I’ll cover applications of the agile methodology and describe some case studies.
There are three main variables when managing any IT or analytics project: time, resources, and scope. In traditional project management, the scope is fixed while the resources and time needed are estimated. In agile project management, the resource and time components are fixed and the scope is estimated (see Figure 1).
A traditional project management model consists of a project manager and a team of specialists who work on the project. The project team begins by meeting with the customer (which could be another department, the team requesting the analytics project, or an external party) to collect project requirements, which are broken down into milestones. The project manager is tasked with keeping the customer posted with the status and completing the project.
This model is vulnerable to delays, miscalculations or unforeseen costs that can cause budget overruns, or overall failures to deliver on stated goals. And because the scope of the project is fixed in the traditional model, there’s also the potential for missing business changes that might affect the project.
AGILE PROJECT MANAGEMENT
Agile project management takes all these factors into account. The project owner and the customer would agree on a minimal viable product (MVP) using an iterative method based on the team’s—as well as the customer’s—understanding of what the customer actually needs. The process works through multiple iterations of product testing, and it saves time by making sure the work done throughout the project is aligned to what the customer needs as well as any business changes.
The time spent to complete the MVPs for each iteration is called a sprint. At the beginning of a sprint, the customer and project team discuss the MVP that’s going to be done during the sprint and then establish a plan to complete the work. During the sprint, the team carries out the plan. The length of a sprint could be two weeks, three weeks—whatever timeline is best suited to the project.
At the end of a sprint, the project team goes back to the customer to show the MVP and get feedback. Even if there’s no deliverable, the team meets with the customer to explain any delays or problems and to show the progress so far. With some sprints, you can even launch part of the project and go live after the review.
Here are some other important facets of agile project management:
- Scrums are regular team meetings to review progress of agile projects.
- Similar to a project manager, the scrum master oversees the development process and ensures everyone is on track and aligned to the planned sprint.
- A scrum of scrums is a meeting for when you have multiple teams working on projects and need to keep the wider team updated.
- The backlog is a list of tasks to be completed by the team.
- The product owner manages the backlog to ensure product delivery. He or she discusses which items on the backlog need to be done and the sequence in which to do them. This leader also reviews with stakeholders any critical changes in scope based on the backlog. Product owners sometimes are also compared to traditional project managers, but product owners are more focused on maximizing the value of the product as well as managing the backlog.
METHODOLOGY IN ACTION
Let’s see how to use an agile methodology in a real case. A customer describes some challenges with the current reporting used for pricing and would like better visualization to understand the relevant issues. The agreed-upon MVP in this case is a dashboard that helps report pricing. The team working on the project agrees with the customer to meet biweekly and review progress and MVPs based on expected sprint deliveries at the start. The project time is agreed to be three months, and the number of team members is set at five. The project owner creates a backlog listing the tasks needed, such as a tool used for visualization, preliminary key performance indicators (KPIs), and other reporting requirements.
The team starts working. Scrum meetings occur daily, with the scrum master ensuring everything is on track. At the end of sprint 1, the team meets with the customer to present and discuss preliminary KPIs and a basic dashboard that helps the customer view and understand the numbers.
While this helps the customer right away by providing some preliminary KPIs that can be reported, it’s just the beginning of the project. Sprint 2 involves refining not only the individual deliverables themselves but the ultimate goal of the project. At the end of the sprint, the customer reviews the additional KPIs suggested by the team and determines that more visibility regarding pricing and its optimization is needed. The team explains to the customer that a pricing optimization model with a report would accomplish that, which is completely different from just the KPI-tracking dashboard originally agreed upon.
Agreeing with the customer that the model is priority, the team works on sprint 3 and delivers variables that affect pricing as well as explain the different internal and external sources being used for information. The customer is happier now, and the project team is delivering what’s needed and not what the customer thought was needed.
The team reviews the scope and determines that the model can be delivered within the fixed three months but not the reporting. The customer agrees to the optimization model and asks for a reporting dashboard as another project once the team completes the model.
If the traditional method were used, the original product scope more likely would have been delivered, but the customer wouldn’t have been provided with the optimal product. Using the traditional method also may have led to scope creep, with more and more resources being added to make the project work while still not delivering what’s truly needed.
May 2019
