pmStudent

Value

Do your stakeholders know?

How To Really Add Value

The Bean Counter

The Guru Who Won't Let Go

I'm going to make a very specific case today.

Let's review the Theory X / Theory Y models of McGregor, knowing full well they are just models. There is no purely Theory X or Theory Y manager.

Theory X

Assumes project team members:

• are lazy by default
• will avoid work if they can
• inherently dislike work
• will show little ambition without an enticing incentive program
• will avoid responsibility whenever they can

Assumes project team members need:

• to be told what to do, given structure
• to be closely supervised
• comprehensive systems of controls developed
• respond best to threat and coercion (carrot and stick)

Results in:

• blaming people before systems and processes
• culture of CYA (cover your a$$)
• hierarchical structure
• focus on compliance
• top-down decision making

Theory Y

Assumes project team members:

• find satisfaction in doing a good job
• enjoy challenging and meaningful work
• are self-motivated and responsible
• are creative problem solvers

Assumes project team members need:

• to be able to learn new skills
• to accept responsibility on a regular basis
• to exercise self-control and self-direction

Results in:

• evaluating systems for flaws before people
• flat organizational structure
• climate of empowerment and trust
• culture where mistakes are opportunities to learn
• focus on commitment
• shared decision making

Knowledge Work, Specifically Software Project Management

My verdict is that software project managers exist out there in numbers who are heavily geared towards the Theory X side of things. And that the more they are, the more their teams succeed in spite of them rather than because of them. And even when they do succeed, it's far below the potential of the team.

Now, what's your verdict?

Shim Marom posted an interesting metaphor using the Second Law of Thermodynamics recently to describe how tendency towards disorder is the norm.

I am also reading "The Black Swan" by Nassim Nicholas Taleb at the moment and am finding some interesting thoughts running both ways through my brain.

One one hand I see the evidence of self-organizing teams as a real phenomenon with the challenge of being able to use these dynamics of a social species to move towards a [predefined] goal.

On the other I am starting to see Taleb's point about how utterly terrible we are at predicting the future and planning for it due to our living at least sometimes in "Extremistan" although all of our models assume only "Mediocristan" exists.  Our expectations mess up project estimates and we are overconfident in our ability to plan.

Taking Shim's metaphorical lead, perhaps it can be said our goal as project managers is not to simply fight disorder by expending energy towards control.  Perhaps it is to find other forces available to us and use the natural order instead.   The curvature of space-time (gravity) and the electromagnetic and strong nuclear force can be used to naturally overthrow entropy, if only for a finite amount of time.

The shared goals and common interests of a team, desire to do good work, and a myriad of other factors common in the psychological makeup of most people of our social species can be facilitated and reinforced through the removing of interference.

By removing interference and leveraging the properties already inherent in a team of individuals, we enable the best qualities to surface and the most extraordinary results to be achieved.

Image by jurvetson via Flickr

The team is awesome.  They are smart, motivated, and want to do a great job.

The last project manager?  FAIL

You're the new project manager, and you're speaking to variances on a baseline that forgot what reality was last fall.  The WBS is structured to look nice, not to model the actual breakdown of work on the project.  The schedule was made to be convenient for upper management, not to be a representation of the actual work that has to get done.

Arrrrgh!

How To Cope

The first thing is to get a handle on your scope.  Without that, trying to manipulate a schedule is futile.  The WBS (Work Breakdown Structure) to the rescue!

Scared at what the reaction of the developers will be, you decide to sit down with them and create a WBS together anyway.  Oddly enough, a little while later you have a draft that looks pretty darn good, actually.  The team is already getting used to the idea that they can glance at this diagram to get a clear sense of what they need to deliver.

Now that your structure for work breakdown is solid, you can start breaking down the deliverables into the tasks it will take to produce them.  I do this in a BOE (Basis of Estimate).¹  Then, you can start to produce a schedule (at least a working schedule) that really tries to model reality.

Depending on the project environment you are in, you may be able to re-baseline the project right away or you may have to wait.  You may have to speak to variances for a long time however.

• Be honest - If you think the previous estimates were plain wrong, say so.  "Now that we know more information about x, y, and z our estimates are closer to reality (and well done in the BOE too).
• Find out what you can - In this situation it's helpful if you can find out what assumptions were made before you arrived.  In some cases there will be no documentation and you may have to guess.
• Be good to the team - I have seen some people in this situation try to blame the team for an unrealistic set of estimates, decomposition of the work, etc.  Nope.  Everyone contributes, but this is ultimately the PM's responsibility.
• Wow them with the "new way" - I don't normally recommend changing anything within the first 30-60 days of taking over a team....unless it's a train wreck.  In this case, your goal should be to wow both the project team and the other stakeholders external to the direct team with turning a fuzzy mess into crystal clarity.

What advice do you have for others in this situation?  Have you been in this situation yourself?

-Josh

¹ WBS Coach, WBS and BOE integration on page 50 of the textbook

Ty posted an interesting piece on leadership that I commented on, and am about to expound upon here.  He referred to successful project work being led, not managed.

I'm going to disagree, at least slightly on what may just amount to terminology.

Successful project-based work is led AND managed.

There is a false dichotomy between leadership and management that I often see. While it is true that you can be a leader without being a manager, and you can be a manager without being a leader, the highest state (for a project manager) to achieve is both simultaneously. As my former PM mentor and engineer Brian Bernhard used to say, it's the "genius of the AND".

A general, CEO, technical innovator, or scientist can get away with being a great leader and lousy manager if and only if they surround themselves with great managers. The general and CEO in that case rely on their vision and strategic capabilities, and the technical innovator and scientist rely on their ability to create movements through technical breakthroughs.

A team manager can get away with being a great manager and a lousy leader if the environment doesn't call for innovation or great leaps forward; change is infrequent and most of the activity is similar to the way it was the day before or last year. Here, you need a great manager who understands how to manage people effectively day-in and day-out.

For a project manager, you really need to aspire to having both qualities. With the change and constant need to generate and sustain momentum towards a common goal, you can't be successful for long without developing at least a minimum amount of both qualities.

 

Leadership is a sexy attribute that everyone wants to be associated with.  However, do not forget about the importance of effective management.  Frankly, I don't want to hire project managers who can not manage teams, stakeholders, and projects effectively.

To use a sports analogy, it's about blocking and tackling combined with inspiration and empowerment.  A good coach needs to be effective at both leadership and management, not one or the other.

We are project coaches.