The Project Management Institute (PMI) is revising their seminal document, A Guide to the Project Management Body of Knowledge, PMBOK Guide 4th Edition to version 5. These revisions are made by committees subject to countless comments, arguments, lamentations of the commoners and gnashing of teeth...
This revision is interesting - to me it reflects a rather dramatic shift to what I call the "right", or the end of the control spectrum that represents high levels of definition, proceduralization, controls, or in English - the level of micromanagement necessary to support our old friend, EVM. So why would I like this one? In their attempt to more strictly regulate and control the execution of the project, PMI has actually done us a favor by forcing more emphasis on the "fuzzy front end" of the project, which is where the ability to succeed as a project manager resides.
PMI has hinted at this shift before - the 4th edition drove home the importance of good requirements and the impact that level of definition can have on scheduling, cost estimates, and legitimate controls during execution. So here is the rub - where do these requirements come from? The list is long and exhaustive, just look it up...but is this really a "one size fits all" situation? If you can legitimately tell me what it is you are looking for with good detail, chances are we are dealing with what we call a "technical" project - which fits nicely into the PMI framework. So what do we call those projects that are what I call "fuzzy" - those that are ill-defined, experimental, require deep thought and assessment, have a heavy reliance on knowledge workers, and often exist without a solid potential for ROI? Adaptive? Agile? The term nightmare works for me, but more often than not I simply call these my "reality".
Requirements for these "fuzzy" projects tend to originate with a stakeholder(s). These stakeholders, believe it or not, are normal people just like us. The 5th edition places significant emphasis on these people, and uses terms such as "satisfaction as a deliverable", "engagement", "controlling relationships", "fostering", and "continuous dialogue" - all with the intent of controlling them to control the execution and ultimate outcome of the project.
HOW COOL IS THAT?
I'm not sure if I'd be so subtle about it though, as the term I've always used for this behavior (right or wrong) has been MANIPULATION. Sure that sounds ugly, but is that not what we as leaders really do? So how does one effectively manipulate without negative effect? By knowing your stuff as both a leader and a manager, fully understanding the mission and objectives, and most importantly by knowing people and how they function.
See how that ties back into our discussion on Leadership? As if by design...
Until next time ~ Cheers!
No comments:
Post a Comment