Agile Is Great, But What About The Other Half Of The Equation?

 

Agile Project Management is very popular among Information Technology (IT) portfolios, and for good reason. It can be reliably employed to significantly increase the odds of any given IT project coming in on-time, on-budget. It is also a source of frustration for me, since it does have some notable shortcomings, but its afficionados tend to be oblivious to them.

Problem Number One is that, while Agile does streamline the configuration management problems that tend to accompany traditional PM and its Baseline Change Control Board (BCCB) lethargy, it can also impede the discovery and implementation of the optimal technical approach. To help illustrate this, let’s turn to the Game Theorists’ favorite tool, the payoff grid. Consider two scenarios (simultaneously), where a given IT Project is headed by a manager who has identified the optimal technical solution, and is pursuing it, versus an analogous Project where the PM is rather unsure or unclear about the best way of addressing the Project’s central problem. Add to this two environments, one Agile, the other traditional PM. Here are those scenarios in a payoff grid:

Let’s dispense with Scenario D first, since this is likely the environment that hatched Agile PM in the first place. If the PM has selected the optimal technical approach to the central problem of the IT project, the last thing she needs is an ossified BCCB curtailing her latitude of movement when it comes to configuration management. A key characteristic of Agile PM is that it reduces the number of opportunities for, ahem, stakeholders to influence the technical agenda in the name of expediting progress (take that, Communications specialists!), meaning that, if that very technical agenda is the best fit for the organization, most superfluous input isn’t even allowed a venue. Conversely, if the best technical approach is unclear or even unknown, a traditional PM approach (Scenario A) can provide greater opportunities for more voices to be heard in identifying it, assuming the PM is open to the greater number of stakeholders.

The remaining two scenarios are where we can easily get into Project Management problems, with no nominal capacity within Agile to correct. The most readily-available boogey-man for those wishing to avoid traditional PM techniques in IT projects, Scenario C, is rather difficult to refute. IT projects tend to be far too dynamic and fast-paced to have use of a BCCB that meets every month, or even bi-monthly, where almost any member can slam the brakes on a recommended or needed scope update. Recall the old saw that there are no solutions, only trade-offs. What’s being traded in Scenario B? Well, if the optimal technical approach is either unknown or unclear, the removal of the BCCB carries with it fewer stakeholders providing input. This input can be inessential, but every now and then it can also be game-changing in its capacity for steering management decisions in the right direction.

Then we have the problem of implementation. Probably the only genre of software that isn’t in need of some sort of consideration of how it is to be implemented to the wider organization is games, whose customers purchase it for entertainment. I believe most everyone else is looking to enhance a management capability, which means we’re tinkering with a business model. Make no mistake: no matter how blatantly obvious that an extant Management Information System (MIS) is failing to perform adequately, there will almost always be someone within the organization who will not want it to change. In a mid-to-large organization, you can even expect some members to actively work against any transition, which leads us to Problem Number Two: while Agile may enhance and streamline the Configuration Management process significantly, it really doesn’t address the implementation strategy. As stated earlier, this is irrelevant in the development of game software, but for virtually everything else it’s going to be an issue.

“But Michael!” I can hear GTIM Nation say, “why are you laying the implementation issue at the doorstep of Agile PM? Don’t other projects have similar problems?” No, not really. You generally don’t need to convince the members of the client organization to occupy a new office building, or municipality to hook up their power grid to a new dam. Software is different like that, and, since Agile lays claim to being an adaptation of traditional PM for Information Technology specifically, I think it should be at least somewhat on the hook for this oft-encountered barrier to successful project completion.

For those who insist that simply mandating the usage of a new or updated system, on pain of discipline, is sufficient for IT project success, I would counter that a lack of an appropriate technical approach to the actual implementation will more than negate any advantage from using Agile over traditional PM in the first place. The only question left is, what are you going to do about the other half of the Agile equation?