A culture of impatience

I read recently that we have moved inexorably to a 'culture of impatience' that requires 'satisfy me right now' functionalities -- think: cell phone apps, video games, 140 character tweets, and so forth

In fact, here in Orlando, Disney has installed 87 'gaming stations' in the line to Space Mountain to entertain 'guests' waiting--patiently--for the opportunity to ride.  And, there's now a real-time C&C bunker under Cinderella's castle to manage ride and wait dynamics.

Is this news?
Is this culture shift news? Probably not. Who could have missed this shift, or drift?

Certainly not we bloggers who have inserted this 'short form' rapid fire info source into the project space formerly occupied only by the deck of briefing charts and white papers.

[Does anyone read the long form anymore? To answer my own question: Yes, my white papers I post on slideshare.net get a pretty good airing, so somebody still reads]

[And, I recently bought new bookcases for my office to hold my personal library, about which I was asked: "bookcases? really? why?". Since one of my own PM books is now selling on Google's "Ebooks" site, I find myself working on the elevator-speech answer for that one!]

Impatience begets Agile
Enough digression: The topic is 'impatience' and the project management answer to this, so far, has been Agile for a large class of projects [not all of which are software, by the way], or the US DoD's 'evolutionary acquisition.'

So, what is Agile? Agile is both a mindset and methodology.

The arching value is "change should be provoked to incrementally close the gap between the 'as is' output and the 'as is' need".   The going-in presumption is: unavoidably, there is always going to be such a gap. 

Good grief! With this construction, Agile is really just a risk management strategy!  Who knew?  Perhaps it will show up in the next incarnation of Chapter 11 in the PMBOK Guide.

So, the prescient project manager is unlikely to believe in the spot or single-point solution, but is otherwise personally committed that the project is going to get 'close enough' that the gap--even the residual gap when the project is complete--is 'narrow enough' that the sponsor is not only satisfied but is willing to pay for the effort.


Change should be provoked
In case you missed it, 'provoked' is an actionable task, not a 'we will deal with it if it happens' risk response on somebody's register.


To reduce to practice the agile value  'change provoked'  requires a governance paradigm that is constructed for just this purpose. Such a paradigm introduces, or provides control of, a project dynamic...that is, a temporal cadence... that is relatively rapid. Material things happen in a matter of a few weeks in the best of cases, and few months in most real cases in real business' with real trappings that are not to be dissed.

Different project dynamics
The extension of 'changed provoked' into project practices means that the project office needs to run on the same dynamic as the development/delivery cycle. Thus, PMO tasks and artifacts need to be leaned sufficiently to support the cycle times. But, it's not only a matter of lean.  Conventional practices that depend, in part, on long-term analysis to develop the 'facts' to guide decision making and to develop the calibrations for probability assignments, will have to be modified for pieced-wise discreet performance intervals.

And, not to leave out communications, about which we  bloggers have some acumen, the sponsor-PM relationship and the information flows are likewise to be tuned. Thus: the popularity of the short form 'dashboard', updated webpage, and daily 'stand-ups'. Even POTUS Obama gets a daily security and economic threat briefing....backed up in 20th century writing...that is commensurate with the pace of events.

photo credit: target picture: ntang on flickr; c's castle monorail express on flickr

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.