Getting the systems of two companies to exchange information is tricky. Not because the technology is hard, but because there are two parties involved.
Lessons from the kitchen timer.
Even if the task looks trivial, sometimes you need a professional.
When developing software, the contractor needs to understand the difficulties and the methodologies, and the client needs to be willing to step out of his “that’s the way we’ve always done it” habit of working with traditional contracts.
When you make a bridge you have a plan. You know exactly how much you have to dig and how much concrete and iron you’ll use. You can ask a contractor how much and how long. If the bridge was software, all you’d know before you started to build it is some vague requirements like “it must have a capacity of 7 thousand vehicles per hour in each direction”. A contractor wouldn’t be able to give you a quote. However, it’s not impossible to make good estimates for software.
In IT projects, both requirements-based contracts and time-based contracts create tension between the contractor and the client.
Until 20–30 years ago, we approached software projects as if they were bridges. We’d write a list of requirements, and a contractor would develop and deliver the software based on these requirements. Today we know that this doesn’t work.
Why do we perceive as a problem the transfer of business knowledge from the logistics professional to the programmer? Why do we not perceive as a problem the transfer of business knowledge from a manager to a management consultant?
At a fundamental level, writing software is easy. Why, then, are good programmers so hard to find and expensive to hire?
“Ten years ago, if I wanted to do a simple computing task, I needed to hire a programmer. Today I do it myself in Excel. It seems unlikely we will be needing any programmers at all in a few more years.”
—My boss, c1995
Like today’s CEOs who have lots of pressure to show ROI within a trimester, I’ve often been looking at the costs and the ROI in a short-sighted manner.
A web site is a tool. Asking whether you need a web site is like asking whether you need a pen.
It’s not just our homes that can benefit from Marie Kondo’s method—it’s also our businesses.
If throwing it away is going to pay off, you should throw it away—the amount of previous money and effort is irrelevant.
Looking for the right context is important, both when dealing with COVID-19 and when we examine the cost of automation.
The cost of automation for a trucking company is dwarfed by the cost of trucks and drivers. Why, then, do many small trucking companies run on pen-and-paper or Excel?
Do you want to be “strategic” rather than “transactional”? Do something about your home-grown Excel.
“Oh, this thing is so complicated! I’ll just do something simple in Excel.” If you ever said this to yourself, here is the result you got.
It’s an old Greek saying that however bad something is, there’s always a good side to it.
I created a toy application, which, if you were lucky, would cost you 500 or 1000 dollars/euros. Real projects cost much more.
Despite having taken 18 hours of work, it the application needs have some way to go.
A developer will sometimes be able to do wonders in minutes, and sometimes get stuck for hours while trying to change a comma.
A graphic that shows where a programmer spends his time in order to write a simple program.
I thought I’d take this small application for breakfast, but it took me two weeks.
Search in 1.7 million U.S. transport businesses; the FMCSA census data for humans.
You don’t have to have a web site. Make one if it’s useful for your customers.
“We paid for it, therefore now it must pay off.” Here’s how to escape that damaging mentality.
A question that can lead to good automation is “how can we reduce the volume of emails?”
If you have your nephew develop software for you, costs will be way smaller. But these savings come at a, well, cost.
The first step towards good document management is to eliminate as much as possible.
“Integration” is a slightly confusing term and in many cases “bridging” and “connecting” are simpler and tell the whole story.
Even if you’re not an expert, it doesn’t harm to ask some questions about your prospective IT provider’s software development habits.
All software solutions suck. The thing is to find one that sucks less.
If you are a new business you may think you shouldn’t worry about code quality now, and you’ll do it “later”. This mentality has driven companies out of business.
If you use “ERP” as a meaningless sequence of letters, it’s OK. If you try to look it up, you may be in trouble.
We often worry a lot about how to proceed with automation. Sometimes we fail to ask: Should we proceed with automation?
Warranties can help, but they are not the answer to the problem of automation.
The press likes a good story like an automated vehicle, but you’d better ignore that and concentrate on whatever actual improvements your business needs.
Many companies get into trouble believing that they can just install the software and throw in some data. Inevitably, the scope of the project grows and what was supposed to be a simple system ends up a confusing mess.
Two stories, one from Truckstop.com and one from Pixar, illustrate an issue that is often overlooked in young companies.
Becoming dependent on an IT system can hinder progress. Not becoming dependent can make an IT project fail.
The five times more rule is figurative. If you take it at face value, it’s stupid and pointless. It’s just a guide to a different way of thinking.
When you estimate the cost of an IT solution, multiply it by five. What if you don’t have that amount? The same thing you will do if you need a 300k truck and can only spare 60k.
Yesterday I wrote that when you are about to automate your logistics business, you should be prepared to spend five times as much as you initially think. What if you don’t have that much?
When you are about to automate your logistics business, get into a mentality of “we are building it in order to throw it away”.
When you give an employee a device, you might need to give it bundled with a carrying case, a specialized charger, or a towel.
Celadon Trucking, one of the largest trucking companies, failed. This can happen to software companies, and the results can be worse.
When the Manchester ambulance dispatching service added decision support software, they had to change the way they were seated.
If you rush to adopt some automation without thinking about the repercussions first, you are headed towards a nasty disruption.
The story of Twitter illustrates how software can start OK and then fail big. Twitter was able to overcome the problems with a brave decision.