To claim uniqueness, however, does not explain much. This description might elicit many different negative comparisons, such as, “it is almost, but not entirely unlike this other workshop.”
How is this workshop unique? Most project workshops focus attention upon transferring explicit how-to skills: how to plan, how to track progress, how to control execution, and how to build a team. They focus upon the transfer and acquisition of explicit knowledge without ever considering how it is that one goes about acquiring and actually using that knowledge.
This is a different kind of learning, one not encapsulated in any method. Agile, for instance, represents a specific context within which certain techniques are appropriate and others are not. Becoming an Agile practitioner entails exposure to specific techniques, for instance, but practicing agility requires something else, too. It requires a level of awareness about who you are within that context, and not simply the ability to repeat pre-defined practices.
We consider all techniques situationally useful and none universally appropriate. So we focus upon how one might meaningfully pick and choose from among the array of possible approaches to discover, to design the approach best suited to a specific situation. This is at root a design process which includes both knowledge of explicit practices along with a deep awareness of tacit knowledge and personal preference.
To master a project is quite different than to manage a project. Mastery entails both a keen understanding of techniques and methods and a presence of mind while employing them. Mastering Projects focuses upon conditioning that presence of mind which is fundamental to adequately designing any complex undertaking.
How do we accomplish this? First, we ask each participant to bring their own set of learning objectives. Rather than pre-determine the purpose of the workshop for you, we ask you to deeply consider what, in your practice, you want to pursue. This means that the workshop will be pursuing at least as many different objectives as there are participants in the workshop. This context seems to more realistically mirror the context within which real-world projects exist. While a project might have a well-advertised public purpose, every one has imbedded within it innumerable personal purposes: why each individual is engaged. And no project succeeds without attending to these personal purposes as well as the publicly acknowledged ones.
In this way, like on real-world projects, the workshop becomes the medium within which each participant can deeply consider their own objectives and learn to use the workshop to achieve these. Along the way, participants discover clues that inform them about how they form and pursue objectives, and how these pre-conscious patterns of engagement help or hinder achievement.
These learnings take many different forms. Some appear as brilliant a-ha insights, others as less inspiring “oh Shit!” experiences. We employ a simply ethic, “learned if you do and learned if you don’t.” We help you appreciate whatever form your learning might take. We enlist every participant as both a student and a teacher, understanding that your most enduring insight might come from anyone in the room.
We also ask you to bring your own project to use as your own personal case study. Rather than feed you pre-packaged case studies, we help to properly situate your pursuit of your learning objectives by using your own project as the primary case study in the course. We guide you through a series of focusing tools intended to elicit a deeper understanding of yourself, as well as a deeper appreciation of the nature of your project and of the organization sponsoring your project. Not just what to do, but who you, your project, and your organization might be in the context of your specific project.
... More in the next installment ...
I'm investigating some ways to spread the contents of this blog more widely using Technorati. I might as well start here:
I have been, over the past month, developing a series of articles for Projects@Work entitled Unlearning Project Management. The first in this series was published last week to varied critical reception; mostly, it seems, quite critical. My editor there didn't report any death threats, but he did say that several people recommended that he black ball me from further contribution. He said he'd stick with me through this series, hoping that I might "win over a few of my critics" by the time I've finished the series.
What IS my problem with project management as I see it increasingly practiced? Here's some background from an email exchange with one of the critics of the first installment:
Here's something like a root foundation beneath my assertion. Over the past decade, I have visited dozens of companies struggling to deliver project results. The PMBoK-addicted ones seem to struggle much more. I know this says nothing about the PMBoK, but a lot about how people interpret PMBoK. Perhaps if it was titled, "Some Potentially Useful Project Management Information" this imprinting would be less severe. And, honestly, the problem imprint is rarely at the project manager level, but several levels above that. Executive edict commands that projects will henceforth be managed according to some Hoyle's model, and people within the organization just shut down their natural ability to pick and choose what seems right for their context in favor of pleasing their management. The stories proliferate (most falsely) that if they fail to live up to the promise of PMBoK by choosing differently, they'll be fired (or worse, whatever that might be.) So then their projects are saddled with the obligation to both do their projects "right" AND deliver results. The disconnect is not lost on many, but the disconnect is not easily reconnected.
I have seen many, many, many projects expend more energy failing to fulfill high church expectations that are inappropriate to the scale of their engagements. And lose connection to what works there in the process. So, I'm not on a rail against PMBoK, but, as you'll see in upcoming parts of the series, about how people, in the presence of the """Body Of Knowledge""" respond as if in the presence of something smarter, more knowledgeable, than they already are.
Napoleon claimed that the pursuit of perfection was the greatest evil. I think my moral outrage at the continuous improvement mindset is somehow rooted in this observation.
So, I'm trying to reconnect people to their natural genuis, the one that pre-dates their innocent adoption of an essentially mechanical mindset, which insisted that work is about process and process-improvement, and not about organic human interaction. This is a tough sell, and an even tougher 'think.' Once imprinted on a frame of reference, it's next to impossible to consider any other way; and even more difficult, this experience is teaching me, to explain an alternative in any way that makes sense from within the imprinted frame of reference. I teach about dissolving dilemmas, and I've adopted a dandy one here.
We (Amy and I), in our Mastering Projects Workshop, have found it essential to focus upon some form of relationship mapping BEFORE creating any task plan or even the roles and responsibility exposition, because acknowledging existing relationships can help create a plan that works with what's there. This can also head off some inevitable collisions.
We always find some busted relationship in the mapping, someone in the community who has the power to take another's lunch money without even intending to. Learning how to better cope with these subtly powerful people in our relationships adds a lot of potential to the person and to the project. Creating a task plan without acknowledging these powerful networks seems theoretical; not well grounded in reality.
Of course, these maps are no less notional than any task network, but they seem to carry deeper personal meaning. (Note that everyone, always, already carries an implicit relationship map around inside them. This activity merely moves what might have been only implicit onto more explicit ground.) We guide each participant in creating their personal map of their relationships, and never insist that these be shared or distilled into a single, comprehensive model. These are information, not definition. How I see you is not how you are, but a representation of how I see. How I cope with what I see is more important than agreeing that what I see defines anyone else's reality. Also, announcing that I characterize you as a jerk on my relationship map won't improve our relationship. This is personal information.
We focus upon what we call 'high-cost relationships.' Ones where we aspire for the relationship to be different than it seems to be. Where, for instance, we feel we need a committed relationship, but experience an indifferent one. Or where someone with an invariably different perspective has the power to say, "No!" and make it stick. Then we work through a little safe role-playing, where individuals get the opportunity, with a supportive coach on hand, to engage with their nemesis. The results are usually surprising. Whether the objective of the conversation is met or not, a deeper understanding of how that relationship might work results. Oh, and the one initiating the relationship usually learns how useful it is to have a coach.
I believe that in the future, most project "planning" will incorporate these techniques, and the explicit exposition of social networks will be recognized as an equal, perhaps greater contributor to project success. If the plan doesn't acknowledge informal relationships, focusing only upon formally-assigned roles and responsibilities, looking at formally-declared tasks as the premise for getting stuff done, the project can't work. Can it? When the plan falls apart, these networks kick in to actually get stuff done, whatever the plan might say.
This is a high-level outline of one of the key elements of creating a project community. More in later posts ...
