Agility, as a practice and principle, has nothing to do with the mechanics of agile software development (ASD). By this, I mean that an individual or organization can practice agility without ever having encountered ASD or even hearing of the Agile Manifesto.
Why is this important? Recently, I’ve spoken with too many PMs who apologize for doing waterfall, or a sequential form of project management that’s based on phases. In cases where a phased approach fits with the nature of your work, like construction, then waterfall is appropriate. However, if you don’t need to work in phases, you might consider sneaking a little agility into your otherwise linear process.
Measuring success or failure
The secret to incorporating agility into your workflow is to focus on four main areas: outcomes, risk, staffing, and rapid decision-making. It should be obvious that you can’t deliver a project successfully if you don’t know exactly what you are delivering and why.
From a PPM point of view, this means you need to know not only what the project is intended to deliver, but also how success or failure will truly be measured. And no, “on-time and on-budget” never counts as a real success criterion when agility is concerned. Otherwise, when faced with a decision to either cut some of the originally planned scope and deliver early, or spend more and deliver on time, how will you know the right choice for your organization? True agility requires understanding where your wiggle room is.
Using agile to deliver critical results
Agility is easiest to incorporate into mission-critical projects. After all, those are the projects where there is no disagreement about the need for the outcome.
For example, I was once called in to run a mission-critical program for a large software company that was already six months past its originally planned start date. Theoretically, the deadline was moveable. So, the first thing I did was throw out all the nice to have “requirements” (that had absolutely nothing to do with the program) and focused exclusively on delivering what the CEO wanted.
I was also fortunate enough to be able to staff the project with consultants. It wasn’t that the people in the company weren’t good. It was simply the fact that they were already over-scheduled, and there was no possible way enough of them could be freed up for this project.
This situation illustrates just how next to impossible it can be to get even important things done internally. I was only able to deliver results by working with consulting resources to backfill over-allocated staff positions, which is a rare occurrence.
Success depends on your core team
Consider this thought experiment. In your organization, if management comes to you and says, “We need this done NOW!”, how can you stack the odds in your favor?
The first thing you must do is get a dedicated team. No matter who else ends up working on your project, you’ll need a core team that understands exactly what needs to be delivered. If management doesn’t want to assign a dedicated core team, they aren’t serious about wanting the project done quickly, and you can relax. After all, there is no reason to stress if nobody else is.
Once you have the core team, you can always hire contractors for the other positions. A dedicated team, however, is required for speed. A million and one things can go wrong, and we know from experience that a significant number of those things will go wrong. You need the team to have the bandwidth to work around the problems.
The second thing you must do is trust your team. Their intuitive sense of knowing when there is a problem or how to solve a problem might be the only reason you end up succeeding.
I learned this lesson one Friday evening, right before we were about to deploy six implementation teams into the field as part of a mission-critical program. Right then, one of the field-team PMs called me and said, “Stop, we are planning to do it all wrong.” He went on to recommend that we centralize some of the work the field teams had planned to do (rather than have each team do it themselves).
As I remember, I asked him if he was sure, and he said he was. By Monday, we had seven teams — six in the field and one at our central office providing support. When we did the lessons learned a year later, everyone unanimously agreed that this decision was one of the biggest reasons we succeeded. In fact, the team estimated that it would have taken us another six months if we hadn’t centralized.
Agility requires being willing to back not only your own judgment, but also that of your team. At the time, I was a recent addition to the program. Based on my personal knowledge, I couldn’t guarantee the PM’s suggestion was right. What I could be certain of was that the PM, as an expert, believed he was right.
People are the secret to agility
A successful project team is much more than a collection of people assigned to complete tasks on a project. It’s about each individual understanding how their specific tasks are contributing to a common goal.
I’ve been fortunate enough to be a part of many programs that successfully delivered their outcomes on time. In every single instance, the reason we were successful was that we had a dedicated team of involved, creative, and committed people who cared about delivering results.
