The Value of Domain Expertise: Football By Football

One of the “old chestnuts” I heard when I started to consort with project management professionals was the “functional vs. project skills” chestnut. I used to hear from many project pros that all that was really needed for project leadership success was command of the project management body of knowledge (PMBOK). But as the quote from the PMBOK Guide (3rd edition) in the post suggests, the full PMBOK itself is just one element of what must be understood and used.

To that point, a new football blog — American football, for my international readers — is all-in on the value of “functional” knowledge. Football By Football started at the beginning of the 2014 National Football League season, and it lays out its strategy on the home page: is a football analysis website providing unique player-writer generated content; owned & operated by experienced football players.

Experience counts immensely—especially in analyzing the world’s most complex sport. A tiny percentage of the writing population has football experience. This is a disparity we aim to change.

Football fans crave insight. So, when the world orders a steak, you don’t butcher a chicken.

A great, but subtle, example of the site’s value is a recent post on the “Best Way To Spend Your Bye Week.” The bye week — a week off during the regular season — is a relatively recent innovation in the NFL schedule. I had no real idea of what the players did during the bye — I’m a family guy, so Chris Snee’s account of home time resonated — but the other two vignettes had a couple of “Aha!” moments.

Drew Bennett noted that many players don’t get time off if they are injured and unavailable for practice. The time off was so alluring that walking wounded would rise from their beds, so:

that final practice before the break begins is a riot. You see guys that were on crutches Monday hobbling through pass rush drills. You may see a receiver with a cracked wrist catching passes. You could see someone who barely made it through a meeting with back pain lined up for conditioning.

Matt Chatham highlighted that one’s itinerary during the bye week is a non-obvious choice. Perhaps there’s more structure now, but as I read his piece I realized that the bye week only started in 1990. I doubt that there was a good idea of what to do with that time off, at least not for a while. After all, any downtime was balanced by the fact that the season would resume — in midseason. The players had to jump right back into their midseason mindsets, or risk a loss (or a string of losses). Every game, practice, and event is magnified in the NFL: there are only 16 games and one or two losses can doom a season. Chatham realized that the way his first approaches to his bye week affected his mindset:

I had teammates who went to Jamaica for a few days, which sounded insane to me with a long day of travel on each end. But I got caught up in the idea that ‘I must be missing something,’ so I compromised and went to a beach resort in Florida. I still felt rushed to get down there and back.

No dice. Never again….

I learned. No reason to put myself through that. A little bit of pleasure that somehow made me feel worse in the end.

As they say, read the whole thing.

Don’t PMs get that they’re “business” people yet?

I saw a somewhat depressing article in this month’s PM Network about the need for project managers to get business-savvy.  Not that there’s anything wrong with what Gary Heerkens writes (the article itself is here).  What saddens me is what this article implies about the mindset of project managers:

  1. Too many project managers don’t see “business understanding” as part of their job.
  2. This expectation isn’t explicit enough in PM job descriptions or how PM performance is managed.
  3. PMs seem to want the title, but not the responsibility. 

IMO, a project manager who can’t participate in business discussions can’t meet the substantive requirements of whole swaths of the PMBOK Guide.  How can a project manager participate in charter, scope, and change control discussions without knowing the business?  Otherwise, aren’t they really project coordinators, assistants, etc.?  As Gary notes (and understates):

Basing choices solely upon technical or functional considerations means all of the critical inputs required to make the best possible decision aren’t being considered.  Project managers who do not understand the business aspects of their projects are destined to make subpar decisions from time to time.

Is the PMBOK Guide a standard if it is always changing?

That’s the question posed by James Brown (here). He points out that the PMBOK Guide 4th Edition no longer discusses the Triple Constraint — yes, I was shocked it was missing too!  He wonders if the PMBOK Guide:

…is not a standard if it is always changing!… PMI is at risk of devaluing the PMP certification because now you have project managers certified on different sets of terms. When an organization hires a newly certified PMP based on the fourth edition of the PMBOK. they may not know the term triple constraint. A standard doesn’t have to be perfect, but a standard must be a standard to effectively serve its purpose!

In this case, I agree that the loss of the term “triple constraint” is pointless.  It is a powerful way to highlight the choices that one needs to make among competing priorities.  Why not elaborate the concept or point out its limitations instead of dropping it?

However, I challenge the idea that a standard cannot be “always changing.”  For example, should there only be one edition of the Merck Manual or various ANSI standards?

