Having referred in an earlier post to the issues arising  from needing to comply with too much process, I’ve come across a beautiful post by Eric D. Brown titled “Complexity & IT“. Eric has been diligent enough to read through a rather long memo published by Ray Ozzie who, five years ago, joined Microsoft as a Chief Software Architect. The memo, titled “Dawn of a New Day“, includes the following statement:

Complexity kills. Complexity sucks the life out of users, developers and IT.  Complexity makes products difficult to plan, build, test and use.  Complexity introduces security challenges.  Complexity causes administrator frustration.”

In attempting to reduce the mounting road toll, the Australian Police has introduced the slogan “Speed Kills“.

In the context of IT Project Management it could easily be argued that “Process Kills“. It does not kill people but it certainly kills innovation, kills originality, kills inventiveness and kills imagination.

Think about it!

Print Friendly

3 Comments

  1. Pingback: Cornelius Fichtner

  2. Pingback: Cornelius Fichtner

  3. Shim,

    I must disagree. While process for process’ sake is stupid, I believe that process can actually promote innovation and creativity by removing busy work.

    Have you ever been stuck deciding which format to apply to a particular type of document; for example a proposal? What about having to figure out what that proposal should include? Too often, the lack of template (a form of process) leads to a kind of paralysis that steals time away from content and instead waste that time of format.

    Comparatively, efficient, simple processes become second nature through repetition and lead to what I like to call “creative laziness”. By that I mean being lazy to allow time for creativity. I understand that some people are allergic to process and discipline and may want to use the “process kills creativity” argument as a defence. Let me counter by saying that many creatives; writers, people in advertising, etc. do follow a process and are highly disciplined yet they achieve their goals. A great many examples of this can be found in Phil McKinney’s Killer Innovation podcast and blog.

    I think it is time to let go of the sad “process kills creativity” excuse and to use process to liberate creativity.

    Reply

    • Hi Pat, thanks for taking the time to comment.

      I respect your view on this point but would maintain my position on this issue with the expectation that the gap between our views is semantical and not conceptual. I trust this is the case as I am in full agreement with the examples you bring, relating to such issues arising from having rules for what documentation to use, what templates to apply, etc. If we were to look at the ‘complexity issue’ band, the examples you bring would sit at the ‘consensus end’ of that range, as it is likely most commentators would agree that standardizing these elements would be a positive and productive outcome.

      What I am referring to (and so do Ray Ozzie – the former Microsoft as a Chief Software Architect; Vivek Kundra – the person charged with the strategic direction of IT coordination across the entire federal U.S. government and more recently in the HBR Ron Ashkenas – managing partner of Schaffer Consulting) are those processes arising from the complex and convoluted IT organizational and technological structures, where the introduction of technologies necessitates the introduction of yet additional processes, all aimed (IMHO) to justify the existence of these organizational structures and the use of these technologies.

      I suspect this post should really be read in the context of another post I’ve published some time ago, titled “Too much technology will be harmful to your project” the key arguments in which were that
      1) There is a tendency in some organizations to impose overly engineered processes in a (futile) attempt to increase quality; and
      2) 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.

      The simple fact remains (and I’m just about to further elaborate this in a forthcoming article) that despite our best efforts we are yet to see substantial improvement in projects’ success rate. We live in a world where information is as available as ever before, blogs and research work are being used to disseminate and propagate ideas and advice; and yet, we still seem to be looking for the lost item under the street lamp – i.e. we’re attempting to increase quality by introducing more and more process. I strongly believe this is wrong, and the evidence seems to be on my side, not because I know how to fix it but because the evidence suggests in an indirect way that it simply does not work.

      Having said all the above I’m more than willing to be proven wrong and your perspective on my comments will be greatly appreciated.

      Reply

  4. Patrick & Shim –

    Allow me to interject here and say ‘I agree’ :)

    I agree with you that process is important…but that process has to be one that allows people to be people and allow for simplicity. Of course that’s much easier said than done :)

    I’ve often used the ‘process kills’ mantra in my career. That doesn’t mean I think all processes should be removed or ignored but many times we in IT & Project Management look to a process for an answer, when in fact the answer is staring at us outside of that process.

    Some of the best project manager’s I’ve ever worked with and for are those that know when to follow ‘the process’ and when to step outside the process to get the job done.

    Process are important and complexity is a part of life. That said, I think we in the IT and PM world have to keep our minds open to simplifying processes, infrastructure and organizations to allow for a much more effective approach to projects and IT management.

    Not sure if I’ve added any value to the conversation here but thought the discussion worthy of a few paragraphs.

    Reply

  5. Pingback: Shim Marom

  6. Pingback: Shim Marom

  7. Pingback: Good Process Bad Process And Everything In Between | quantmleap

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

%d bloggers like this: