Meeting Minutes: As-Was or As-Is?

Considering that "making a record of what happened" is core to so many PM processes, it is always surprising to see how many PM-related meetings go by with no record.

There are a least four schools of thought with regard to minutes:

1. Minutes should be in sufficient detail that key stakeholders who could not attend can still get a good sense of what happened and why
2. Minutes should be very abbreviated, conveying little more than a listing of what topics were discussed and a record of whatever decisions were made
3. Minutes should reflect for future generations what was eventually arrived at and not why. Therefore, not only should they be abbreviated, but meeting members should be free to amend (and if necessary reverse themselves) after the fact 
4. Minutes are just another waste of time.  If anything really important happens, w can put it on an action-items list. 

Items 1 and 2 are the mainstream options, with Item 2 bring (in my experience) what most people do

Personally I believe in Item 1, consistent with my corporate slogan, "It does matter how decisions get made". More importantly, for future stability, it is also important to understand why a decision was reached and the points of view that the "no" votes might have offered.  Not so that later on we can point fingers and say "I told you so", but rather so that much later yet, another PM reviewing the record has the insight to avoid going down a particular path for the right reasons.

Reasonably detailed minutes have the following advantages:
(a) Most of the people in the meeting won't write anything down. No wonder actions don't get followed up on; why should they? Nobody remembers what they were ... until the next meeting, when they remember things rather differently from what they did agree to and everyone else already starting acting accordingly.
(b) One of the key people will likely not be there. Life is that way. Decent meeting notes will let them know where everybody moved to while they were out.
(c) At some point in the future there will be turnover. A quick read through of the notes of actual meetings, even of 50+ weekly meetings, will bring a person up to speed much faster than poring over dense and probably unused policy manuals.

In addition to the detail, check out Greg McKeown's post on the 30-second retrospective. And make sure you add whatever action is required to move forward on the the important point to your calendar.

It would be so tempting to dismiss Item 4 out of hand this line of thinking -- but it seems to be so prevalent. In fact, we'll spend another whole post on why so many people disagree with this ... and then do it anyway.

Item # 3 may seem facetious, but my very respected colleague Vic Rosenberg, a former CXO in a major company and executive coach, tells me that it is quite frequent, especially in (oddly) more mature organizations.  Since the formal meetings are somewhat pro forma (you don't go to them hoping to get approval, but to ratify what everyone already agree to), does it really matter who voted for what when, as long as the record is that "it was agreed" to do X?

What has your experience been on this?  Is Option 3 really all that prevalent?

Governance: where's the beef?

Alas, I betray my age by referring to a TV commercial that in its day everybody recognized instantly.

Most people in the IT consulting business know about Gartner and Forrester, the largest IT advisory services that I know of. When I worked at Gartner, I was always amazed at the volume and quality of the material and analysis that was available. Indeed, my role was to make it more accessible to clients so they would appreciate the value of their subscription, and a full-time role it was to ferret out all the nuggets that were sitting right there. My particular role was in the area of enterprise architecture (EA), which usually evolved quickly into other governance areas as well.

What struck me was how few successful companies are actually using that advice. I don't mean adopting blindly and wholesale, but at least taking at least some significant aspect of it and tailoring it to their situation. Gartner's maturity model, mapping to SEI-CMM practice, established a 5-point range where 1 is a freebie (i.e. "clueless") and specifically means the organization has nothing is place but has decided to conduct an assessment. So really 2 is the lowest score you can get. Their practice indicated (then, anyway) that in each sector of the governance business, their clients consistently average a score in the 2.x range out of 5, and their respondents seldom get above 3.x. And these are the larger and more successful companies on the planet.

If this governance business is all it is cracked up to be, surely an organization not using it would fall into chaos immediately?  Conversely, if hardly anyone is doing it, surely the company that decided to actually do it would shoot rapidly to the top of their pyramid?  If each of these governance disciplines is truly capable of generating meaningful bottom-line impacts, either by enabling new capabilities or at least making a dent in operating costs, how high could profits go?

Yet this is not done. I venture to suggest with some degree of inside knowledge of several august organizations, even by the very companies that sell these processes to others. Are these processes really engines of productivity, or just a consultant-industry self-employment scam?

If your company is one of those that does not, I imagine you'll be unwilling to say so in public, in which case you're welcome to tell me off-line why not, and we can add it in to this topic. Otherwise feel free to comment here starting with "Some organizations find that ..." :-)

If your company is one of those that has instituted on or more governance functions and sees it as a success factor, please let us know which ones and how they are working.

** Caveat: IT security is undoubtedly being practiced in most places, at least after some fashion, but even so it would not be wise to say what you are or are not doing. Organizations frown on this because attackers would love to read about what your security protections are and are not. So please stay away from that! **

Keep it simple is not for the stupid

We all know the KISS acronym. Keep it simple, stupid.  Carrying that out is -- well, not so simple. To paraphrase Benjamin Franklin, "I wrote a long letter as I did not have time to write a short one". Even a simple communication, such as this blog, can get longer than readers might desire. In case you don't get to the end of it ... does anyone have an example of a concise yet robust process for governing IT investments?

There is always the temptation to add a bit more detail in order to assist the end users in carrying out their responsibilities. Quite often what we really mean is the unspoken add-on: "the same way that I would have done it".  And even, "to make things easier for me". Even when our intent is truly to assist, it is almost impossible to provide for every contingency and the documentation required to do so often makes a rather simple primary process look formidable. Often, it is better to make clear what is desired and treat

Governance can also benefit from brevity. Elegance is nice, but it may take a long time to get agreement and much, much longer to get conformance even if people are trying to comply - and that is a big if. It is much more important to get some useful and truthful information in front of the governance board. Once they have that, the board members will start asking much more probing questions that introduce more sophistication into the process without the PMO having to mansate anything. That is handy when one has very little authority to issue mandates anyway.

Another key reason for trying to keep things simple is that thry need t fit into limited available time. One of the most important artifacts in the initiation of govrrnance processes is an integrated calendar. Like it or not, your topic area is only one of many competing for executive attention. The executive board is not going to meet weekly, probably not even monthly, to address your issue. Take a look at an integrated calendar - one that accounts for all the organization's major business processes - and you'll soon appreciate the value of getting even a quarterly dedicated timeslot.

One can overdo this. The recent fiasco with the Obamacare website gives clear evidence that a governance process that is fed inaccurate or incomplete information, and lacking the interest or know-how to identify obvious weaknesses, will lead to serious failures.  The hard part about making things simpler is retaining the critical essentials.

So the challenge: who has a good example of a concise but robust process for governing the selection or oversight of IT invedtments or programs?

Lessons from the polling place: the self-managing Scrum team

This week I had the privilege of being an election official in Virginia, and in the process I learned a little something about Scrum teams.

Election officers are a fairly close bunch.  Several have run the elections in their home precincts for decades. The hours are long, so people are going to be in close contact for some 18 hours.  The pay is only slightly above minimum wage, so people aren't really lining up to take the job.  In short, you need a bit of camaraderie and you really don't want to get overbearing and alienate a good poll worker such that they don't show up next time.

So what we had was a self-organizing team.  The county polling manual provides a fairly detailed SOP for election operations, but only a few of the provisions are actual legal compliance requirements; the rest are just best practices.  Most of the poll workers knew how to do most of the stations, and as people rotated around to deal with the situation of the moment or maybe just to give their feet or butt a rest, even the newbies got the hang of most of the stations pretty quickly.

The major complaint (there'll be another post on that topic) was the replacement of voting touchscreens with the old mark-sense form - talk about back to the future.  We didn't have too many problems to resolve but we did work our way through pretty much every exception case that the user manual contained and then a few more.  Almost every issue required the team chief to "take it off line" (to avoid embarrassing the voter) and often required several or many minutes to resolve.  Consequently, the chief could not have issued too many directions even if he had wanted to. The team just took the actions that needed to be taken and worked out its own task assignments and rotations, mostly by tacit adjustment.

Now at the end of the day, the rule book came back out to actually close the polls, accounting for all the ballots before running the results count.  Although this was tedious beyond belief for a very simple election, there was no grousing and no pressure to skip steps to get the workers out of there.  Some poll workers took it as their duty not to sign off on the results unless every "i" had been dotted; others took it as a point of pride that in case there was a recount (and as it turned out, there would) then the precinct staff would not be embarrassed by being found to have mislaid or miscounted a ballot.  Meanwhile the unoccupied team members just went ahead and put away all the gear, threw away all the trash, and so on.

So much to my surprise, I found myself doing cutting-edge team operations, even in the midst of a business in which the technology is actually regressing

Your customer wants a solution, not a process

In an related post, we noted some observations on the state of the IT business as seen by FedEx CIO Rob Carter.

One of those key points was that the way the company sees the world of business is encapsulated in its actual business operational processes.  In other words, as a customer, what you see is what you are going to get because that is the way the company is set up.

If you start discussing FedEx, one still thinks automatically in terms of the US Postal Service as the baseline. I am not one of those who insist on bashing the USPS just on principle.  In any enormous enterprise there will be a certain amount of bad luck or a couple of bad actors.  Remember, even six-sigma accepts that there will be some defects.  Delivering mail all across the country door-to-door is a pretty remarkable accomplishment, and especially for 50 cents.   It isn't really fair to ask for perfection, and it is true that over the years I have had FedEx mangle a package too, and ditto with UPS.  In fact, in over 40 years of dealing with USPS, I can think of less than 5 letters or packages that have gone missing (and a couple more that I thought never arrived but were later found under a piece of furniture in my own house).  Indeed, it is rather remarkable that anybody is allowed to use the excuse of the USPS losing something.  So the product itself is really quite superior.  How, then, is the USPS everybody's favorite pinata?  I believe that Rob Carter's observation is the point: the business process must not be allowed to intervene in the customer transaction.

Just last week in a venture capital forum, Priceline co-founder Jay Walker (@TedMedjay) noted that there is a vast difference between the company (the institution and processes by which you deliver a service) and the business (the delivery of a solution to the customer's need).  How very apropos to this discussion.  Once the process intrudes, the customer changes their view of the company from "service provider" to "mindless bureaucracy".

Now I am sure that the USPS would like to get my package from here to there in as convenient a manner as I wish to undertake (and pay for).  I know they are constrained by their mission, their history, their union and the US Congress. With friends like those, enemies are hardly needed.  But with the USPS,  for anything but a simple envelope that I can put in the mail, I have to go to their place - which is only open during bankers' hours, when most of us happen to work, or of course on Saturday when everybody else who works also has to go there.  When I get there, I much prefer to use the automat machine, which seldom has a line and usually works.  Usually.  In the nature of things, it tends to be out of order when I need it the most.  And there are a number of transactions that  one cannot do on the automat, which means (a) getting forms and materials and (b) waiting in line.  Forms and materials are often out of supply, and in 20 years I doubt I have ever seen one of their pens work, and this is all before getting a proper place in line.  Generally the staff tries to siphon off those folks who are doing a no-register action (mostly picking up a letter or package) but that too requires a clear departure from the normal process.  All in all, I have to be pretty conversant with USPS' processes to get even a reasonable result, and at every turn the process introduces itself.

FedEx is open 24x7 as a result of its partnership with Kinko's; they never seem to run out of boxes, forms or pens; and except for major holidays there is seldom any line at all at the times when I choose to go (which are deliberately off-hours).  While it is true that there are many conditions that make their job considerably simpler, starting with a more narrow range of services, it's also true that I do not have to be an expert  in their process.  For the  most part I don't even have to fill in their form; I can just hand the desk staff a piece of paper with the address written on it (and mostly they prefer it if I do so, and then they enter it in their computer).   This too I am sure USPS would do, but the truth is when there is a major line going on, which is usually the case, I don't want to inconvenience everyone else in the line behind me by having the postal clerk do every little thing for me.

The process is not the service.