As I stated in my last Blog, time constraints, those things such as schedule, ship date, move-in date, budget (which relates to time available to invest in the design) and other milestone deadlines are part of the design variable equation. What do I mean? I mean that the content, depth, elegance, or otherwise, of a design solution, is dictated by numerous boundary conditions, one of which is the required schedule, budget, and “done date.” However, in my experience, most often this is not viewed as such by the technical professional. “Hey, it takes whatever time it takes to get it done,” is often the attitude.
No. Not true. It takes the time we have allotted, the solution set, scope, and delivery we have sold to the client, and that they have purchased, to get it done. I dive a little deeper with some observations and comments below.
“Parkinson’s Law.” This is the adage that “work expands so as to fill the time available for its completion.” This is so true. I have seen it over and over. I don’t think any design, service, or product would ever be completed if it weren’t for deadlines, whether externally or internally imposed.
Do you need a solution in an hour, a day, a week, a year? We can provide that. You may not like the one-hour solution, and patience will wane with the one-year solution. Any good technical professional can tell you something that will work, sketch a solution, or provide a recommendation in a short period of time. It will likely be heavy, bulky, conservative, not elegant, but it will be a solution. If the client has $500 to purchase engineering vs. $50,000, the design will be impacted. If they have a day vs. a week, the design will be impacted. We can’t provide the same level of value and design in both contexts.
If we let design expand into “the void” until we think we’ve perfected it, we will reach the asymptotic stage where the curve flattens out, running almost parallel to the horizontal axis forever, never reaching the desired outcome (whatever criteria we have established.) Remember, there’s no perfect design, no perfect work product, no perfect solution. There’s complete, correct, finished, polished, specified, scheduled, completion of the work product, service, solution. Get it to the defined, specified, standard of care, and ship it.
How about an example from the building industry. Do you want quick turnkey delivery of your building for occupancy? How about a tilt-up precast or pre-engineered metal building? Not an elegant enough design solution? Better modify your timing. Do you want hand chiseled split-face stone, marble floors, custom bronze doors, glass from Europe, stone from Italy? If that’s the more elegant design solution, then get out the calendar and push the move-in date out a couple years.
What about modern tools of technology? Can’t they “hack” the time variable and do more work in less time? Sure, in theory. Those tools can enable a more elegant design in a short period of time. What I’ve found over the years though is that the tools of technology are often misplaced in the mind of the technical professional in this way; they become the thing we are serving rather than them serving us. If you’re my age, you’ll remember when the prediction was that things would go so much quicker the more advanced the tools became. Unfortunately, many lose site of this and use the tools to dive deeper and deeper to a point of diminishing returns, rather than using the tools to advance the design solution more quickly. Step back. Assess. Regroup. Do this often. Plus, there’s this thing called complexity. Simplicity is undervalued. Systems fundamentally create more complexity. The more capable an IT platform, computer, software, the more complexity can increase. Sometimes we need to step back, sketch and idea, assess “1st principles” and re-state the scope and deadline.
Schedule, time to perform, ship-dates, timing, all are part of the considerations in design. Schedule is a design variable. I recommend this be kept in mind when deep in the midst of “the work” and the scope and end goal is getting murky. Keep the end in mind.
JOHN L WHEATON BLOG 