A Needlessly Complex User Experience

VTA ElevatorOn the right is a picture of an elevator at the VTA Light Rail station at the Great Mall, in Milpitas, California.  It allows people with limited mobility, or those traveling with bicycles, to travel between the station and the sidewalk below. You might expect that an elevator with only two stops would have a relatively simple user interface. After all, as a user, you only want to go from the stop where you boarded to the other stop. One button should suffice. But, no – the user experience is painfully, needlessly complicated, by imbedding control surfaces and indicators for the most common use cases in amongst the more rare use cases.

Discoverable With Difficulty

Control PanelAs you can see, the control panel is festooned with buttons, indicators, key-operated switches, and labels. The prominent red button is for emergency calls; if you press it by mistake, you need to somehow find and press the Call Cancel button in the upper right, in a different control surface group. Directly beneath the emergency intercom button are two buttons, with white on black labels to the left, “P” and “*S. “ Squinting at the engraved label above the Braille instructions to the right of each button, you will realize that “P” stands for “Platform” (not “Parking”) and the starred “S” stands for “Street Level.” It’s not clear why the platform doesn’t merit a star.

Side-by-side and below the starred street level button are buttons to Open and Close the door; immediately below the Open button is an Alarm button.  To the right of the Alarm button is a key switch, to lock the doors. Below this is a recessed section with eight more key switches, an indicator lamp, and a 110 VAC duplex outlet. At the top is another key switch, labeled fire service, an indicator, and a jack for a Fireman’s Phone. No doubt, each of these controls and features is required by law, safety regulations, elevator design convention, and the manufacturer. They just aren’t particularly beneficial to members of the traveling public, who actually use this elevator.

Needless Complexity Impedes Value Realization

If you board the elevator at the platform level, nothing useful happens until you figure out that you need to press the starred “S” button.  However, you have two different ways to upset someone manning a remote control console, even if you didn’t intend to. Making the emergency intercom button so prominent and positioning it so close to one of the two most-used controls guarantees a high number of false calls.

I applaud the use of labels in Braille; however, labels for the sighted majority should be prominent, rather than small engravings, subject to wear. Abbreviations and symbols should be instantly recognizable, or they are simply a source of confusion. Far too much effort is required for the casual user to get value from this elevator; there are far too many failure modes, valid choices with no result, and unavailable choices in close proximity to the useful choices. But the most important lesson here should be that compliance with standards and other non-functional requirements is not an excuse to deliver a truly wretched user experience. Would you use software that had a UX like this? Would your target user population? We expect our interactions to be obvious, rather than tedious. Time to value is the difference between acceptance and rejection of a product.

Next time, I’ll take the stairs.

Managing Auditability (and other non-functional, non-technical requirements)

Magnifying Glass ManOne of the most common causes for IT projects to slip into “troubled” status is missed requirements. In many cases, this is because the subject matter experts don’t think of all at the functional requirements at the beginning of the design stage. In other cases, technical requirements may be “discovered” during the execution stage, when the team starts to build the system that will deliver on the functional requirements. But while there are clear sources (and advocates) for functional and technical requirements, there may be requirements which are neither functional nor technical, and the sources for these requirements may not be advocates for them during the course of the project. In many cases, advocacy must fall to the project manager.

Consider the following attributes of a modern transaction processing system, whether located on a server in the corporate data center or delivered as Software-as-a-Service in the Cloud. Requirements associated with each of them may be a consideration for your next information technology project.


Auditability is the degree to which transactions can be traced, from originator to approver to final disposition, through a system by an auditor. Part of auditability comes from system documentation, and part comes from visibility of all integrity-related modifications to the system and to data records. Logs should make it possible for the auditor to determine who did what, when. Auditors may be either internal or external to the organization. Once you’ve identified who will be the auditors for this system, work with them to ensure it will meet their needs. Naturally, they’ll want to validate and document that it does.


System security refers to the control of access to a system’s resources, including both programs and stored data, to safeguard the integrity, authenticity, and confidentiality of the data and operating processes. Security is implemented though a combination of internal controls and software, according to relevant standards and policies. Your organization may have a Chief Information Security Officer, whose staff is responsible for setting security standards. Work with them to identify relevant security controls, how to implement them as procedures, and how to validate that they work correctly. The Auditors will almost certainly be interested parties, so keep them in the loop.

Records Management

Most transactions are recorded for a specific purpose, and have a limited retention period. The record management policy for a particular record type should dictate when a record becomes obsolete, and must be purged. In the event of litigation, a court order requiring preservation of records may override the policy. Work with your Corporate Counsel or Chief Administrative Officer to identify the relevant policies and retention periods, establish procedures for requesting, approving, and documenting the destruction of obsolete records. In the case of compliance with a court order, ensure you have procedures to document the chain of custody, and control access.


If your project is replacing a legacy system with a nice, shiny new system, part of your scope may be to plan for retirement of the old system. This may involve a number of tasks, including: purging obsolete records; archiving records not yet obsolete and not moved to the new system; notifying any number of interested parties; and ordering the removal and disposition of the servers. Work with the data custodians and the data center manager to identify the subject matter experts and conduct a stakeholder analysis. As you’ve no doubt realized, Retirement overlaps with Auditability, Security, and Records Management. Ensure it’s a part of those conversations.

Final Thoughts

While these aren’t the sexy parts of an IT project, missing these requirements can still delay your project or put it over budget. Make identifying the sources for these requirements part of your planning process, and ensure that your project budget and labor estimates reflect the level of effort required. If not, get out in front of it with a scope change. Your sponsor will (probably) thank you!

This article was first published March 31, 2014 as a guest post on PM4Girls.

Received Knowledge, Fanaticism, and Software Consultants

Professor Harold HillBack in the 70’s and 80’s, when I was a young coder, you could generally group programmers into two camps: those who thought that the GOTO statement was evil (including such luminaries as PJ Plauger and Edsger Dijkstra), and those who thought it was perfectly acceptable, when used responsibly (such as algorithm guru Donald Knuth). Of course, by the late 80’s, we were all migrating to object-oriented languages, and the notion of structured programming seemed … quaint. Objects were going to free us from the anarchy of procedural code, just as relational database management systems freed us from whatever-the-Hell we’d previously been tinkering with.

But a funny thing happened on the way to high-quality code: bad coders. Oh, there were always bad coders. We simply pretended that the problem was our choice of programming paradigm, and that Bjarne Stroustrop’s preprocessor would suddenly make lousy C programmers into great C++ programmers.  Of course, it didn’t.  So some other coders-in-denial created Java, with the intent of encapsulating great code into packages that could be called by lesser practitioners. It was an incremental improvement, but it opened the career door to many more programmers. And many of them were also bad coders. IDC recently estimated that there are now eleven million professional programmers in the world, and nearly eight million more that they refer to as “hobbyists.” Not me; not any more. I moved on, a long time ago. I just got tired of repairing the software equivalent of a film by Troma Studios – as one critic memorably put it, “dogshit with sprocket holes.”

“Ninety percent of everything is crud.” Theodore Sturgeon

The rise of Agile methods, as they are now called, began well before the 2001 conference in Snowbird, Utah that produced the Agile Manifesto. Scrum and Extreme Programming were in wide use, even as we were correcting old dogshit code in preparation for the year 2000.  The serious improvements came from XP’s pair programming and test-driven development. As long as you didn’t pair two bad coders, you got better code, and eventually, better coders. Then came Snowbird, and the Manifesto, and the Agile Coaches. And the obvious Pareto-truth, that 80% of the bugs were being inserted by 20% of the coders, was papered over in favor of Yet Another Salvation Myth.

Instead of focusing on the coders, the consultants wanted us to focus on how we organized, and planned our work. It wasn’t the coders’ fault that their code sucked – it was the way they were being managed.  The words “traditional” and “waterfall” became epithets, used to describe the reactionaries who would have us focus on code quality, rather than methods. The new word was “refactoring,” which sounds less judgmental than “we have to replace this unmaintainable, write-only, dogshit code.” Yessir, the real problem was project management, and (lately) this fixation on providing cost and schedule estimates. And all of these proof-free assertions fed on each other, until it seemed like you weren’t a real Agile coach unless you dismissed project management, not just for coders, but for all human endeavors. I recently had the temerity to say I wouldn’t want to fly in a commercial aircraft designed using Scrum, and was tut-tutted by a True Believer who reminded me that many modern software practices have their roots in auto manufacturing practices. Not “design,” but “manufacturing.” Egad, have you even read The Scrum Guide?

So I got quite a chuckle this morning out of Nick Pisano’s rebuttal to Neil Killick’s recent expansion of the War on Management, demonizing the “traditional” software contract. It’s bad enough that Neil and his fellow Accusers insist that any approach they don’t like is “command and control;” now they’re going to prepend “traditional” to software contracts? Intolerable! Nick shredded Neil’s assertions, admirably. I was still laughing when I sat down to write this, late in the evening.

To be clear: I embrace the values in the Agile Manifesto, as do most software project managers. I embrace Scrum, as an effective method of organizing small teams of software developers to deal with uncertainty. I follow Neil’s blog, and Tobias Meyer’s, and several other Scrum-lord blogs. They know a lot about Scrum, and modern methods. That they are wrong about other things is immaterial. I have no problem with them dispensing received knowledge and calling it science. Of course, I feel no particular sympathy for the lousy coders who find affirmation in their anti-PM blather, nor for their more skilled colleagues who enable their inability by cleaning up after them. As long as the ratio of chaff to wheat is tolerable, I have no objection to separating them.

But I fear that, until the competent software developers address the real problem – bad coders – we will still be fixing dogshit code, under one procedural name or another, for a very long time to come (“Technical debt?” Coder, please …). And since I am a project manager, I have to point out that these competent coders are thus assuming a risk they could easily avoid, if only they weren’t in denial.