People call it luck when you’ve acted more sensibly than they have.
Anne Tyler, Author
People call it luck when you’ve acted more sensibly than they have.
Anne Tyler, Author
Ready, Aim, Fire
Seems logical. You set some goals, plan how you’re going to reach those goals, then pull the trigger on execution. And it is logical as long as you’re dealing with known quantities. You know…you’ve done this type of project before and have a pretty good ideal of what it takes to be successful, both internally and externally. To be successful, the goals have to be reasonable and the stake-holders need a good grasp of the success criteria. But if you’re stepping into some uncharted territory, the strategy could be more wishful thinking and there’s a risk of over-planning when you in fact have a lot of unknowns. Ahww…who cares…we can always blame the people responsible for execution!
A good percentage of the posts here touch on the topic of thinking. But can you “over-think”?
Ok…I’m going to carefully step out on a slippery slope here and try to find a balance. On the one hand, we can labor overt what our strategy should be, and spend so much time honing it that we never actually get into the execution phase…or miss the window that would have produced the most fruit from execution.
My observation is that organizations and individual leaders tend to fall into four categories when it comes to finding a balance between planning and execution. I’ll use a metaphor to explore this. BTW…ALL metaphors break down at some point, and I can quickly point out how the one I’m going to use does, so don’t get too wrapped up in the metaphor itself.
For our purposes here, “Ready” = Strategy Development, “Aim” = Planning, and “Fire” = Execution
We’ll explore each in subsequent posts, but a hint about where I’m going can be found in the following quote…paraphrased from a conversation with Paul Marshall, Vice President, Bentley Systems, Inc…
“A (B) Strategy with an (A) Execution will beat an (A) strategy with a (B) Execution everytime.”
“We already have a system to manage documents (and/or data) and we don’t understand why the engineering team thinks they need yours.”
I’ve heard statements like this many times over my career. And the reasons behind it make sense. It usually comes from someone on the IT or management team that believes that they’ve already spent the money to “solve” the engineering information management problem.
After all, there are a lot of systems that manage documents or data in one way or another. Most vendors of general purpose systems will say that they can manage engineering documents. And they can, but in a very limiting manner when compared to systems designed for EIM. (See the third bullet in the list below)
Engineering data is an amalgamation of documents and data (with some formats found only in engineering) the interrelationships of which can be far more complex and much larger in size than common business documents. In addition to these interdependencies, this content is created by sophisticated engineering applications that can imbed objects and link to external databases that carry important information about the asset that will be used in construction and operations. And, oh yeah…this content is being authored by a team, rather than an individual, and that team is frequently separated spatially.
A few years ago I wrote a short white paper on this subject and it’s due for a refresh. I’m planning to address this overdue update through a succession of weekly posts here. The series will describe both the challenges that engineering information creates and why general IM systems fall short. Some of the topics will be:
If you have ideas or specific questions you’d like to see addressed, please comment.
Next week we start by looking at the complexities of engineering content and the unique challenges of managing it.