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:

  1. Do we need this technology?
  2. What tangible benefits, based on a clear selection criteria, does this technology have that we don’t already have today?
  3. 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?
  4. 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!

Print Friendly

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...


  1. Pingback: Shim Marom

  2. Pingback: Cornelius Fichtner

  3. Pingback: Luke Lee (이호웅)

  4. Pingback: Sara BROCA

  5. 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.


  6. “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.


  7. Pingback: Shim Marom

  8. Pingback: Shim Marom

  9. 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… ;>)


  10. Pingback: gedpro (Jose Moro)

  11. Pingback: Jo Ann Sweeney

  12. Pingback: Steelray Software

  13. Pingback: Julio Vazquez

  14. Pingback: KISS – Keep it simple stupid | quantmleap

  15. Pingback: Quote of the day – More on Too Much Process | quantmleap

  16. Pingback: Shim Marom

  17. Pingback: Complexity of IT Systems Will Be Our Undoing | quantmleap

  18. Pingback: Shim Marom

  19. Pingback: Jo Ann Sweeney

  20. Pingback: Shim Marom

  21. Pingback: Shim Marom

  22. Pingback: Shim Marom

  23. Pingback: thepmobox

  24. Pingback: Max Walker, MBA, PMP

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: