How many times have you heard, “We picked the wrong tool!” when referring to a project management or portfolio management or just about any other kind of tool for the IT organization? I’ve heard that many, many times over my 30 year consulting career. So, it’s time for a couple of uncomfortable truths – expressed as “Merlyn’s Rules of IT Tools”:
- Merlyn’s Rule #1: You will always pick the ‘wrong’ tool.
- Merlyn’s Rule #2: If you focus on the process being automated or supported, and the management of organizational change, you will probably find you actually have the ‘right’ tool.
- Merlyn’s Rule #3: If you focus on the process and management of organizational change and still want a different tool, then switching to a new tool will be trivial.
The Cobbler’s Children
All IT people know the three rules above. You would never allow technology to be applied to a business process without reengineering the process first. And yet, when the “customer” is the IT organization, all the conventional and hard-earned wisdom goes out of the window and into the shredder! I’d like to explore why this is, but frankly, I don’t know. I guess it is a syndrome that all professions are prone to – hence the ancient proverb.
Image courtesy of USDA Agricultural Research Solution
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=2060a1ad-3041-4b55-ab44-91707d8f0f7a)
Filed under: Change Management, IT Management, Useful Tools | Tagged: Portfolio Management, project management, organizational change management, IT portfolio
[...] and these procedures are supported or automated by appropriate systems (read Vaughan Merlyn’s post on the topic of appropriate tools) the Project Management Information System becomes the Project Information System of [...]
Hi Vaughan,
We also hear this in the context of large scale system development (ERP, CRM, Sales Compensation, etc). I think that in many cases there is a ‘right’ tool… or at least a ‘best’ tool. It might not feel like it during implementation, but even the ‘best’ tool can be a pain.
It’s true that with a strong focus on processes and change management the pain might be less, but with a similar emphasis AND the ‘right’ tool it would be even better.
Too often do I see companies choosing a certain solution because they like the sales guys, because an exec played golf with the vendor, or because a solution is considered ‘best of breed’, without really assessing if the solution is really the best fit (i.e. the right tool).
Finally, in my experience, the larger the ‘tool’, the less trivial it is to switch.
Happy Holidays!
Julien, I agree that there is a “right tool”, but even the “right tool” will look like the “wrong tool” if it is poorly implemented.
However, you definitely caught me on my “switching can be trivial” claim – clearly, an egregious overstatement! Thanks for bringing me back to reality, and please excuse my hyperbole!
How True. But I guess you need to separate End user I/T organizations from Software Vendor organizations. The latter are more systematic in applying formal tools and methodologies where as the former struggle.
Well, CK, I guess I’d say, “Yes, but…” I’ve often found software vendors to be the “children of cobblers children” – i.e., really ignoring common industry practice, let alone leading practice. Even today, you can ask some vendors for a view of their underlying data model and if they have one at all, it will reveal a dreadful lack of data modeling “good practice.”
In my experience, some aspects of human nature aren’t well enough buffered by other of our qualities to avoid the fate you describe.
I think it is easy in the beginning to say “we need a tool” and much more difficult to imagine the future state of the organization with that tool in mature use.
It is easier still to then rush to build a case and implement the tool without adequately planning for and re-engineering the processes and training the people. (A compelling story does not a process redesign make)
It is then extremely tempting to rush off to the next problem demanding attention. (It is harder to realize value)
I also have experienced some and suspect there may be a significant number of organizations, even large complex ones, that do not derive significant value from both operational and IT projects. Thus I respectfully challenge your assertion in this sentence: “You would never allow technology to be applied to a business process without reengineering the process first.”
I wonder what an IT organization looking toward 2017 could tangibly do to develop and sustain an ability to live “Merlyn’s Rules of IT Tools…?”
Great comments, Barry – thank you. And thanks for challenging my statement “You would never allow technology to be applied to a business process without reengineering the process first.”
My “would” should have been “should”. You are correct – IT organizations often do allow the businesses they support to implement technology without really thinking through and following through on how that technology will solve business problems and deliver value that can be captured.
As for your closing question, “I wonder what an IT organization looking toward 2017 could tangibly do to develop and sustain an ability to live “Merlyn’s Rules of IT Tools…?” I guess that is the proverbial $64,000 question. And I’m afraid the answer is something close to the sum total of all the good management practices you need to reach high business-IT maturity. It’s a long and arduous journey. And maybe it needs to be that way – it’s what separates the best organizations (and the results they achieve) from the rest of the pack.
…and then there are the cases in which we create a monster with the tool. While good practices may have been followed when automating the processes initially, after many revisions and updates we sometimes reach the point at which we’ve automated ourselves into a corner. That is to say, when faced with the cost and pain of significant process revision, we sometimes choose to compromise the process in favor of automation that we can afford (money or time).
Yes, Bob – that’s another one of the “traps” we all fall into – a question of “tool over process.”
I’ve been thinking lately about ‘sustainable practices’ for IT organizations, and you’ve hit on one of the many impediments to this goal.