I would have written a shorter letter, but I did not have the time. - Blaise Pascal
How does this relate to the world of getting things done? Kevin Jones has me thinking about this with his piece on Why Complexity is Simpler than Simplicity
We often don’t take the time to think about things all the way through. We rush to conclusions and in our rush make things more complex.
He is a little tongue-in-cheek in his definition of these terms. There is that fast-and-easy version of "simple." And then there is the not-expensive-but-it-works version. Or you might have the does-one-thing version. Similarly, there are variations on the definitions of "complex" and "complicated." Sometimes what one person thinks of as simple is another person's picture of complex, so you do need to be careful.
My take on this is colored by my experience with Theory of Constraints and systems thinking. Complicated is something that is difficult to describe: pages and pages of technical specifications. This is orthogonal to the simplicity / complexity question. Simple is something that requires one (or very few) inputs to affect the entire system. Complex is something that has may degrees of freedom and requires touching them all to affect the system.
Back to Kevin Jones' argument: the fast-and-easy solutions are often those that solve the problem in a overly-complicated way. Just like the Pascal quote above: if we don't take the care required, we often do too much. How many projects have you been involved with where there was a push to "just get started" even though all the elements weren't there yet? What is the inevitable result? You build something the customer wasn't asking for, or you have to make expensive changes partway through the project that wouldn't have been required had you known everything up front.
I have a client who is talking about doing more "front end loading" on projects - meaning doing more up-front work at the beginning of projects to ensure all the bases are covered. They've had too many experiences of getting to the end and discovering changes. We've all seen the curves of the cost of changes as projects mature (exponentially more expensive to make changes towards the end of a project). From the perspective of this thinking, the idea of planning up front to avoid mistakes later is a great path forward.
Another client is very fond of metrics and KPI's. However, when I walked through these metrics with them, I found nothing that told me how the system was doing or that could direct them to look for opportunities for improvement. Their metrics were complex enough that they could only publish monthly results. Or they would have to compile several months' data before being able to say whether they had done well. These kinds of metrics make it difficult to sense and respond to changes in the system. We had to step back and ask what it was they were trying to do and then suggest metrics that would tell them if they were succeeding. Simple things like Number of Projects Completed; Number of Active Projects; Cycle Times.
Pay attention to what you are doing. Think beforehand, and then take action. And of course, check that your actions are taking you in the right direction and correct course as needed.
[Photo: "Statue de Blaise Pascal" by Yann Caradec]