To be fully prepared for this, I decided to re-read two absolute classics in this area: The Toyota Way and The Goal . I read both of these books in college, but re-reading them made me realize that many of these process optimization exercises are very simplistic in nature, and often misunderstand what to focus on.
visual barrier
Let me show what I mean.
gantt title Project Timeline dateFormat YYYY-MM-DD section Scoping Feature exploration :s1, 2024-01-01, 10d Budget scoping :s2, after s1, 3d Legal :s3, after s1, 10d Documenting :s4, after s3, 5d section Development Exploration :d1, after s4, 25d Software Development :d2, after d1, 70d Documentation :d3, after d2, 5d section Deployment Deployment :dp1, after d2, 5d Hyper-care :dp2, after dp1, 10d
This is a Gantt chart for demonstration purposes, typically what you would see in BPMN. Showing Gantt makes things easier.
If you take a look at this Gantt chart you’ll immediately see what takes the most time: software development. If your task is to improve project throughput, that should be your first stop. And that would be right.
However, the problem is how I generally see people go about it: throw people towards the problem. Or just assume that AI is going to make it much faster.
What people usually don’t do is look Why It’s taking so long, and more importantly: a longer period of time does not mean that the problem arose automatically.
The problem is being resolved upstream
Now we’re talking about software development, but this applies to all processes that take more time than you expect.
Every software developer knows that you can’t make a project go faster just by typing faster. If that were the case we would all be taking typing lessons.
Software development is about turning a problem into a solution that a computer can understand and solve automatically. preferably in a secure and scalable manner.
To do something like this, you need a complete overview of the problem. Either in feature or scope documents (if you’re going more waterfall), or with constant iteration with domain experts (more agile).
This is often the part that slows down software development. Trying to figure out what a vague, title-only, feature request actually means.
What does “send mail to user when sale is completed” mean? Ok, we can send the mail, but what should be in the mail? Do we still send an error mail if there is a problem with the sales process? When is the sale completed?
just throw AI at it
One argument I keep hearing about automation of software development (AI generated code) is that you can bypass the development part and the software developer becomes the project manager. AI discussions around software development actually illustrate this problem perfectly.
Many people expect the results of AI development to look like this:
gantt title Project Timeline dateFormat YYYY-MM-DD section Scoping Feature exploration :s1, 2024-01-01, 10d Budget scoping :s2, after s1, 3d Legal :s3, after s1, 10d Documenting :s4, after s3, 5d section Development AI development :d1, after s4, 3d section Deployment Deployment :dp1, after d1, 5d Hyper-care :dp2, after dp1, 10d
But it doesn’t work like that. Here we are facing the same upstream problem as before.
Yes, AI can generate code faster (it’s open to debate whether this is a good thing), but that doesn’t mean it’s generating perfect code.
When making comparisons between human vs AI development they always ignore the help that AI requires to do its job. It looks pretty much like this:
gantt title Project Timeline dateFormat YYYY-MM-DD section Scoping Feature exploration :s1, 2024-01-01, 10d Budget scoping :s2, after s1, 3d Legal :s3, after s1, 10d Documenting :s4, after s3, 40d section Development AI development :d1, after s3, 40d section Deployment Deployment :dp1, after d1, 5d Hyper-care :dp2, after dp1, 10d
Maybe this setup is faster than the old way of doing things. But I also think it’s an unfair comparison. Working this way requires very deep involvement of domain and product experts. This involvement would mean writing every feature and bug fix down to the smallest detail.
This is what software developers have sought since the beginning of their profession: to get a detailed outline of the problem and what the end result should look like.
If you give the same amount of feature/scope documentation to human developers, you’ll also see your productivity increase.
really speed up processes
If you want to speed up processes, you have to make sure that the people who need to do the work actually have all the tools to do the job.
This means that if your legal approval process is going slow, you should focus on what is needed to start the legal approval process. If they need to chase down five different people for incomplete documents, you won’t be able to speed up said process by adding more lawyers to the department.
A big lesson of the goal is: “Bottlenecks should receive predictable, high-quality inputs”.
I believe this should be the first step in process automation.
<a href