While we should avoid change for change’s sake, project management is still trying to codify the common sense Dr. Brown mentions. We’re a long way from having a stable project management standard, IMO.

PM Standards are not Holy Writ

Andrew Meyer at Inquiries into Alignment provides a useful corrective to the faith that we project management types put in our industry standards and frameworks (post here).   He hits on a lot of topics that are only alluded to in our project management “bibles”:

[P]rojects often pull people from different departments together to work on a project. While that is what the project requires to be successful, what does that mean for the people pulled from the different departments? Is the project of primary importance to them or is what’s happening in their department of primary importance?

Now, I believe Andrew that has set up a bit of a straw man here.  I’m not sure that it is the responsibility of the PMBOK Guide or PRINCE2 to elaborate some of these topics fully (I’ll leave Agile aside for the moment).  At least in the case of the PMBOK Guide, it is only a guide to the project management body of knowledge.  While a guide should reference the need to ensure business alignment, only so much content “meat” can be expected from such a guide.

My take is that firms should not count on generic standards to cover some of these topics —  one’s firm-specific methodology should elaborate the questions Andrew suggests (and more):

What is the business environment your company is working in?
How is that environment changing?
What is happening inside the business?
What is the state of the project?
Where does it need to go?
What needs to happen to get it there?  

Monitoring and Controlling — what the PMBOK Guide says and shows

My last PM Quote (here) reminded me of this PMBOK Guide issue.  There’s an awkwardly phrased topic sentence in Chapter Three that gives some the impression that the PMBOK Guide intends to segregate monitoring and controlling activities in the executing process group:

The Monitoring and Controlling Process Group consists of those processes performed to observe project execution… to control the execution of the project. — Page 59, PMBOK Guide 3rd Edition

The focus on execution is unfortunate, because a lot of folks seem to stop there when skimming the Guide.  Throughout the Guide — and even on this same page — we find better indications of the team’s intent, IMO:

The integrative nature of project management requires the Monitoring and Controlling Process Group interaction with every aspect of the other Process Groups. — Page 40, PMBOK Guide 3rd Edition

[A]ll of the Process Group processes would normally be repeated for each phase or subproject. — Page 41, PMBOK Guide 3rd Edition

The Monitoring and Controlling Process Group not only monitoring and controls the work being done within a Process Group, but also monitors and controls the entire project effort. — Page 59, PMBOK Guide 3rd Edition

The botched topic sentence notwithstanding, the PMBOK Guide doesn’t give us an out.  Monitoring and controlling activities are needed throughout the project.  There’s even a purdy picture…


Squaring up the PMBOK Guide and Agile

Glen Alleman shoots down some of the common misconceptions about the relationship between the PMBOK Guide and agile principles (here).  As regular readers know, I’m sympathetic to agile approaches, I’ve found them very powerful in the right project context, and I push to incorporate agile principles further into our own content. 

Of course, if I commented on Glen’s post itself, I’d be writing “ditto” or “I agree” a lot, so I’m just going to add on a bit:

  • While many agile advocates over-read the PMBOK Guide, the guide did imply a waterfall approach, especially in earlier editions (Chapter 2).  I can understand the confusion or over-reading.
  • The pending 4th edition does have a more sophisticated treatment of project life cycles and explicitly addresses iterative relationships among project phases.  It is hardly sufficient, but it is heading the right direction.
  • PMI itself is quite eager to engage agile advocates for future editions (or extensions) of the PMBOK Guide.  Several Global Corporate Council members were approached about how and whom to engage in the agile (or agile-savvy) community.
  • My take is that creating an Agile extension to the PMBOK Guide would be the best initial approach.  If nothing else, integrating agile-oriented PMs into the standard-setting process should be easier in an extension project.

PMBOK Guide 4th Edition — Pet peeve in glossary

There have always been a few in-apt or questionable glossary terms included in the PMBOK Guide‘s glossary.  But in particular, the persistence of the Delphi technique puzzles me.  I mean, how many people actually use it?  Have any of you all seen this technique used recently

A lot of such techniques are around and all have their place.  And it isn’t that I have desire to see Delphi stamped out.  It just seems so out of place as something that should be codified in the PMBOK Guide

The bottom line is that Delphi just doesn’t belong; here are four reasons off the top of my head: Continue reading


Get every new post delivered to your Inbox.

Join 12,325 other followers

%d bloggers like this: