Life Before Retirement

Life Before Retirement

On This Date: Photo taken 3/26/2010.

A few days back Facebook’s “Memories” dredged up this comment I’d posted in 2010:

‘”What do you do for a living, Joel?” Go to meetings. 13 scheduled this week (so far), plus a doctor’s appointment….’

This was one of those meetings. Judging by the folks in attendance we were working on integrating our soon-to-be-installed IRP system with Finance’s accounting programs. Also judging by those attending I was there primarily as the management rep.

IRP stands for International Registration Program–license plates for trucks.


I took this pic with my phone, and the timestamps tell me that I promptly posted it to Facebook. I called it “Your Tax Dollars at Work.”

FB’s “Memories” gets the final comment, having found this for me today:

‘My work week in retrospect: One meeting added to the thirteen originally scheduled, one cancelled, one rescheduled to April, and two missed because I can’t be in two places simultaneously. Had a stretch like this ten years ago; never expected it to happen again.’

A few months later I retired.

Number of pix taken on various March 26ths: 203 [two of those are Joan’s]
Year of oldest photo: 2003

How I Rated the Date’s Photographs:

  • 1 Star: 2
  • 2 Stars: 26
  • 3 Stars: 145
  • 4 Stars: 29
  • 5 Stars: 1

Revision History:

Winter Through the Work Window

Winter through the Work Window

On This Date: Photo taken 2/24/2010.

For a dozen years or so this was the outside view from my desk. The window was tall, but this photo shows its entire width. Not a great view; not a bad view. At least I had a window.

Hiding behind that tree is a salt shed. Victor got a great photo of it last November.


I had this cubicle twice. A reorganization took me away to an upstairs cubby with a view of the swamp, but then we moved to another building and a desk without windows. A few months later I transferred back to this building, and soon reclaimed this desk.

Perspective: Joan worked in the same building for 40 years and never sat near a window.

Number of pix taken on various February 24ths: 138
Year of oldest photo: 2006

How I Rated the Date’s Photographs:

  • 1 Star: 11 [all smartphone focus failures]
  • 2 Stars: 11
  • 3 Stars: 96
  • 4 Stars: 17
  • 5 Stars: 3

Revision History:

Cheri, John, & John

Cheri, John, & John

On This Date: Photo taken 2/16/2006.

I mentioned a few days back that my job had “other responsibilities.” Among those responsibilities was supervising software tests.

We were about to launch the third iteration of a call center support package in February of 2006, so I borrowed an all-star testing crew from the Information Center to help the vendor’s rep, Jorge, put the package through its paces.

The session didn’t go well. There was something going wrong at the server, so we couldn’t complete transactions. This was pretty typical; I learned early on that the first day of testing usually revolves around getting the test system to operate correctly. Knowing this to be true didn’t make it less frustrating.

So Jorge spent the morning on his cell with his server team, and we spent the morning waiting. And staring at the computers. We adjourned at noon. The next day went better.


I took a bunch of photographs of this session, but only this one’s (barely) good enough to publish. The high number of 2-Star ratings, below, were largely the result of me rushing photographs during this test session. Even this one was rushed, but the damage is light.

Number of pix taken on various February 16ths: 35
Year of oldest photo: 2006

How I Rated the Date’s Photographs:

  • 1 Star: 0
  • 2 Stars: 14
  • 3 Stars: 17
  • 4 Stars: 4
  • 5 Stars: 0

Revision History:

Capitol Complex, with Smokestacks

Capitol Complex, with Smokestacks

On This Date: Photo taken 2/1/2006.

On the first day of February in 2006 I had an early afternoon meeting in downtown Lansing. I took my camera along and spent my lunch hour wandering around Michigan’s Capitol complex. This view’s down Walnut Street; the nearer building had been recently renamed for Richard H. Austin, and the one beyond it honors Lewis Cass. The smokestacks, a local landmark, are at the Board of Water and Light’s Otto E. Eckert power plant.

When I moved to the Lansing area, nearly forty years back, Eckert had six stacks. We thought those were tall until they replaced ’em with these monsters.

While I had other responsibilities, there were stretches–sometimes long stretches–when my job consisted mostly of meetings.


Number of pix taken on various February 1sts: 101
Year of oldest photo: 2006

How I Rated the Date’s Photographs:

  • 1 Star: 0
  • 2 Stars: 8
  • 3 Stars: 78
  • 4 Stars: 15
  • 5 Stars: 0

Revision History:

I’m Feeling Lucky by Douglas Edwards: a short review

This is a better book than I anticipated. Edwards–one of Google’s earliest hires–was obviously fascinated by Google’s founders, and the culture of the company they created. We watch as they repeatedly reorganize the leadership structure–an important concern for a middle manager–and as the author learns how he can contribute to the company. It’s an interesting, nitty-gritty view of the office (and its politics) from a privileged seat. This is well worth your time.

Google has resemblances to Carnegie Steel. Like Carnegie, Google is closely controlled, respects statistics, and is consciously disruptive. New technology is constantly put in place; failed projects are scrapped and forgotten. The leadership worries a lot about competitors, and embraces change as a competitive tool. Small edges are constantly devised and implemented, while big, industry-changing innovations are rolled out with astonishing regularity. Also: Like Andrew Carnegie, Sergey Brin and Larry Page are kinda preachy, and seem blind to some of the impacts and pitfalls of their colossus.

Andrew Carnegie eventually retired, and worked hard at giving away his fortune. His successors–JP Morgan allies–rebuilt the company into another model. It seems probable that Google will meet a similar fate, and that worries me far more than the casual arrogance of the company founders.


This short review was originally published on LibraryThing.

ExpressSOS

Michigan’s Department of State announced that the new website, ExpressSOS, is online today. The press release is here, and says all the right things.

Stand in line no more.

BAM’ll Fix It

Auditor General Thomas McTavish’s very critical assessment of the BAM project is available in PDF format from the State of Michigan website.


Since Michigan Secretary of State Ruth Johnson mentioned–and bad-mouthed–the Business Applications Modernization project in her speech the other day, I thought I’d follow up on an earlier posting. Please understand that I’m not defending the BAM project. I may (or may not) discuss what might have been done differently in some future post.

Secretary of State Building

Fair warning: This post discusses a system which hasn’t been implemented. Prior to the project’s web phase I was working on other projects, and only rarely an active BAM participant, so this post summarizes discussions I heard only second- or third-hand. I’ve also simplified things enormously to fit this treatment into a still too long essay, with the unfortunate consequence that I’ve ignored entire initiatives, made some difficult decisions look painless, and rendered some heated disagreements as settled questions. Finally: At no point was I a BAM project insider. Where I say “we” in this essay I mean The Department of State.

Introductory

The State of Michigan has been working with a vendor to replace the Department of State’s mainframe system, a key component of the State’s DMV. The vendor is HP, which you can find from their website (PDF), though the contract was originally with EDS. After years of missed targets, it’s fair to say we’ve proven that a system which took decades to build cannot be easily replaced. I’m reasonably comfortable with that, but my opinion’s not universally shared. Moreover, recognizing that the problem is difficult is very different from accepting an inadequate solution, which remains a real danger.

Yes, we might have done things differently. It’s likely we should have. This document is a description, not an argument.

Proto BAM

I mentioned a few weeks back that the Department of State’s management had concluded by the late 1990s that assuming a long-term future for our mainframe was untenable. It took a few years, and a new Secretary of State, for a project to completely replace that system to gain traction.

Terri Land was elected Secretary of State in 2002, and took office early in 2003. One of management’s recommendations to Secretary Land was replacing the Department’s mainframe with a more modern and maintainable system. After the new Secretary’s staff had digested that recommendation, knowledgable senior staffers were invited to brainstorming sessions, where we were invited to propose technological improvements for every existing workflow and to help define how those new systems should work. Those meetings’ notes, after considerable further digestion, became a formal proposal to consolidate nearly every Department of State technology initiative on a single platform. Thus was the Business Application Modernization (BAM) project born.

First BAM

BAM began with high hopes. Management believed the new system would address most existing workflow problems, and began to make staffing decisions on the assumption that the project would become available in 2006. 2004 saw the first mentions of BAM interfaces in purchasing contracts. Meetings with EDS staff became a regular feature of our work life. “BAM’ll fix it” became a mantra, particularly since the programming staff’s necessary involvement in the endless meeting made it still more difficult to implement even vital mainframe programming changes.

Unfortunately, the unending meeting soon made it clear to our participants that the vendor didn’t understand the basic problem. That the discussions opened at a high level was obviously necessary, but an oft-voiced concern was that their staff clearly wasn’t much interested in the details and complications which we understand as our job. “BAM’ll fix it” devolved into a running joke, and the initial project collapsed after two years of requirements-gathering and a clearly inadequate, unsatisfactory prototype. The contract was renegotiated, and EDS acquired Saber Government Solutions, a company with experience with another state’s DMV programming, to revitalize our effort. (This was a few months before HP bought EDS.) The project was relaunched as 2008 began.

Second BAM

Since the Saber team had previously worked on a similar conversion, they recognized that the details mattered. This worked far better, though Michigan’s differences from the other state sometimes provoked discussions which were, well, interesting. This project was plagued by obviously-unrealistic milestones and “deadlines,” but at least the still-perpetual meeting revolved around issues our staff actually considered significant. There was an inevitable retreat on project scope. Where the original objective was to consolidate nearly every departmental workflow and database in a single system, in the end the project became mostly an effort to replace the mainframe with a perhaps-better system having roughly the same capabilities, plus some few obviously-valuable improvements. Operationally, we’d be replacing one set of system quirks with another. This platform could be the basis for further enhancements, someday, but those would be some other team’s project.

One of the compromises was to initially implement BAM as a hybrid system, with much of the decision-making code, including Computer Decide, remaining on the mainframe. In trade we made a commitment to a more logical and efficient data structure. A new user interface, which everyone recognized would involve gains and losses, was agreed upon. This compromise was defensible as a tactical budget and resources decision, but it seriously undermined the project’s strategic rationale.

The Saber team began writing code, and members of our staff began testing the system. As is often the case with a major new system, the initial results were daunting. Almost nothing worked. There were simple coding errors, there were serious flaws in the design, and there were significant misunderstandings about our processes. Outputs were reliably poor in many dimensions. For the few routines and screens which did work, system performance was unacceptable. It was weeks before the testers were first able to run a transaction to completion, and months before they began to see acceptable results. Failures were reported by the main testing team, which was primarily assessing the branch office programming, and by folks developing interfaces between BAM and other systems. Thousands of defects were logged. Fixes tended to reveal new bugs, so more defects were filed. After a few weeks, even the most battle-hardened testing veterans were discouraged. The programmers plugged away at the problems, and in time the bug list became more or less manageable. But by that time many testers had grown weary and cynical. After months of logging defects, any testing team tends to be much more aware of unresolved issues than whatever progress can be shown. A life’s lesson, that.

Web BAM

Late in 2009 the most important of the agreed enhancements–a web interface which we expect will move many transactions out of the branch offices–was launched as a semi-independent project. The original plan was that BAM Web would go live after the main BAM system was introduced in the branch offices, but it became clear last summer that the web application would be stable before the branch system was available. This forced re-prioritizing the main project, as the web implementation required devising backend support processes to replace tasks which had heretofore been handled only over the counter. Sorting this out temporarily stopped coding for both projects, and disrupted the main project’s development plan.

Third BAM?

This paragraph is speculation. The clearest statements about BAM in Secretary Johnson’s speech are that the effort is still alive, at least in spirit, and that the web interface is important. I take this to mean they plan to build the web interface approximately as designed. Probably its back end will interact more or less directly with the mainframe, which will require some reengineering on both systems. What will happen with the rest of the project is likely still under discussion. We’ll have to see how things develop.

Edit 5/12/11: I’m told the web effort will be using the BAM hybrid back end, described above, which implies that the rest of the project will eventually be implemented as the hybrid is not a viable long-term solution.

Secretary Johnson’s renegotiate-the-contract effort is significant, but not essential to the project itself. She’s wrong, though, about what would be tolerated in the private sector. I’m pretty sure she’s letting ideology blind her to known facts. See this.

Future BAM

Everything an elected official’s staff does has potential political impacts, but this project was unusually political. Secretary Land had proposed to remake the way we do business, and fully intended to see the changes implemented on her watch. One result was an ever-present tension between the desires of the Secretary’s personal staff and the honest expectations of those working on the project. An example: When I retired on November 1 the officially-unofficial planned website launch was known to be mid-December, with the branch changes to follow over the following weeks. My fairly-informed opinion was that a more realistic expectation was an April kick-off for the web, and the branch changes perhaps by autumn.

BAM Web will likely launch later this year. I fully expect the rest of the mainframe-replacement implementation to eventually occur, because the alternatives are ugly, but it’s unlikely that this project will be Secretary Land’s BAM. The simple truth is that maintaining the old system carries similar risks to pressing forward with its successor, at the sacrifice of BAM’s potential benefits. I’m less sanguine about the eventual implementation of the original BAM plan’s ambitious vision of a comprehensive platform. Better, perhaps, to design ways to easily integrate external systems.

One hazard haunting any years-late technology project is the prospect of failure. That may yet occur with BAM, particularly since Governor Snyder and Secretary Johnson both seem skeptical about the project. A greater risk, though, is that after investing years of staff time and a fortune in dollars to develop this system, management will elect to accept a mediocre solution, with a vendor pledge to eventually repair the faults. Truth is we’ve a poor acceptance test track record, and a decades-long tradition of making do. We can’t afford that with mission-critical platforms.

Ms. Land no longer holds any public office. Here’s hoping Secretary Johnson introduces her at the press conference when the web app goes live.

Bureaucratic Whimsy

The Web is full of people who talk about their jobs. While much of that talk is simply bitchin’, some sites are more constructive. There are, for instance, many sites discussing technical work, and no few aimed at bureaucratic policy makers. Not many, though, discuss the daily realities of folks doing operational work at the middle management level.

Workspace

For most of my State of Michigan career I worked as a staff analyst supporting middle managers. Whatever that means. Even to those of us doing the work, describing the job is difficult. To the production staff much of what we do is pretty mysterious. We’re obviously busy, but much of what we can be seen to do–meetings and memoranda, especially–often seems quite pointless. We sometimes obsess about organizational politics. When we touch the staff’s daily work, the immediate result is usually disruption; that the disruptions are beneficial is not always obvious. Even to us.

Anyway: When I began this journal, my main purpose was to document the things I did for a living. I wrote these work-triggered essays so for about a year, then stopped. A few months later, as I moved the site to a new server, I removed most of the work-related pages, leaving only a handful of job-pertinent pages which didn’t directly touch on my job. I always planned to recover and repost the removed pages at some future date, and have now done so. They can be found in the site’s Bureaucratic Whimsy category (pigeonhole). A few have minor edits, and I’ve added an occasional explanatory note. Please be aware that all names (except mine) have been changed, though in most cases the identity will be obvious to folks who worked with me. These essays routinely simplify things, and sometimes leave out complications. But I always make an effort to accurately report the essence of the story.

I’m quite pleased with some of these notes:

This hardly exhausts the list. I’m hoping you’ll find something interesting, or useful.

Computer Decide

My first State of Michigan job was checking the output of a new computer program. That program’s clever moniker was Computer Decide, and it identified drivers whose record suggested they needed intervention–which might be counseling, a restricted license, a suspension, or some other sanction. The program detected patterns in driving records, and was probably considered cutting edge in 1977. I joined several senior clerks in the Review Unit, and was clearly playing out of my league. But that’s some other post’s discussion.

Computer Decide was the last, and most complex, piece in the Department of State’s initial drive to computerize its DMV record-keeping. It was also among the Department’s first serious forays into computerizing the business workflow–only a small step, mind you, but a necessary foundation. Our programmers would later build a system to schedule hearings on that base, and different coders would automate other processes. Some of this automation took place on the mainframe, of course, but we’ve since accumulated an array of systems on a variety of platforms. Many of those are now in their second or third incarnation.

But to keep today’s yarn manageable we’ll limit this discussion to Computer Decide. An unavoidable reality of DMV life is that the Legislature rewrites the Drunk Driving laws every two or three years. The Legislative package typically includes well-intended amendments to other driver licensing laws. The lawmakers rarely give much thought to the new act’s impacts on the driver’s prior record, nor to their predecessors’ attempts to improve traffic safety. This routinely gives rise to odd interactions which need to be implemented in the workflow–and written into the programming supporting that workflow. A side effect is that Computer Decide has grown quite complex. Mainframe programs supporting other departmental operations have similar issues, and have grown similarly complex.

By the late 1990s it was clear that this complexity had become a problem, and that the foreseeable retirements of the COBOL programmers supporting that complexity would, eventually, create a crisis. Maintaining the existing code had become their main occupation, and getting non-legislative initiatives off the ground had proven virtually impossible due to a shortage of expert programming staff. Equally worrisome was our vendor’s evident plan to reduce their corporate dependence on their mainframe product, which was the heart of both their business and our data store. Departmental leadership, recognizing these issues, began exploring ways to move to a new, less problematic, platform.

Where those explorations led is some other post’s discussion, friends. Not sure when I’ll feel comfortable sharing that story.


Ate breakfast recently with one of those COBOL coders. Mostly we had an old-friend chat, but we briefly discussed her replacement’s lack of experience with the system he’d inherited when she retired. That crisis is here….

Revision History:

Pensioned Off

Some notes for my last day of work.

Age 53: Identification

Michigan’s Governor and Legislature have claimed that a major portion of this season’s balanced budget charade was achieved by something they called Pension Reform. This is only half true, as the reform in question actually dates from 1997, when new state employees were first required to enroll in Defined Contribution (401k) plans. This year’s development is that the state government’s remaining Defined Benefits (traditional) pension employees are being encouraged to retire, which will reduce (at least for the short-term) our budget impact. I’ll leave the long-term impacts of the incentive’s pension increase, and the fact that my pension seems not to be properly funded, as an exercise for the reader. I offer a word to describe this political half-truth behavior, though: Irresponsible.

I’ve been a Michigan public servant for 33 years, and my responsibilities for the past twenty have mainly involved reducing governmental costs and improving our response times. I’m actually quite good at this, and one of the reasons is experience. I understand how the work flows in our department. I’ve considerable experience with designing, specifying, testing, and implementing systems (computer and otherwise) to simplify and automate paper-bound processes. I’ve helped move much of our business to the web–and a pair of web projects which have dominated my past year are scheduled to debut before the year’s end. I’ve worked with other departments to reduce friction on shared processes. My hypothetical replacement has valuable skills, but lacks my years of experience. She’ll bring a new perspective to the job, and that’s beneficial, but she’ll also make mistakes I’d have avoided.

Multiply this effect by thousands. Our Secretary of State Branch Offices (Driver License Bureaus, for those who aren’t from Michigan) will have fewer staffers, and on average those workers will have less experience. Joan’s sister’s a prison guard; her job’s risks will increase. This retirement rush is taking effect just as Michigan’s Treasury Department gears up for the annual tax rush. If your business calls a government office, expect the phone queues to lengthen; the person who answers the call will more likely be frazzled and less likely have your answer at his fingertips. Offices performing necessary inspections–in factories, on farms, of bridges–will be short-staffed and less knowledgable. Nearly every state office will lose staff, and the resulting stress will be visible.

Michigan’s state bureaucracy employs many folks who’ve spent thirty or more years in public service. Many of us were planning to retire in the relatively near future, with or without incentives; inevitably we’d be exchanging experience for youth in the process. On the whole, this is a good bargain. But this year’s incentive distorts the hiring pattern, as well as the retirement plans, and the impacts will be more obvious than they might otherwise have been. Again, a penny-wise, pound-foolish decision.

Enough. I’m outta here.