“Change is hard because people overestimate the value of what they have – and underestimate the value of what they may gain by giving that up.” — James Belasco and Ralph Stayer, Flight of the Buffalo (1994).
New trends drive change every day in today’s complex global marketplace, presenting business leaders with serious challenges. Astute leaders are constantly on the lookout to more effectively manage their projects and programs. Information Technology leaders in particular have started to pay attention to Agile Project Management.
While presenting on this topic at a Project Management Institute event in Atlanta, it became evident to me that not all project leaders are able to clearly articulate what value Agile principles can infuse. There are several key differentiators between Agile and traditional methods that warrant attention.
Typically, project managers are accustomed to a project plan, which contains a series of tasks laid out for the entire project. This will list task durations, responsibility assignments, and dependencies. Plans are developed in this manner based on the assumption that the Project Manager, in consultation with stakeholders, can predict up front all deliverables details, including estimates and resource assignments.
Agile project plans, on the other hand, are based on features. The plan projects when features will be delivered to production. Full details surrounding how those features will be delivered may be missing, although the most current iteration tends to have more information. Agile plans are based on the assumption that stakeholders do not always know what conditions will be six months from now. The project leadership team can put together a reasonably good estimate of about what will be delivered based on the priority of the features and functionality the team needs to deliver within a given timeframe.
Because traditional project plans tend to be task-based, it often seems appropriate to group like tasks together into phases. Let us take the example of a software development project. It typically will follow these steps:
- Gather all requirements
- Perform analysis work on all required functionality
- Perform design work on all required functionality
- Develop code for all required functionality
- Test all required functionality
- Deploy all required functionality
The result here is that the actual end products do not take shape until well into the project, so substitute measures of progress have to be established to provide the stakeholders an idea of how the project is progressing. This is usually accomplished by providing a count of how many tasks are completed and a percent complete estimate on those that are not done yet.
Agile project plans are organized into time bound iterations, usually anywhere from 2-4 weeks in length. During those iterations, all of the necessary work to take features from an idea to a working product is completed without artificial dependencies that prevent work from being done in parallel. The end result is that portions of the product are delivered on a regular basis. This gives stakeholders an opportunity to provide feedback as the project team works through iterations.
Traditional project plans are often developed up front based on the best information available at the time. In order to reduce the risk of the unknown, the team lays out the entire project and assigns all of the work so nothing is forgotten. This results in a highly detailed plan, often scheduled down to the hour, stretching sometimes six months to a year out into the future. My experience with managing and trying to estimate large program efforts is that humans are not very good at foreseeing the future. Given today’s chaotic business world, this approach leaves plans outdated shortly after they are finished.
It is completely reasonable to expect a team to be able to identify what they will be doing at a relatively detailed level for the next 2-4 weeks. Outside that time frame, things become less clear because of changing business conditions. Agile project plans address this with multiple levels of detail based on timeframe. At the high level is a release plan, which highlights what functionality the team is planning to deliver for the next several iterations. For the most current iteration, the team produces a detailed plan that includes tasks needed to deliver the planned functionality. This multi-level planning allows the team to adjust their approach to account for changes and techniques learned during previous iterations.
This can be one of the bigger hurdles for traditional leaders. Project leaders are used to having ownership and control of the project plan. Some project managers look at the project plan as one of their major deliverables in a project.
In the Agile world, the team is empowered with ownership of the project plan. They work with key client personnel to decide what functionality will be produced in a specific iteration. They are given the responsibility to decide what tasks are necessary to successfully deliver the planned functionality in an upcoming iteration. They self-select the tasks that they will complete and update the status accordingly. They are positioned to self-direct their deliverables.
People are creative individuals who figure out ways to achieve results. Providing people with the autonomy or freedom to determine how to accomplish outcomes helps people learn and feel that they can be trusted. These differences may give experienced project managers a reason to stop and think. Many of these ideas run counter to what they have both been taught and practiced for several years. Agile ideas make sense in a projectised organisation focused on delivering value to stakeholders in a fast-paced environment with frequent changes.
Mastering change as a core competency, both individually and organisationally, leverages strengths that only change-adaptability can bring, and helps you differentiate your organisation in this highly competitive global marketplace.