As global markets continue to expand at a rapid pace, we're witnessing a tenuous combination of low employment and increased spending in IT. As a result, many enterprises are tasked with maintaining adequate resources to fulfill IT initiatives and business needs.
According to Gartner, worldwide IT spending is projected to reach $3.7 trillion by the end of this year, an increase of 6.2 percent from 2017. But despite generous IT budgets, more than a third of all IT projects are still likely to fail if management can’t put the right people on the right projects at the right time. Inadequate resources can result in a shortage of tech support professionals during a new product launch, a lack of programmers needed for a major software refresh, or a shortage of experts in specialized fields like data analytics or business continuity.
It's reported that 85 percent of organizations struggle to sufficiently forecast capacity and available talent far enough in advance to leave time for necessary adjustments. This problem is why IT organizations are prioritizing the hiring of qualified resource managers and processes to improve the way time, costs and product quality measures are handled.
Resource Management Supporting Agile vs. Waterfall Approaches
Most IT professionals will approach resource management processes from two angles, depending on the project management methodology of their choice: waterfall or agile processes for project execution and program development. Both of these methods brings with them specific benefits and tradeoffs, and require different approaches to resource management. This article focuses on agile methodologies, which are gaining momentum industry-wide.
One key difference between the two approaches is waterfall methods require a continuous cycle of pre-planned activity leading up to the final outcome. Agile methods instead involve a series of smaller iterative completed steps leading up to the end. Therefore, resource planning for an agile environment must consider these key differences:
- Agile shifts the focus from the project to the "product," or the outcome of the effort, not the execution of the project plan itself.
- Work is broken down in smaller increments (sometimes called sprints) leading up to a finished "product."
- Resources are assigned to iterations (or sprints) rather than entire projects, and may be assigned to multiple sprints at the same time.
- Shorter planning cycles minimize the amount of up front planning and therefore require more resource flexibility.
- Because of the short duration, reduced planning and higher volume of sprints, project teams generally have less visibility into the details of a particular sprint.
In summary the agile methodology employs less rigorous planning, leading to less visibility and predictability to staff allocation and productivity. But good resource management fundamentals still apply and should be adhered to here, in what is a more challenging environment for resource planning and allocation.
Applying Supply and Demand Principles
Agile resource management requires a slightly different approach to understanding resource supply and demand, especially when it comes to how teams are organized and how resources are leveraged to create project teams.
The demand side is always the hardest aspect to solve given the reduced planning effort involved with agile. Also, organizations struggle to plan for unfunded or unapproved work, causing teams to be more reactive than proactive in staffing projects.
The best way to know your supply is to develop a resource management plan within the constructs of agile project methodology. This means having a normalized and manageable set of roles, a functioning and well-maintained skills database and alignment and mapping to resource management processes.
Sometimes resource managers lose sight of actual resources for projects that are less structured because team managers maintain tighter control over how to use their resources. This frequently results in violating a key resource management principle that dictates the transparency of resources to other potential users in the enterprise. Therefore, it is important to retain some way of tracking use of allocated resources using some common definition of supply allocation.
Defining the demand side can be more difficult with agile because a customer or a single project commonly determines it. Most IT work is already funded with expectations for a start, middle and end. Agile disrupts this somewhat, as it focuses more on the solution and how to incrementally create the solution to meet the needs of the business.
Understand, a product backlog is not a project plan. It's essential to force a standard definition of resource demand. This is still project work therefore, we still define the demand in terms of a project. The project may serve many masters such as multiple customers or multiple businesses. As a result, project teams should show some flexibility in defining projects, while making sure to develop a common vocabulary with your delivery stakeholders. This common vocabulary can then be used as part of your forecasting efforts for demand planning.
Related Article: How Software Can Aid Testing in Agile Environments
Adapting to the Iterative Process of Agile
It is more difficult to plan and forecast future resources for projects without the rigor a waterfall methodology provides. With agile, usually the end dates are a little less firm. One way to address this is to get teams more comfortable operating with “directionally correct” data.
Even with waterfall projects, the future is uncertain. We can only define the future with the information we have and how we interpret it. This information can often change, forcing us to adapt. Don’t become overly exasperated when the future is unknown. Instead, force project managers to estimate future iterations and sprints, even if the plans are subject to change.
Related Article: Don't Go Chasing Waterfalls in Your Software Projects
Focus on the Result, Not the End Date
Ask if a project will end on a given date, and the answer might be “it depends.” That is not very reassuring for a resource manager. However, a project end date isn’t necessarily as significant an issue for an agile environment where work is typically defined in sprints. Each sprint might be two to four weeks long. During this time, assigned resources may be dedicated to four or six full sprints during the project. Resources can change for each sprint, but it is more likely that many of the resources will work consecutive sprints. Keep the team focused on the resulting product.
Because of the very nature of operating with an agile methodology, the churn of sprints can take a toll on productivity. Supporting agile usually requires more resource managers who have to focus on tracking productivity and utilization in a highly iterative environment.
A smart resource manager will monitor planned versus actual hours data and reporting to govern that the defined assignments of resources result in roughly the right number of hours on their timesheets. If gaps or trends of underutilization to the assignments begin to surface, the manager needs to discuss improved ways to assign and allocate resources.