Victus pro Scientia Opus -- Food for the Knowledge Worker

Putting More "ME" in "TEAM"

As someone who works every day with teams, some as long-lasting as a consulting practice team and some formed and dissolved as quickly as it takes to create a presentation, I always find it interesting to read research about what makes teams succeed or fail.

In the May, 2009 issue of Harvard Business Review, senior editor Diane Coutu interviewed (note: subscription or purchase required) Richard Hackman, a Professor of Social and Organizational Psychology at Harvard University and expert on teams.

I found Professor Hackman's insights on team dynamics fascinating, and expect to use them as both a participant and a leader of teams.  Some of the key insights I took away follow:

1.  Dissent is important.  An important role on the team is that of the deviant, defined by Hackman as someone who challenges the status quo, the person willing to incur personal cost to say things that nobody else will, the person who won't hesitate to say, "Why are we doing this at all?"  As the summary in another HBR article (from 2007) states, "The absence of conflict is not harmony, it's apathy."  Having social norms that encourage healthy dissent and lively debate, and an environment where people can feel comfortable hashing out ideas is critical.  Note:  Dissent is different from discord, which is divisive and corrosive.

2.  Don't underestimate the cost of newness.  There is significant research (by NTSB, NASA, and others) about the effects of inexperience in working together on team performance.  Plan for the "forming" stage in the group development lifecycle of forming --> norming --> storming -->  performing.  Leigh Thompson's work, such as her book "Making the Team," is worth reading for more detailed guidance. 

3.  Teams aren't always the answer.  In truly creative endeavors, too many participants may be more of a hindrance than a help.  Authoring this blog post would have taken longer to coordinate, and the key themes and message would have been diluted, if I had to develop them with a team.  Hackman challenges team leaders to find "the balance between individual autonomy [frequently the reason why people get into the consulting business] and collective action." This is one of the core challenges for any team leader in a creative field such as design, software development, etc.

I completed the article with:

• a renewed commitment to better define my teams' mission, boundaries, and members' roles;
• thoughtfulness about which tasks are best-suited to a team, and which to individual contributors;
• a desire to get the assistance of my partners in committing resources to organizational support, structures, and coaching to help all of our teams perform better; and
• a new book to add to my reading list:  Hackman's "Leading Teams."

Balance: Rigidity vs Responsiveness

I found this following quick post from a PMI newsletter to be a succinct summary of something I think about a lot, and try (with varying degrees of success) to articulate often:  how can an organization develop rigor in its operations without stifling creativity and responsiveness?

As our firm's SharePoint practice area continues development, documentation, and refinement of our methodology, I look forward to thoroughly and continually assessing the balance between rigidity and responsiveness to determine how to best serve our customers. I also look forward to thinking and writing more about this ongoing challenge, one that I've seen in every professional services firm I've ever worked with.

Research that is "Serious, Credible, and Cannot Be Ignored" about IT Project Failure

I read today a terrific post on ZDNet blogs by Michael Krigsman referencing a recent study about IT project success rates by The Standish Group, and a subsequent academic study that (to a degree) refutes it. 

If you're responsible for IT projects, you may find some of the conclusions and recommendations in here worth reviewing, and you may have some of your preconceptions about the ingredients for a successful IT project challenged.

Software Programming Inefficiency: I am part of the problem

I don't know how I found it.  It was one of those times when one just starts reading an interesting blog post or article, sees an interesting link, clicks through, and repeats that process, oh, 4 or 5 times.  [Note:  This is why the last 30 minutes of my work day often consists of closing stray browser sessions, I suppose.]

However, my browsings led me to an article entitled "Why Does Software Work Take So Long?" that, while not of recent vintage, held great interest.  About a year and a half ago, I joined a technology consulting organization that is much more developer-centric than my previous employer, where I worked most closely with the more application-focused and business-focused people.  I have worked hard to study the culture and work habits of developers as we work together to sell, scope, and deliver projects.

The article underscored that my work style, namely that of a project manager and business development resource -- multi-threaded, furiously paced, and interrupt-driven, is not a healthy thing for developers.  I suppose I knew from prior lessons (yes, went through some of that training) that this is not healthy in general, but it can be particularly acute when working with software developers, and the article explained to me exactly why this is the case, and what we should do about it:

1. track time
2. minimize extraneous interruptions
3. vary your work
4. build in time for breaks
5. establish rules about time and enforce them (especally on yourself!)
6. plan your work
7. leverage administrative support

This is all very basic "blocking and tackling" type stuff, but we all get into bad habits from time to time.  From now on (OK, for a while), I will be more conscious of the cost of my interrupting my colleagues frequently.  Of course, in return, I expect that they'll deliver more high-quality work faster...

Real-World PM Lessons

I attended a meeting of the PMI Mass Bay Chapter last night, and was wowed by the presentation by Al Goff, PMP, Program Manager for Systems for the Greenbush Commuter Rail Project.

The Greenbush Line is the second biggest public project in Massachusetts (after the well-publicized Big Dig), and represents a $500 million project to build 18 miles of single-track train line over a railbed mostly unused since 1959. If all goes according to plan, it will open for revenue service in September, 2007. Test runs have already taken place this spring, and the planned service levels will include 24 round trips per day (weekdays) between Scituate and South Station in Boston. The project will provide great benefits to residents of the South Shore in transportation options and transit-oriented economic development, but at no small cost. To give some examples of the scale of this project, the construction required:

• 28.7 million yards of rail
• 35 million pounds of concrete rail ties
• 300 million tons of stone, and
• 36 miles of fencing

Additionally, the demands of over 3,000 abutters had to be managed, and towns such as Hingham had to be accommodated with underpasses through historic districts at enormous costs in time and money (over $40 million for the underpass through Hingham Square alone).

Al presented some terrific real-world stories of his work managing this project , and although many of the lessons were specific to a large-scale construction project, there were many that translated into tasks most PMs perform every day, like:

• Task sequencing: "Make sure you acquire major land parcels FIRST. Revise your standards/specs for design/build, not design/bid/build."
  • Lesson: Identify critical path tasks and nail them early. Find ways to iterate faster.
• Stakeholder management: "Unknown stakeholders came out of the woodwork, such as those who walked their dogs on the railroad right-of-way for 35 years."
  • Lesson: Know your stakeholders, and plan for contingencies.
• Quality: "Is 99% reliability enough for a signal at a grade crossing?"
  • Lesson: Understand quality, and how your stakeholders define it.
• Human resources management: "Are processes in place to support you, or are you destined to fail? How will this project affect YOUR quality of life as a PM? Will it allow you to move between the technical career ladder and the management career ladder?"
  • Lesson: Don't forget about YOUR key stakeholders: yourself and your family. If you don't look out for them, don't expect anyone else to.