The Nimble PM

It occurred to me this morning that we might need to be clearer about what the difference is between an apprentice, a journeyman and a master PM.

An apprentice works with black and white. He believes all knowledge comes from an authority and must be followed exactly.

A journeyman works with shades of gray. She finds that there are at least three different perspectives on every ‘rule” she ever learned and knows if she lives long enough she’ll probably find a circumstance where each one of those variations will be true.

A master works with black alone because black is the sum of all colors. He is comfortable with oppositions, contrasts and subtleties and takes them all in stride, celebrating their richness.

You can generally recognize a Master when you meet him or her. It’s the apprentice with 15 years experience that tends to be the source of the problem.

Thoughts? Comments? Opposing Opinions?

At the beginning of every summer I generally kick off a discussion with my peers as to what PPM books we’re planning to read during the summer.  To be honest the last couple of years it’s seemed that the choices have been few and far between.  I’m delighted to say that’s changed this year thank;s to Dr.  James Brown and his immenently readable book.  The Handbook of Program Management is possibly misnamed.  It isn’t a dry methodological tome. From the moment I picked up the book I realized that Dr. Brown actually knew what he was talking about and had taken the time to share his years of tacit learning with his readers.  All the reviews posted at Amazon speak to the same thing.  This book is like chatting with a master program manager who is willing to give you lots of practical tips about how to do something rather than just telling you what to do.  Just to bring the point home as to how choke full of good advice this book is I randomly opened the book to page 137 and the first thing I was struck by is this quote

“Asking for and thanking people for their followership is a powerful way to ensure commitment.”    

Turns out the entire section I flipped to is about the importance of creating followership and since I’ve written on the same subject myself (xxx) I was immediately left with the feeling that Dr. Brown and I have shared a common experience (managing programs) and that we’ve come to some similiar conclusions that we both think are important enough to share with others.  I could probably flip to any random page (and I have) and find a topic that I’ve touched on in my research or written about elsewhere over the years.  For those of you how have PMCoP in your organization I strongly recommend purchasing this book and handing it out.  There’s enough in here to keep you meetings going for a least a year.  

Happy reading.

In my last post I discussed two perspectives that will lead to better project results. In this posting I’ll be discussing the third perspective.

3) Projects results will improve as long as the project team is equipped to handle anything that might block their progress toward completion.

Not sure I’ve got the statement above worded exactly right but I’m going to let it stand for a moment. For many project organizations, the implementation of this handy piece of advice is accomplished by spending as much time as possible in up front planning. Unfortunately, based on my experience, for most internal IT projects, planning efforts quickly reach the law of diminishing returns.

For those of you who don’t remember your college economics the essence of diminishing returns says beyond a certain point you receive less and less benefit from every dollar you invest. This concept is also known as the law of diminishing marginal returns, the law of increasing relative cost, or the law of increasing opportunity cost.

What I particularly like about this concept is that it helps to point out the various potholes that tend to occur when projects begin without a good grasp of what’s important and what’s not. Projects and Program do need a period of time before work starts on the creation of the product or the deliverables but there’s little advantage in spending the time in attempting to prognosticate the future as most linear project plans attempt to do. The time is actually better spent in determining how little needs to be done to meet the objectives and what needs to be organized to make the execution of the project as efficient as possible.  Essentially Nimble PM (you pick the p) says that you create an area of order (because as we all know things are sensitively dependent on initial conditions) so instead of PLANNING the emphasis is on DOING up front in order to create a situation under which the project or program has the highest possibility of success.

I’ll be exploring more about this concept of area of order in later entries. For now I’ll just say that while I was in Asia-Pac, I had a delightful conversation with an organization that we would categorize as a true PPM maturity level four and I was obviously intrigued to find the same emphasis on practice and action coming from them as from me.

Anyone who knows me knows that I can argue both sides of a topic with equal fluidity.  This is a skill I picked up from my father who was legendary for asserting a position and then explaining (to anyone who would listen) all the reasons why his deeply held belief might, in fact, not be right.  In the past I have made the assertion that PMs should have some level of subject matter expertise.  This is a definitely something I believe in quite passionately but like most things, there are exceptions.  Based on my own experience the definition of what subject one needs to be an expert in changes depending on one’s role on a project or program. 

Once upon a time, in a world long past, I was a program manager on the final stages of a large custom costing and planning system.  I knew the industry, I knew the costing function (at least at a high level) but the truth is I could have known absolutely none of those things and still have done my job.  The only subject matter expertise I needed for that job was 18 years of management experience in leading teams and keeping senior management happy.  In fact I can safely say that all of my program management assignments never required me to get involved in the details of what we were delivering; I had project managers who did that and they were more than good at their jobs. 

So if I didn’t need to know anything about what we doing specifically did I still need to know something about software?  I think so, but my opinion on this topic is a little less strident and a little less sure.   I believe the answer is yes because if you aren’t an “insider” then unless you have some other claim to charismatic leadership, the team probably won’t have enough confidence in your abilities for you to be an effective leader. 

So bottom line, I think how deep your knowledge of the “product of the project” has to be changes with your role on the project/program but even when you don’t have to know anything about what you’re delivering you still need to know how to inspire confidence in the people you’re leading and that generally means being considered “one of them” by virtue of prior experience.

Thoughts???  Comments???

A post by Wally Bock on his Three Star Leadership Blog got me thinking about our the working environment we create based on how we manage our PMOs, our programs, and our projects.  

Over the years Mr. Bock’s has compiled a list of what people who have attended his class consider the hallmarks of an effective workplace.  While I hope to explore the entire list n the future today I want to focus on first element on the list which is productivity.

I have to admit I was delighted to see that productivity was first on the list.  I have always held a world view that most people not only want to do a good job but they positively relish the feeling of personal mastery they get from a job well done.

A desire for being productive also makes our jobs as managers fairly easy.  All we have to do is remove any road block that stands between what our team members hope to accomplish and success.  If we do that, they’ll do the rest.  I don’t know how anyone else feels about this, but removing roadblocks as a job function works for me.  It says that all I need to do is figure out how my team members get the information and the tools they need to do their job.  If I give them that they will in turn provide the brilliance and creativity to craft the product that the organization needs. 

If you’re tempted to respond that I’m just repackaging management 101, let me take my thoughts   a little further.  This truth is it isn’t always easy to remove roadblocks.  There often isn’t the money to give people the tools they really need to do their job right especially in this economy.  To be successful then in our jobs we need to be very good at working the political system and very good at garnering support for the efforts of our team.  We also have to be successful at our jobs to make sure that our team members judge the environment as supporting their productivity.

Twenty years ago I learned this lesson rather painfully.  As sometimes happens in life I had hit a bit of a rough patch personally and because of a lingering illness found that I simply didn’t have the energy to fight all the fights for my staff that I had always done in the past.   After about 6 months of this one of the women who worked for me came into my office and told me I had severely disappointed her.  She told me she had transferred into my group because of my reputation for ensuring that people could get things DONE and that I simply wasn’t measuring up to her expectations.  What a gift she gave me through her absolute honesty.   I have never doubted since that moment that productivity is a collaborative endeavor between a manager and a team member.  She also left me knowing that there really is something called servant leadership which was my job and even though I had scrupulously done everything the company expected of me, I had still failed because I hadn’t honored my contract with my team, which was “you do the work and I’ll make sure you can get the work done.”

In future entries I’ll be exploring the other 7 characteristics of an effective workplace.

I’m not sure why I woke up this morning thinking about lessons I learned on old project.  I have a tendency to reflect back on projects that didn’t go like clockwork and since people only hired me for difficult project I have a vast mental store of examples I can reflect on.  This morning’s was a project I did at least 11 years ago. A manager in a client company was given funds to do a 90 day cost benefit analysis of a proposed project. He was sure he had a great idea but he just couldn’t figure out how to build the business case to justify it.  

In today’s tight economic times its hard to imagine spending money to justify spending money but below the surface there were a number of appropriate reasons for this expenditure. The first reason was that it wasn’t just the project that needed justifying it was the manager’s whole department and the unspoken truth was that if he couldn’t find a body of work that needed doing, then he and his department were probably unnecessary. The second reason was that the company wanted to centralize IT and this manager had been picked as the poster child for why decentralized IT probably wasted money on suboptimal investments.  

Whether or not we want to admit some variation of this scenario plays out in organizations world wide every day, which means there are lots of poorly formed ideas walking around looking for funding.  Some we can kill in infancy through our standard project pipeline management processes but SOME need to be treated differently.  I have standard advice I give to clients on how to do this and I can guarrantee it works if done correctly BUT politics and process don’t make good bedfellows.  All the really interesting situations have varying shades of gray surrounding them and if the right people aren’t matched up to the situation then the process becomes nothing more than a bureaucracy.  

When I reflect on this situations one of the things that the company offered the manager was a “support resource”  with some “political” capital that could be used in service of the proposal.  An execution focused PM assigned to help build the value case in this set of circumstances would have been worse than useless.  To be honest it took me three tries to get something that made any sense to even propose.  The fact that I brought “political” capital into the situation let me convince the manager that his first two ideas weren’t salable to upper management.  The key here was that in this situation I was acting both as a professional who could develop good business cases and as a representative for upper management which allowed me to help filter out things that otherwise might have been proposed.

Returning once again to the politics of the situation.  After 90 days of hard work the final business case was presented to management and it was rejected as i knew it would be.  So did that mean I wrote a bad business case or that I should have done something differently to get it approved?  The answer is no.  The business case aligned, it had a value BUT the truth was that it simply didn’t make sense at the time.  An investment in the area the manger wanted to invest in was NOT the most valuable area for the company to spend money on at that particular time.  Essentially the business case was based on a “field of dreams” and what top management rightfully rejected it.

There’s lot’s more here that I could reflect on: the drive of professionals to push their own agenda and not see the big picture and the fact that we rarely admit that we don’t really have the right tools (and or practices) to solve a problem today (which we might be able to solve cheaply in the future when we do have the right technology.) are just two of the most obvious.  But these are all topics for another day

I was just reading the note on Foxes and Hedgehogs at Jim Collins website.  His assertion is that a hedgehog is focused and tends to adhere to a single unifying principle and a fox tends to flit from interest to interest.  He then contends that the world is split between foxes and hedgehogs with the hedgehog being the superior managerial animal.  Like everything else my view is maybe, maybe not (which of course implies that I might secretly be more of a fox than a hedgehog myself).  The problem is that I’ve run into PMs who have a completely closed view of the world.  There’s right and there is wong and the multitude of shades of gray, that I believe actually define the complexities of what they are trying to accomplish, simply don’t exist for them.  I’m absolutely sure there are situations where this attitude can be both positive and effective but I’m also sure that it’s impossible to manage an enterprise-wide program (that entails high change) in black and white. 

I love models, and I have to admit I was curious to see if I could fit the fox and the hedgehog dichotomy into my own core organizing principles.  The problem is that I just couldn’t make it work.  A good PM needs to have a set of organizing principles that can guide them through the complexity of managing in chaotic environment.  At the same time they need to be open minded and always on the lookout for the thing that is different (what Nadler calls the uniqueness principle) to ensure that they are actually delivering the right thing rather than the thing they think is right. 

it was an interesting flight of fancy for a moment but I think I’ll leave the world of hedgehogs and foxes to the estimable Mr. Collins.  There are other models that more closely fit PPM Leaders that I hope to explore another time.