The Antidote to Value-Destroying Vanity Projects

Choosing the solution that is 100 times more expensive sounds absurd. Nevertheless, that is what the U.S. Congress has decided, which is why NASA is struggling to get its SLS rocket off the ground. It has nothing to do with putting a man on the moon and everything to do with keeping the big NASA factory in Alabama running. They don’t have the technology to compete with newer space companies like SpaceX but are cobbling together old Space Shuttle parts. They’ve actually been going around to museums in the U.S., taking out old space shuttle engines for the quixotic project foisted upon them by Alabama Senator Richard Shelby.

Some organizations face a similar challenge: The CEO or someone else in senior leadership has an idea for some technology, and IT is ordered to deliver it. It doesn’t matter if such a vanity project is practical, feasible, or cost-efficient. You cannot fight this kind of project individually because they are highly connected with the ego of one individual.

The solution is to establish a standard evaluation process for technology projects. Every project needs a business owner responsible for calculating the business benefit. Every project also has a technical owner responsible for calculating the cost, including the ongoing running costs after completion. If the benefit comfortably exceeds the cost, the project is qualified to enter the competition with other claims on company investment.

You might not have such a process because a rational decision might also kill some of the IT department’s most beloved resumé-enhancing projects…

Thinking is Better Than Buzzwords

Thinking is hard. That’s why we substitute platitudes whenever possible. I was reminded last week because the election campaign has started here in Denmark. The young politicians on the left don’t know what to do about the increasing grocery prices – nobody does. But they do know that monopolies are bad. IF something bad happens AND monopolies are bad THEN monopolies cause the bad thing. The problem is that Denmark is the country most over-supplied with supermarkets in all of Europe. Calling the six different chains a monopoly means you are substituting critical thinking with a buzzword.

The same thing happens in IT. I keep seeing IT organizations whose strategy is decided by the buzzword of the day instead of actually thinking about your business needs versus the skills and resources available.

Learning from the Mistakes of Others

Learning from your mistakes is good. Learning from the mistakes of others is better. One mistake that often occurs in projects that include any kind of software is the lack of sanity checks.

For example, hackers broke into Yandex Taxi yesterday. They ordered every available car in all of Moscow to the same address. The result was a humongous traffic jam on Kutuzovsky Prospekt that took more than two hours to resolve. A sanity check would limit the number of cars that could be sent to the same address. Many of the recent failures of self-driving cars and trucks would not have happened if the software had sanity checks.

Do you have a process for sharing stories of things that went wrong? Whenever you have a meeting, have someone tell a story about something that went wrong and discuss what you can learn from that in your organization.

You Need an Agile End Result More Than an Agile Process

An agile development process is not important. An agile end result is. If your organization realizes a benefit from an agile methodology, that only helps you during the relatively short development process. But if you build something that can easily be re-configured and changed, that benefits you for the year or decades that you are running the system.

You would think that a digital billboard would be agile. The whole point is that it can display whatever you want. But German advertisers and shops have just realized that their display screens have very narrow agility. A new law requires these energy-guzzling billboards to be switched off at night to save electricity. It turns out that all the devices were built on the assumption that they would always be on, and they do not take kindly to store employees simply yanking the power cord when they go home.

To achieve agility in your products and systems, you need to avoid hard-wiring your assumptions into them. The only thing you can safely assume is that everything will eventually have to be changed.

What do you incentivize?

You get what you reward. Twitter decided to primarily reward user growth, and things went downhill from there. Recently, their head of security quit. Then he filed a whistleblower complaint with the authorities, complaining that Twitter’s security is bad and not getting better. Now there is likely to be a very interesting congressional hearing.

White-hat hacker Peiter Zatko (aka “Mudge”) was hired after a 2020 security breach but could not implement the changes he felt were necessary to fight spam and automated bots. The reason is the incentive structure at Twitter.

You see, Twitter management bonuses are based on user growth. There is no bonus for reducing spam or automated bots. You get what you reward, with no exception. You can reward with money, perks, promotions, or other recognition, but you have to incentivize the behavior you want. If all your incentives are based on quantity and not quality, you will get ever-increasing quantity and ever-decreasing quality.

Do You Want Fancy, Cheap, or Usable?

Do you prefer fancy, cheap, or useful? Car manufacturers have found that touchscreens look fancy and are cheaper than physical buttons. That’s why modern cars have touchscreens and no buttons. I prefer buttons, and science is on my side. A survey shows that it is almost twice as fast to perform common car tasks with buttons than with a touchscreen.

Unfortunately, a car is not required to be easy to operate. Aircraft cockpits, on the other hand, are full of physical buttons. An aircraft manufacturer accepts the extra cost of physical controls to provide an optimal user experience for the pilot.

Marketing wants fancy. Finance wants cheap. User Experience wants usability. Who has the last word on product design in your organization?

Set Mandatory In-Office Days

It’s back-to-the-office time even in Cupertino. Apple has announce that starting Sept 5, employees are required to be in the office at least three days a week. Tuesday and Thursday are mandatory in-office days.

It is a good idea. The research is piling up that fully remote working has a negative impact on people who used to work in an office. The only organizations that work well fully remote are those that were born that way.

If you are in a leadership position, you should set mandatory in-office days. A minority will complain loudly, but the majority will quietly be thankful that you set clear rules. And despite the claims of the work-from-home zealots, it does improve communication, engagement, and the bottom line.

What is Your Time to Recover?

It wouldn’t take you three to four weeks to rebuild a critical system, would it? But that’s how they do things in the National Health Service in the UK. Doctors and hospitals have been advised that the central patient record system is offline due to a ransomware attack and will not be back until sometime in September. In the meantime, doctors will have no access to their patients’ medical histories and will have to keep notes on paper or in Microsoft Word on their laptops.

As a national health monopoly, the NHS will not be going out of business. But a private company that lost its manufacturing, logistics, or service management system for a month would be finished.

You do everything you can to prevent bad things from happening. But have you also planned contingent action in case something terrible does happen? The NHS hadn’t.

When the Shortcut Becomes the Standard Way

There must be a shortcut for every Standard Operating Procedure (SOP). You cannot allow the production database to be down for hours while you chase down everyone on the Change Advisory Board. The police cannot wait for a judge and the associated paperwork if somebody’s life is in danger.

The problems start if the shortcut is abused. Amazon is sharing video from your Ring doorbell with anyone who works for one of their 2,161 “partners” as long as they promise on their scout’s honor that it is really important. Google will similarly share the video feed from your Nest camera. They say they haven’t done so yet, but that’s only because law enforcement hasn’t noticed them yet.

I’ve been in organizations where half the work of IT operations was Emergency Changes. Do you track how much work is handled following SOP and how much your people use the shortcuts?

The Original Sin of Technology Projects

Today is the 394th anniversary of the original sin of technology projects. The Swedish King sent out an RFP for a huge warship, and a private contractor was selected to build it. But on second thought, the King wanted the most powerful warship in the world. So he required another deck of cannons to be added. A conscientious engineer would have refused, telling the King that this would make the vessel too top-heavy. But just like a modern contractor, the private shipbuilders accepted the questionable change request and charged extra.

On its maiden voyage, the ship heeled over and sank just off the pier in front of thousands of spectators. Just like in modern IT disasters, a commission investigated, and in the end, nobody was punished.

In every failed technology project, dozens or hundreds of people know it will fail many months or even years before the failure becomes obvious. What are your processes to ensure that you are not building a modern version of the good ship Vasa?

(image by Jorge Lascar/Flickr used under CC BY 2.0)