Selecting Means of Communication

Master Kan“Avoid, rather than check. Check, rather than hurt. Hurt, rather than maim. Maim, rather than kill. For all life is precious, nor can any be replaced.” — Master Kan (Philip Ahn), “Kung Fu”

I’ve seen a lot of different estimates of the amount of time a project manager spends on communication, but I’ve never seen an estimate below 70%.  So if we’re going to be interacting with others for most of our working day, we might benefit from a rubric for selecting our means of communication for maximum efficiency.

A rubric is used to assess a performance task, but it can also be used to determine the best approach for performing the task.  The table below describes a rubric for assessing planned communications.  Each element is associated with criteria, which correspond to numeric values.  Communication tasks with lower totals benefits from use of one-to-one communications, whereas somewhat higher totals benefit from one-to-many communications, such as Tweets or Email.  The highest totals benefit from many-to-many interactions, such as conference calls or in-person meetings.

3 2 1
Number in the Audience Many A few One
Proximity of the audience Distant In between Close
Physical distribution Widely distributed In between Co-located
Need for audience interaction High Moderate Low
Familiar with subject matter Yes Somewhat No
Potential for emotional reaction Low Moderate High
Complexity of subject matter High Moderate Low
Need for immediate response Low Moderate High

The goal of communication planning should be not to reduce the amount of time spent communicating, but to making planned communications as efficient as possible. Analysis by rubric can be very useful in preparing our project communication plans.  To paraphrase Master Kan: Speak face to face, rather than by telephone.  Telephone, rather than Instant Message.  IM, rather than Tweet.  Tweet, rather than Email.  Email, rather than schedule a conference call.  Conference, rather than schedule a meeting.  For everyone’s time is precious, and their attention and participation should not be wasted.
Dilbert Meetings a Waste of Time
I’d appreciate your thoughts on the rubric elements and criteria – I’m pretty sure my first pass can be improved.  Leave a comment below and let’s collaborate on it!

Thus I Refute #NoEstimates

In a recent blog post, Woody Zuill – fellow blogger, fellow middle-aged software guy, and fellow banjo picker – gave his personal definition of the #NoEstimates Twitter hash tag that has been the venue for a lot of online discussion lately.

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development.  That is, ways to make decisions with “No Estimates”.

Woody and several others in the Twitterverse and Blogosphere have been advocating for making decisions (more accurately, applying constraints) that don’t require estimates, in order to eliminate the need to make other decisions that would require estimates.  Neil Killick recently posted an explanation of how to do Scrum without estimates, including this example:

Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint).

Implicit in the example is that, once time and schedule are fixed, only the scope is flexible.  While this would certainly make things easier for the software developers, it adds complexity for everyone else.  To explore Neil’s example, let’s assume that the Australian Open app is a public-facing, self-service web site where the general public can buy tickets, see the daily results, read and comment on the news coverage of the event, and possibly follow links to the personal web sites of the players.  But what else is involved in serving the public audience interested in the Open?  I ask because, in the real world, not all members of the public are going to use that web site.

Presumably, the Open will have a call center to handle inquiries and purchases from those who don’t find or can’t access the web site.  They may also have an interactive voice response (IVR) system to support certain kinds of queries and possibly even ticket purchases.  So the Decision Makers will want to make the Australian Open app fit into this operational framework, providing capabilities and services for the public that supplement or complement each other.  To do this, they need to have a firm list of capabilities (or scope) defined for each of the three projects – Call Center, IVR system, and web app.  That way, they can staff the Call Center appropriately, work with the marketers to provide instructions to people when directing them to the IVR or app, and otherwise direct user traffic.  But if the Call Center folks and IVR configuration team don’t know until three days before the Open starts what functionality the web app will have, that doesn’t leave them much time to react, does it?

Of course, it might be wise for the Decision Makers to conduct a “buy or build” analysis, since large events are quite common and have spawned a number of service offerings, including Software as a Service.  But in order to conduct that analysis, they would need a firm feature / capabilities list and cost estimate for the internal development effort, to compare it with the vendor offerings.  And if all the internal developers can commit to is cost and schedule, it makes comparisons impossible.

A group of frogs who live at the bottom of a well are enjoying their nightly chorus of croaking, when one of them announces that he is studying astronomy.  When he gets a quizzical look from one of his comrades, he explains that it is the study of the sky.  “You know: that little round thing at the top of the well.”

Complexity will persist in the face of all attempts to reduce it through simplifying assumptions.  Few modern business problems are simple enough to reduce to a small number of decisions, which then drive all other activity.  Apples falling out of trees are fine for explaining gravity to school children, but celestial mechanics has to contemplate multiple bodies.  Similarly, modern business problems are not simply about software.  And that is why we should devote our energies to improving the quality of our software development estimating methodologies, rather than advocating adoption of simplifying assumptions that don’t reflect a holistic view of the operating environment.

Even Data Needs a Green Mentality

I just watched an interview with Kate Parson, a Senior Director at EMC.  She was talking about Project Propel, which replaced their two decade-old ERP solution with a nice, shiny new SAP solution.  The part that really caught my attention was her statement that, early in 2012, they had to start deleting tables in their database, because they ran into “an integer limit.”  They had accumulated so many records that even Oracle couldn’t handle them.  Yes, you read that correctly: EMC, provider of massive storage solutions, couldn’t handle the sheer volume of data records they had accumulated.

I make my living moving customers off of old HR, payroll, and benefits administration solutions and onto a nice, shiny new one in the Cloud.  Naturally, a big chunk of every project is moving records from the old solution to the new one.  We always recommend that customers only move “current” records, rather than attempt to load history.  While you need to retain history records for some period of time, they don’t need to be kept commingled with current records, in the system of record.  They can be stored in off-line databases, with restricted access, or as reports, on paper or in PDF format, or any number of other approaches.  But whatever approach you use, at some point those records will need to be destroyed, in accordance with your organization’s record retention policy for that sort of data.  You guys have a record retention policy, right?

We need to adopt a “Green” mentality for data records.  We need to make proper disposal of old records that have come to the end of their useful lives as much a part of system design and maintenance as disaster recovery.  Ensure that you have a plan to move records from on-line to secure off-line storage at some well-defined point.  Ensure you have the ability to later purge them from off-line storage.  Ensure these activities are scheduled as part of the annual operations calendar.

Of course, some records may need to be retained past their normal lives because of a court order, as part of a legal dispute.  And some types of records may be subject to summary analysis as a class or group, rather than a simple look-up (think Lilly Ledbetter or other sorts of class action lawsuits).  This is why your legal counsel should review your record retention policy, to ensure you keep records as long as required, and no longer.  So the selection of the proper storage tool set for history records has to take into account the potential need for these contingencies.  Be sure you understand all possible uses (and customers) for history records before you settle on a storage medium.

The bottom line here is that proper stewardship of the organization’s data records requires a life cycle mentality.  Just as you have a plan to destroy old hard drives (you do, right?), you should have a plan to manage destruction of old data records.  At some point, all of that data quits being an asset, and becomes a liability; legal, technical, or administrative.  Recognize the risks, and treat them as such.