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.

ACA/Obamacare website team develops new extension to Brooks' Law

*** Updated: The IRS system to support Obamacare/ACA does work.  As a result of which we learn of yet another hole in Heathcare.gov.

Some day the political furor over the introduction of government-run health care will simmer down, and it will either start working or we will be stuck with it anyway (since that's the way government works).  At that point, academe will be free to climb down from its partisan cheerleading role and do some actual research into the issues that surface every month or so [or perhaps into the reasons why the issues do not surface until then], at which point Healthcare.gov will be included in every textbook as the defining case study on governance issues.  Meanwhile, you can look into governance issues via this blog ;-) ***

In "The Mythical Man-Month", Fred Brooks posited what has come to be known as "Brooks' Law": adding resources to a late project simply makes it later.  The reasoning is that the existing team now has to stop much of what it was doing to explain what is going on to the newbies rather than getting on with the actions that they already know they need to take.

The Affordable Care Act (better known as Obamacare) website project has recently undertaken what it calls a "surge" -- somewhat ironic, considering Obama's opposition to the surges in Iraq and Afghanistan -- to correct the problems in the ACA healthcare website and enrollment process.

At first sight this would appear to be an interesting and very public case study in whether Brooks' Law can be overcome. But Brooks' Law talks about technical resources, and it does not appear that the repair concept is about adding any significant numbers of contractors (i.e. developers or testers).  On the contrary, the contractors (in a display that was certainly unique in my experience) threw their contract-holders under the bus and claimed that the only resource lacking was project management skills on the part of the government.  Indeed, the primary change appears to have been the assignment of OMB Deputy Director Jeff Zients to give the matter his attention.  At least he has evidently taken one of the elementary steps of project management, which is to hold a review to determine what the plan actually is, what the status is, and what the issues are.  Elementary, perhaps, but we are to gather that this is concept is entirely novel for this program.

So it would seem that HHS and OMB have developed an extension to Brooks' Law - we can call it the Zients Law:  "while the addition of resources could delay a project, bringing a project manager on board may well be a necessary condition of getting a project back under control."

*** Update:  Within days, Zients announced that the web site would achieve full operating capability in 30 days, a breath-takingly remarkable assertion. Even simple things in government take more than 30 days. At the end of 30 days there was no announcement of anything: the manual enrollment process continued, and Zients slunk back to OMB with no fanfare.   In January 2014 the enrolment figures zoomed -- as the result of a back-end process moving millions of people from Medicaid to ACA.  

To be fair, Zients, or somebody, did put a lot of project management things into place.  A new contractor was brought on board at the turn of the year and they must have done a bang-up job because within weeks (March), more or less in the nick of time to meet the enrollment deadline, the website apparently handled several million last-minute on-line enrollments, thereby proving both the financial viability of the program itself and of course the technical viability of the website ***

I'll go out on a limb here and say that if (as claimed) senior executives and appointees never inquired into the status of this administration's number one domestic policy initiative, then they are so incompetent as to deserve removal for that.  On the other hand, if the project managers at any level were fully aware of the issues and chose not to pass that information up the chain, or worse to alter it, then they need to be terminated - not "allowed to retire", but terminated without future pensions and be darned glad that they are not being subjected to recoupment of the cost of this botched effort.

*** Update: CIOs are required to certify the condition of their major investments on the Federal IT Dashboard. It's managed by OMB -- which is part of the Executive Office of the President -- and it's quite a big deal. Lateness is not tolerated.  Except, apparently, sometimes.  The Dashboard, which is publicly available -- usually -- reveals that in January 2013 the project was suddenly listed as RED because -- well, because it wasn't passing planned tests.  The following month it went back to green.  In August 2013 (right about the time that the September rollout issues with Healthcare.gov HAD to have become obvious to anybody working on it) the ENTIRE Federal dashboard reporting process simply stopped.  Coincidence? Well, I guess you can't show a RED on a dashboard that isn't being updated, now can you?  Maybe Zients, as the OMB Deputy Director, knows how that happened.   Anyway in April the data stream started back up again.

So who's been fired?  Well, nobody.  A couple of people have been retired in regular order and Secretary Sebelius moved on amid the usual political and media swooning about her greatness.  The contractor was eventually replaced by another based on its track record of having done a similar project for one of the states (well, there's a good idea -- except that later it transpired that the state's exchange wasn't doing so well either). And 6 months later we learn that system has been making millions of dollars of erroneous payments of subsidies.  It is not the system's fault that the subsidies themselves are also coming under scrutiny as to whether they are legal at all  How do we know any of this?  Because the IRS system supporting ACA, which does work, is finding discrepancies in tax returns between the filer's incomes, the subsidies to which they are entitled, and the subsidies they have been getting.  So the technical solution is not impossible to attain; the IRS has already figured it out. ***

Metadata more important than the payload? Exhibit A.

Noted in an earlier post, FedEx founder Fred Smith regarded the company's data about its packages as more important than the packages themselves.  How can this be?  Isn't the reason people use FedEx that they trust the company to handle their treasured packages with a bit more care and accountability than the alternative.  As with all worthy epigrams, the seemingly nonsensical and heretical remark contains some deep truths.  Of course I expect FedEx to value the actual package.  The point is that there is not much real value in taking very good care of the package if you don't actually remember where you put it.

This one certainly strikes home for me.  I've certainly experienced the opposite effect.  This isn't really a bash on United Airlines - after 18 years I've gotten over it - sort of, although apparently I remember every grim detail so maybe not.  But it is a great illustration of Fred Smith's point.

When my wife and I left for the UK on our honeymoon, the trousseau came along in two checked suitcases.  I only needed one for my clothes, and you should have no trouble guessing which one of the 3 bags actually made it to the conveyor belt in Heathrow.  Bad enough that we had to go purchase emergency gear in one of the most expensive cities in the world, but then because United (yes, you get named here) had absolutely no idea where these bags were, and very little system-wide data visibility, we had to go stopping into their office almost every day for 2 weeks in order to try and get some information and to pick up our daily ration of $20 which of course does not last more than a few minutes in London.  Needless to say, my better half was not showing up for multiple nice events in the same outfit, so I was in hock for several nice Peter Jones outfits by the time the trip ended.  Ouch.  But it gets worse.

The only consistent information we got was that eventually, all the bags they cannot repatriate with their owners are eventually carted off by policy to the Bag Mountain in Chicago, so at least after 3-4 weeks we would know where the bags were ... if, of course, United still had them under control at all.  On returning to Dulles airport, it occurred to me to stop by the baggage desk in case there was an update on the situation from within the US where maybe the interoffice communications were more effective.  By golly, yes!! The bags had been found and flown off that very morning ... to Chicago.  This was actually recorded in the same electronic file that documented the effort made to date to find the bags, so the only thing I could not work out is why (being in possession of my itinerary) they didn't just hold them and give them to me that very day.  The airline promised to get them back from Chicago on the next flight and I went home shaking my head.  At least the new clothes would last a long time, and indeed they did.

The adventure was't quite over.  I got home to find a dozen messages on my answering machine (that'll date you!) beginning an hour BEFORE the original flight saying they had my bags at Dulles and would I be home to accept delivery.  What??!!  How does THAT  not show up in the bag record?  So at any time in the prior 2 weeks they could have put the bags on a flight to the UK, which would have saved me a couple of thousand dollars and endless aggravation.

The metadata was definitely more valuable than the actual package.

I don't think there's value in a bunch of comments flaming United Airlines in particular, but I'd love to have your comments with examples of other cases where the metadata is indeed more important than the payload.