Too much technology will be harmful to your project
I wrote in an earlier post (“how much process is too much process?“) about the tendency of some organizations to impose overly engineered processes in a (futile) attempt to increase quality.
Further to that and having been in the Information Technology sector for almost 30 years I can confidently and comfortably conclude that innovation, flexibility and grand availability of sophisticated and feature rich technologies have resulted in substantial increase to projects’ complexity with an increased risk of project integration failures.
Information Technology project tend to include, in one way or another, a number of database, networking, server, software packages and other perhaps more obscure technologies. Each of these technologies require the services of highly technical and trained personnel in order to best use the respective tools to achieve the best result for the project. Now, the problem with today’s set of technologies is that they are all highly flexible, powerful, customizable and configurable; to the point that a considerable amount of effort need to be spent in order to ensure that the enormous capability built into the tool is harnessed appropriately.
Let’s use a common presentation tool as an analogy to explain the point above. Preparing a presentation is an easy task (provided you have the right tool and you know what you intend to convey to your audience). If you are an average user of Microsoft PowerPoint (or any other similar tool) you will surly know that in addition to the basic presentation capabilities you can introduce complex transitions, timers, sound and multimedia to enhance your presentation and turn it into an Oscar worthy event. Now, most people don’t require this extra elaborate capability and indeed, for many, this extra functionality is more of a distraction than an enabler as they get tempted by the available technology in an attempt to make use of all these gadgets because they are there.
A similar phenomenon which can be easily observed at the micro level can be seen also at the macro level. Organizations are lured into deploying and using large number of technologies, each of which come with a promise of amazing flexibility and functionality, while the consequences of deploying these technologies are not properly understood.
The questions I would like organizations to ask before deploying any new technology are:
- Do we need this technology?
- What tangible benefits, based on a clear selection criteria, does this technology have that we don’t already have today?
- What percentage of the marketed feature would we actually use, compared with those features that we are really excited about but will never ever get used?
- Assuming we conclude that we really, really, really need this technology, do we understand the impact on integrating this wonderful thing with our existing technologies?
The Conway’s Law which I got introduced to some time ago states that:
“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations“.
I would like to propose a slight variation on the above law (which I humbly call “Shim’s Law of the impact of Advanced technologies on projects’ risk“)
“organizations which design systems are bound to produce designs which mirror the myriad of technologies the organization utilizes“.
Think about it!
No related posts.
new quantmleap post: Too much technology will be harmful to your project http://bit.ly/aabnfp #pmot
The Science of PM: Too much technology will be harmful to your project #PMOT http://dld.bz/upPx
RT @corneliusficht: The Science of PM: Too much technology will be harmful to your project #PMOT http://dld.bz/upPx
Too much technology will be harmful to your project http://j.mp/a7VIBo #pmot
Hi Shim,
Hum, this post doesn’t make it any easier to be a PM tool vendor in an already competitive and tight economy… ;>)
Still, to be honest, I absolutely agree with you on the highest level, but would share my likely biased opinion on certain points.
First, my observation is that prospects/customers demand both every feature imaginable as well as ease of use. Clearly there is a trade off here, so typically the features win, as competitive companies each try and stay ahead of the other. How many times to do see a software company release a new version touting “We removed 20 features to make the product less flexible but easier to use”…
Regarding your point on complexity and the inherent requirement then for good training and planning, this is not a bad thing. A car is a complex tool, and everyone needs training in order to operate one effectively. The thing about a car, is that new users typically are highly motivated to learn. This is typically not true with any kind of productivity tool, as people tasked with using it rarely are supportive initially. Even when management clearly defines the goals, and picks an appropriate tool, this is still an issue and can make or break an implementation. The other challenge is that the cost of training is looked at as an expense, and not an investment and thus is often minimized instead of maximized. This again leads to loss of long term value from the tool.
That said, I hope you don’t mind if I borrow your last 4 questions and use them when talking to prospects. If they have solid supported answers to them, and my product fits their need, they are the prefect customer.
A great post, thanks!
Hi Bob, thanks for your thoughtful response. Having been involved with this industry for a substantial period of time I honestly sympathize with your plight. Coming from a vendor perspective does shed an interesting light on the flawed process taken when procuring new technologies. Such negotiations are often conducted by individuals who see only part of the picture and are only in a position to answer part but not all the questions I have listed in my article. The example you bring using the car analogy is an excellent one but it addresses only part of the problem. Even with the best training for each individual tool, integrating all tools into a single, cohesive, business solution is still a complex and risky business.
Would I buy your product having heard that that you removed 20 features to make the product less flexible but easier to use? Probably not – because I, like most other people, am biased, greedy, short sighted and irrational person. I want more, not less. But seriously, if you dropped the first part and only emphasized the ease of use and ease of integration I would be listening and asking further questions for clarifications. But that’s me, not sure about others – and I wonder what your experience suggests in that regard.
Good luck with your sales mate.
Cheers, Shim.
“organizations which design systems are constrained to produce designs which mirror the myriad of technologies the organization is invested in“. AND THE PEOPLE THEY ARE INVESTED IN.
Hi Linus, happy with your extension although, in some respects, I always felt that the people aspect is somehow already covered in the original Conway’s Law.
Cheers, Shim.
Thanks for the RT @sara_broca: Too much technology will be harmful to your project http://j.mp/a7VIBo #pmot
Thanks RT @always14: RT @corneliusficht: The Science of PM: Too much technology will be harmful to your project #PMOT http://dld.bz/upPx
Actually, I think Shim that we share a similar philosophy and view, and don’t worry about sympathy, I did after all chose this path… ;>)
In my opinion, often people do start out wanting ease of use and integration in software tools, but then succumb to the sounds of lots of bells and whistles (or flashy GUIs). There are always tradeoffs between these two, and the key is that the buyer understands that and makes an informed choice that fits their actual need.
I acknowledge that my product is not a good fit for all PM processes, and yes, is initially visually complex, but with proper training, it flat out works, especially in the hands of an experienced and open-minded Project Manager. So, you want to drive a Yugo, or an American muscle-car… ;>)
Too much technology will be harmful to your project http://ow.ly/2zQaG by @shim_marom #pmot
RT @gedpro: Too much technology will be harmful to your project http://ow.ly/2zQaG by @shim_marom #pmot
Too much technology will be harmful to your project – http://b2l.me/an3wqm
RT @steelray: Too much technology will be harmful to your project – http://b2l.me/an3wqm
[...] previous two posts (http://quantmleap.com/blog/2010/09/the-cost-of-too-much-technology/ and http://quantmleap.com/blog/2010/03/how-much-process-is-too-much/) I’ve raised, rather [...]
[...] referred to this issue in previous posts (see “the cost of too much technololgy” and “how much process is too [...]
quantmleap: Too much technology will be harmful to your project http://is.gd/gceY2 #pmot #ftpm #pmp
[...] a previous post titled “Too much technology will be harmful to your project” I’ve made the observation that: Having been in the Information Technology sector for [...]
quantmleap: Too much technology will be harmful to your project http://is.gd/88YJpJ #pmot #ftpm #pmp
RT @shim_marom: Too much technology will be harmful to your project http://is.gd/88YJpJ #pmot #ftpm #pmp
RT @commsabilities: RT @shim_marom: Too much technology will be harmful to your project http://is.gd/88YJpJ #pmot #ftpm #pmp
quantmleap: Too much technology will be harmful to your project http://is.gd/qxQa6h #pmot #ftpm #pmp
quantmleap: Too much technology will be harmful to your project http://is.gd/qttDVl #pmot #ftpm #pmp
RT @shim_marom quantmleap: Too much technology will be harmful to your project http://is.gd/qttDVl #pmot #ftpm #pmp #pm #apm
RT @shim_marom: quantmleap: Too much technology will be harmful to your project http://is.gd/qttDVl #pmot #ftpm #pmp