Victus pro Scientia Opus -- Food for the Knowledge Worker

Lucid Ignorance and Project Process

This January, I learned three expressions related to my work that I want to share.  This post is about the first of the three, “lucid ignorance.”

On January 12-13, I was fortunate to be able to attend Microsoft-sponsored training in the Microsoft Solutions Framework (MSF).  As a self-professed process geek, whether it’s the PMBOK, client-specific process analysis, or any flavor of capabilities maturity model, I enjoy thinking about how people go about their jobs and create common vocabularies, and this training was no different.

The MSF is Microsoft’s standard framework designed to help lend structure to application development and implementation projects, and it’s a framework that we at KMA will be employing more aggressively in the days to come.

 

In addition to the overview of roles, risk analysis, phases, deliverables, and milestones prescribed by the MSF, a phrase our instructor used in describing project participants’ state at project initiation stuck with me:  “lucid ignorance.”  Lucid ignorance is used to describe our state during the “envisioning” phase of the project:  we have formed a clear scope and vision for the project, but we have yet to test that vision the way we need to in the planning phase:  by establishing technical feasibility, lining up resource requirements and risks within organizational constraints, performing high-level design activities, etc.  In other words, we're smart, and we know what we know, but we don't yet know what we don't know. 

The concept of lucid ignorance underscores the need to “re-baseline” the project during a rigorous planning phase.  The activities of the envisioning phase are sufficient to develop initial, order-of-magnitude estimates and an understanding of the “shape” of the project, but without planning and testing of our initial assumptions, we are still mired among “unknown unknowns.” It’s imperative that we re-assess initial estimates of cost, timing, and scope in light of things we discover during a more detailed planning process, and leave room to do this properly right from project outset.

If both scope and cost are locked in at the outset of the project, especially an application development project, proceed with caution!  Don’t lose track of the fact that, at that point in the project, all project stakeholders are lucidly ignorant.  The cure for lucid ignorance is another process-geek term (shocker!):  “progressive elaboration,” where the degree of uncertainty gets narrower and narrower as the project progresses.

Tappers vs Listeners

 
[photo credit:  "Morse Telegraph Key" posted to Flickr by public.resource.org]

 
Last week, I came across an article that resonated with me because of things I see all the time as a consultant. 

Many times, as consultants, we fall into traps that diminish our effectiveness.  One of these that I saw very nicely represented in a blog article referencing a book called "Made to Stick:  Why Some Ideas Survive and Others Die."

The concept was simple:  researchers performed an experiment with two groups of participants, tappers and listeners.  Each tapper was required to listen to a song, then to tap out its rhythm to a listener who had to guess the song without hearing the melody.  Even with the simplest of songs (e.g., "Happy Birthday to You"), the tappers expected the listeners to guess the song they were tapping 50% of the time.  The listeners only guessed the songs right 2.5% of the time.

As a team of technology consultants working with clients, we have a melody in our heads. We're working with technologies that we're comfortable and experienced with, we are deeply vested in the Microsoft community (and jargon), and we have a consistent approach to how we approach engagements:  implementations, migrations, training, architecture, etc. 

Our clients don't have our melody in their heads.  They are just getting to know us, just learning to trust us, just orienting us to their business and how their teams work.  On top of that, I find myself surprised by how often our clients' team members are getting to know one another in their first meeting with us.

The post was a great reminder to me about the importance of:

1. Spelling things out.  Our clients don't know the shorthand we use when we talk to one another, so we need to take extra care to ensure that our ideas come through clearly in our written and verbal interactions with clients.
2. Listening more and investing extra effort in building trust with the client.  We may understand their business problems by the time we're engaged on a project together, but do we know what motivates all our stakeholders?  Whether it's financial incentives, prestige, or other things that provide individual motivation, we have to invest the time and listen to what our clients care about.

So, a note to myself for the next kickoff meeting, presentation, or design session:   tap less and listen more.

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.