The Case For Rigid Project Management

 

Being the contrarian that I am, when I saw that ProjectManagement.com’s November theme was Agile PM, my thoughts (automatically?) went to compared to what? Agile PM, a favorite of the Information Technology set, was originally developed to accommodate the significantly more dynamic management environment where software projects are developed, since employing a traditional Baseline Change Control Board that meets once per month would be to condemn the typical IT project to an ossified configuration control-induced overrun/late delivery. I get that. By arranging the elements of the project’s scope into Epics and Sprints (roughly analogous to Control Accounts and Work Packages), the members of the Project Team with specifically assigned change control authorities could quickly modify the performance characteristics of that scope to account for unanticipated conditions or advances, enhancing the odds of an acceptable product being delivered on-time, on budget. Take a look at the list of antonyms for the word “agile,” from thesaurus.com[i]:

• dull
• ignorant
• lethargic
• lazy
• slow
• clumsy
• rigid (hence the reference in the title)
• stupid (really!)

…among others. Indeed, among the list of antonyms for ”agile,” I didn’t see any that had a positive connotation. So why in the world would anyone attempt to make the case against Agile PM? I’m glad I’m asking myself that question.

The problems inherent in Agile PM are pretty easy to uncover. A quick reading of The 13^th Annual State of Agile report makes them apparent. For example, the whole raison d’etre for Agile PM was to be able to deal with fast-developing changes in scope, right? Well, on page 11 of the report, under the open-ended question “How Success is Measured …with Agile Initiatives (emphasis in the original), we see this gem: “Product scope saw a decline over the past years going from 40% to 20% and falling to 12% this year.”[ii] For a business strategy designed to alleviate difficulties in modifying scope within the traditional PM structure, this is quite the poll question response. With respect to managing scope, its own practitioners appear to be losing faith in Agile’s ability to perform as advertised.

A glance at the topic of “Challenges Experienced Adopting & Scaling Agile” is also revealing. Survey respondents’ top three challenges were:

1. Organizational culture at odds with agile values
2. General organization resistance to change
3. Inadequate management support and sponsorship.[iii]

In addition to reminding GTIM Nation of Hatfield’s Incontrovertible Rule of Management #5, that one cannot advance a capability maturity by leveraging organizational power, I’ll add this quote from Nicolo Machiavelli:

“It must be considered that there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things.”[iv]

For every frustration the “traditional” PM-types have had in influencing organizational culture to do such basic things as setting up the general ledger’s chart of accounts to mirror the project’s Work Breakdown Structure, what the Agile PM practitioners attempt in business model influence space is even more difficult. The three “challenges” listed above are essentially the same complaint: the people we’re selling Agile to aren’t buying, and management won’t make them. I believe all three reflect the inherent difficulty in “initiat(ing) a new order of things.”

Finally, if we’re being brutally honest, I’m convinced that, should each member of your typical customer-attended sprint meeting OR Baseline Change Control Board be struck by a random flying sodium thiopental dart, at least one customer would admit to being on high alert to prevent the allocation of a cost adjustment for having overspent a Work Package or two (a “get-well” Baseline Change Proposal, or BCP), while the contractor is hyper-vigilant to prevent the addition of something that’s technically not in the baseline, at zero additional cost (scope creep). How this sub-rosa conflict plays out in a typical BCCB meeting tends to follow a familiar script, including lofty discussions on how contingency or management reserve is properly defined, estimated, and used. But how it’s played out in an Agile Planning meeting is a bit more convoluted. Instead of having a paragraph in a BCP template that addresses the nature of the change, with another spelling out its impact to the baselines, the Scrum Team will evaluate “User Stories” in the Sprint Review to evaluate completed tasks, and use those lessons to inform how to continue to work incomplete tasks. With these verbal User Stories – essentially, narratives – being, by definition, more fluid than their traditional, written-out versions, it seems to me that there would be an increased chance of either scope creep or get-well changes seeping into the cost and schedule baselines.

Sure, I’ll get with the ProjectManagement.com program and discuss some of the more gee-whiz aspects to Agile PM in later blogs. For now, I just had to go ahead and make the case for performing configuration management more traditionally, or, as the list of antonyms for “agile” puts it, “rigid.”

[i] Retrieved from https://www.thesaurus.com/browse/agile on November 4, 2022, 17:33 MDT.

[ii] The 13^th Annual State of Agile report, pp.11.

[iii] Ibid, pp. 12.

[iv] Retrieved from https://www.internetpillar.com/niccolo-machiavelli-quotes/ on November 4, 2022, 18:20 MDT.