Linear Thinking Equals Business Improvement Disaster
September 8, 2008 | Author: PM Hut | Filed under: Change Management, Corporate Transformation
Linear Thinking Equals Business Improvement Disaster
By John Bolden
Today, like yesterday and doubtless tomorrow; change is coming down the pipe and most if not all who read this piece have been, are and will be impacted by change. Depending on your rank and role; you may conceive, approve, plan, execute or be the recipient of efforts to strengthen, grow, streamline, consolidate or simply improve what the business does and how it does it.
Here’s the bad news… The odds are stacked against you! Never in the history of corporate transformation have so many projects delivered so little, so late, so poorly, at so much cost and with so much aggravation.
My research into why transformation projects fail to meet expectations so often focuses on certain aspects of corporate transformation / business improvement that are usually overlooked, ignored or taken for granted. Here’s one aspect; far too often, it sneaks up and bites transformation where it hurts!
Back in the 1960 -70’s; business and government began to move into the information age. Management needed a way to deploy new systems, new processes and new ways of doing business. Project management techniques used in construction/engineering projects were well suited for these early efforts to automate the business along vertical, functional lines and business grabbed the opportunity to use what had worked before – in other environments.
The very means by which these new ways of doing business were delivered became second nature, permeating corporate and individual thinking to such an extent that it is ingrained in the corporate psyche. What worked quite well in the past is now the de facto standard.
The thinking that governs construction/engineering projects has been around for a long, long time. If one wanted to build a pyramid, dam, railway, etc. one used linear project management techniques. One started with an empty space or obliterated whatever occupied that space then built to spec, to budget, to schedule.
Way, way, way back in time - if one had to build a pyramid, one used linear project thinking.
One did not need to contend with or even consider that lots of other pyramid building outfits would be building pyramids for lots of different pharaohs, each with different ideas and designs in exactly the same empty space where you are building your pyramid. If one did (back then), one would simply cleave aside the opposition, smiting all around until the empty space was once again empty.
In today’s business world, there are no empty spaces where linear project thinking can truly work as well as it does when things are being built in real empty spaces. And, one cannot smite quite so freely…
Today; multiple, concurrent change projects are underway, each building a personalized pyramid of varying import, size, scale, purpose, etc. somewhere in the business AND, each change project is governed by linear project thinking based on building just one thing in just one empty space…? Is there a problem here…?
Today, multiple projects are targeting the same people, processes or functions in the same part of the business for many different reasons; each project is marching to very different orders, timelines and priorities; each is governed by linear thinking…? Is there a problem here…?
Essentially, each and any project intent upon changing the business does so in a manner meant to meet that project’s specific objectives (this is a good thing) yet is utterly ignorant of how this project might impact other projects or vice versa (this is a very bad thing) or how project vs. project collisions and conflict will impact the business (this is a very, very bad thing).
Essentially, linear project thinking overlooks or ignores the fact that other projects will be contemplating, competing or contending to make changes to the same part of the business while the project in question is underway. What can be done about it? For starters, ask questions whenever a project comes forward for approval. Ask questions like…
What other projects have, are or will be working in the same relative space in the business?
Has this project spoken to that project?
Does that project know what this project intends?
Does that project have anything that this project could borrow or reuse?
What did that project teach us about this project?
Will what that project is doing get in the way of what this project wants to do?
Has anyone asked the end user which project is more important?
Has anyone asked whether what this project wants to do might be changed, made redundant or even eliminated by the next project coming down the pipe?
Etc.
By simply instilling and insisting upon awareness of what the rest of the business is up to in the minds of those who approve, manage and execute projects, significant benefits to project(s) and business will accrue and very significant problems of conflict, contention, mayhem and general chaos will be reduced if not eliminated.
And that would be a very good thing, wouldn’t you agree?
If you would like to learn more about the seminar themes I speak to, types of consulting engagements and research that underpins my thinking, feel free to browse my web presence at http://www.TLIRGroup.com
John Bolden
RMA, Mil C, C/MBB-ISSSP. F-IICM, F-IPMS
Transformation Leadership, Innovation & Research
http://www.TLIRGroup.com
John Bolden is renowned for value laden advice that stakeholders depend on when assessing the wisdom of investing billions. John’s views and observations enable corporate leaders to ask the right questions, probe problematic answers and avoid surprises.
Related Articles
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.










