“Simplicity is the ultimate sophistication.”
Leonardo Da Vinci
Some years ago, I presented a session on Benefits Management at an IT conference in Brisbane. At the end of my session a very serious looking person came up and introduced himself as a lecturer in IT at a Queensland university. He asked me for permission to use my ideas in his course and I had no problems in giving him permission. However, he hesitated and I asked him if there was anything else I could help him with. He smiled and said “Yes I do have a problem. You explained the model and approach in 30 minutes. I have to make it last a semester”. I couldn’t help thinking “Oh! You know how to stretch this out for a semester. Just make it more complex, use lots of big words, get the students to study more theoretical models of benefits and … there you go”. Perhaps you’ll see this as just my cynical view of academia but sometimes you just can’t make a powerful and simple model last a semester.
Welcome to simple versus complex.
Of course, there are areas of human endeavour, expertise, experience and knowledge where complex is real. Performing brain surgery using robots, designing and building a rocket ship for a Mars mission, conducting an election campaign, managing a program schedule with thousands of related tasks, maintaining a healthy, loving and supportive relationship with another human being … these are complex.
Unfortunately, in over 40 years of consulting, teaching and researching project management in many organisations, I have seen too many examples where the complexity of processes, standards, artefacts and behaviours were not inherent but rather, the result of people over-complicating fundamentally simple things.
In effect, there are two types of complexity. One is inherent, natural and intrinsic such as the interactions between CO2, deforestation, population growth and Global Warming – natural complexity if you will. The other complexity is un-natural, artificial and wasteful. This second type of complexity is the one that I am focussed on in this series of posts.
Observation 1: Complexity breeds complexity
I was fortunate to be a small part of the pre-history of Agile. In the late 1990’s I was based in the US and for a couple of years, a unique conference was held in Boston. Agile innovators such as Kent Beck, Jim Highsmith, Ken Schwaber, Alistair Coburn and I presented sessions and were on panels together. Often, since my perspective was always project management, I was the dissenting or disruptive member. For example, pure Agilists saw no role for project managers in the new Agile world – Product Owners and Scrum Masters were going to rule the universe. Right!
However, what we all agreed upon was the basic simplicity and truth of the Agile Manifesto and the simple concept that a co-located team of business and IT experts would dramatically out-perform the prevailing model where ad-hoc teams are formed, reformed with a mix of contractors, out-sourced experts and part-timers.
The fundamental idea of Agile (circa 2001) was based on simplicity and transparency. For a number of years Agile also worked (provided good coaching and support were sustained). However, in a pattern that we’ll talk about in this series of posts, a simple and proven idea had to become more complex as more people (and experts) became involved in the Agile movement.
A wonderful example of complexity upgrading to manage scale for Agile projects is the arrival of Features and Epics. As you will know, the fundamental building block of Agile development is the User Story. “As a user I would like …” The User Story could be described on a card including definitions of “Done”. The number of User Stories required was dependent upon the size of the project. However, some folks liked the idea of a Feature which would aggregate a number of User Stories and then, of course, then you needed an Epic that could aggregate a number of Features. So, you now had three concepts instead of one (In fact, some versions of Agile replace Feature with Theme further complicating things). So much for simplicity.
“What’s the problem?” you may be asking. Well, on more occasions than should happen, myself and some of my colleagues have been in Agile planning sessions where the debate was not about whether this User Story added more value than another User Story. The debate was “Is this a User Story or a Feature?” True! In one instance, the answer to the question was to engage the resident Agile expert who could arbitrate and decide User Story or Feature. Thank heavens they all knew it wasn’t an Epic .. or did they?
I am not arguing that there shouldn’t be some form of aggregation or hierarchy to deal with a large number of User Stories but, if you undertake a Google search to find a clear definition of the distinction between User Story, Feature and Epic, you’ll quickly find that a very large number of people are confused about the distinction or have very different views of that distinction (see https://softwareengineering.stackexchange.com/questions/182158/relationship-between-user-story-feature-and-epic). Perhaps one lesson here is that if you are going to add new concepts, to avoid raising complexity, you must have a very clear, precise and simple definition of the new concepts.
Let’s move to a more challenging example of complexity breeding complexity. Most organisations that have many projects have some standard development methodology (either Traditional/Waterfall or Agile). The basic idea is to provide a broadly adopted model that describes the phases of planning and development enabling consistent and transparent plans, tracking and reporting as well as other advantages. So, as an example, when one project reports that they are in Design everyone understands what that means. This is a simple idea.
Where the complexity emerges is when some folks add on top of the methodology, new elements such as phase stage gates, approval processes, mandatory artefacts and other control processes. So instead of providing a common framework across many projects and a basis for collecting time and cost metrics, the methodology has become a complex control eco-system.
In many cases, these enhanced methodologies often become a bureaucratic nightmare for project managers who have to complete forms, reports and gain sign-offs that have little to do with delivering value for customers but a lot to do about simply conforming. The CEB estimates that the average PM spends 30% of their time going through these control processes. My experience is that this estimate is accurate.
While the issue of methodologies and the associated control mechanisms is generally associated with Traditional or Waterfall development models, folks struggling with a feeling of loss of control though adopting Agile add similar requirements for integrated reporting, gates and so on to Agile models which are based on “face-to-face” reporting and control via retro’s and showcases. While there is a clear need for an organisation that has adopted Agile models to be able to govern at the portfolio level, in most cases, attempts to overlay standard reporting models that work on Waterfall projects generally raise complexity – which is directly against the Manifesto and Principles of Agile.
By adding unnecessary complexity, we have added waste, confusion and cost. Worse, this wasteful complexity often creates a cultural overlay where the frustration of people having to comply with these wasteful activities is broadened to negative views of the people and management who “enforce” these activities.
We’ll come back to methodologies and complexity in a later Observation. In the next post, I’ll look at the paradox of how smart people often handle simplicity.
Observation 2: Simple often challenges smart people
I have a really bad joke that I often tell in my workshops and seminars. You are at a party and meet a stranger. You ask the person what job they do at work. The person answers “Oh! I’m really into tasks and breaking them up into smaller tasks so that people can figure out which ones should happen before others.” Hmmm. You politely leave and go into another room. Meeting another new person, you ask the same question. The answer is “I’m into methodologies. I’m a methodologist” Wow! You now know who the smarter and more interesting person at this party is.
This is the complex and simple dilemma at its core. A simple Google search shows how much value is placed on being perceived as a smart person. A smart person is defined as a person “having or showing quick-witted intelligence”.
However, time and time again, when I have presented some simple and effective models for determining benefits, project success, risk assessment to people who are considered to be smart, I have seen how they struggle with “It can’t be that simple”. Years ago, I developed a simple model for project success based on 7 simple dimensions – stakeholder engagement, objectives, cost, budget, quality, benefits and team engagement. However, despite applying this model successfully on literally hundreds of projects, there have been a number of people who knew the model and, I worked with closely, who searched consistently for the 8th dimension. One colleague came to me excitedly “There is one that you have missed and I found it!” What that person had done was extract Customers from the Stakeholder dimension and declare it a separate dimension. Customers were already listed in the Stakeholder list!
As Shulamit Widawsky puts it “The smarter and more knowledgeable we are, the more we are aware of the breadth and depth of what we do not understand. So, we look for complexity or create complexity, even when simplicity would better fill the need. How can we know in advance, that a problem will be best served by simplifying, rather than by digging into the complexity?”
The question is “Why do some people constantly try to make things more complicated than they need to be?” I believe that some of the factors that drive people to unnecessarily over-complicate things are:
Ego. We all have one and, in many cases, demonstrating that you can both create and/or understand complex things that other people have to struggle to understand is a very powerful ego boost. Having someone say “How do you understand all of this complex stuff so well” is a very powerful feedback, as distinct from, someone saying “Well, what you are saying is just common sense”. I am speaking from a very personal perspective here as often the feedback from people who participated in my project management workshops is “What you showed us was just common sense”. To me, that is the greatest compliment of all. If you can get to the essence of a model which makes the model simpler to apply, that is “more common” you have been very smart. More on this paradox in the next observation.
Power. A very common source of power is expertise. If you are perceived as an expert and you can show that you are on top of complexity, many people will concede control (power) to you. After all you are the expert (especially if you can get a white lab coat). How many times have you been in a crisis meeting where the conversation from the experts goes like “We have encountered un-resolved performance issues which appear to be intermittent asynchronous time-outs within the Dual Aardvarker technology. As you know, we are a beta-test site and the vendor has given us access to their Dual Aardvarker Performance Architect who assures us that by applying a Self-referencing Discombulator patch we could resolve the situation. I hope that is clear to you all”? Translated … you should have never bought the Dual Aardvarker in the first place and your project is probably going to be way over budget and very late. Paradoxically, if you are an expert and you have the ability to communicate your expertise in a manner that really helps people to understand, in effect, share your expertise, you will generally increase your power. We’ll come back to this in Post 5.
Lack of trust. This is the most common cause of complexity in methodologies and very prevalent approaches to project governance. There are many people who believe that by being more prescriptive, more detailed and standardised processes you will gain more consistency and quality of work output. Indeed, this belief is the core of ISO and AS Quality standards and, as shown by Toyota, Mazda and other quality innovators in manufacturing and service organisations, is patently true. When applied to the more complex world of projects and the creative people who deliver projects, this belief in enforced standards can and does lead to un-necessary complexity. However, there is a group of people who really believe that, if you let people adjust processes and methodologies to eliminate barriers to delivery, the lowest common dominator will eventually prevail and chaos will emerge. A case in point is that it has been a common argument against Agile that Agile is just an excuse for people to cut corners and avoid controls. I have asked this question of many executives “Do you trust your people and assume that most people come to work to do the best they can?” Many of you will see that this is a slight reframing of the famous Steve Jobs statement “It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” It’s all about trust. If you trust people you can have simpler control processes and deal with those who can’t be trusted as exceptions, not as the norm. Clearly, how much trust can be allowed is very dependent upon the competency and skills of the people involved. Not everyone gets to hire only smart people and, while solving the issue of competency should be addressed through training or hiring different people, in some cases, careful use of controls may be the only option. As Ronald Reagan put is so well ‘Trust but verify”.
Curiosity. Albert Einstein states that “The important thing is not to stop questioning. Curiosity has its own reason for existing.” From early childhood, most of us have found that curiosity leads to discovery of new things and new perspectives. However, there are situations where curiosity can lead to people experimenting with, modifying and adding complexity to something that works typically resulting in it not working. A really good example of curiosity leading to un-necessary complexity is the strange case of Function Points. Most of you will not know this term. However, in the 1990’s, Function Points was a very powerful (and simple) method of estimating project cost/effort based on the relationship between the size of the problem and the effort to deliver a solution. However, some curious people then asked the question “What else can we use Function Points for?” An obvious answer was that by comparing two teams working on two projects delivering the same Function Point size you can determine the relative productivity of the two teams. However, Function Point calculations did not include factors that heavily influence productivity such as the level of sponsor support, experience of the team, co-location of team members, availability of tools, levels of shipped defects, etc. Using raw Function Points comparisons for productivity without these additional factors was highly flawed. As a result, becoming curious about other uses for Function Points and distorting the basic purpose of Function Points resulted in it being perceived as a crude control tool and the use of Function Points declined and is now lost. Which is why most of you haven’t heard of it!
Parkinson’s Law. Warning! This is pretty dark stuff. The statement that work expands to fill the available time, which is called Parkinson’s Law, is an uncomfortable truth for many people. A very common example of Parkinson’s Law is when you have 4 weeks to prepare for an exam, do a little bit of prep for 3.5 weeks leaving 3 days at the end for the real preparation. While Six-Sigma, Robotics and other techniques, effective at reducing waste, have become widely-implemented there are many folks who simply add unnecessary complexity to fill in time or to make their job more defensible (extremely negative view I accept). I have personally observed people add additional processes to existing models simply because they had time available and inventing a new process is fun – see Curiosity. Even in an era of corporate cutbacks, downsizing and use of AI and Robotics, where the amount of waste/slack in a job will continue to be reduced, there still will be people who will have time to add complexity to fill the day in and, in extreme cases, to make the job less suitable for automation. As the old quote says “The devil makes work for idle hands” could be restated as “Complexity makes work for idle hands”.
In the next post, we’ll look at the difference between simplicity and dumbing down.
.
Observation 3: Simple is not the same as “dumbing down”
“Dumbing down is the deliberate oversimplification of intellectual content in education, literature, and cinema, news,
video games and culture. The term “dumbing down” originated in 1933, ]as movie-business slang used by screenplay writers, meaning:
“[to] revise so as to appeal to those of little education or intelligence” Wikipedia
The differences between simplicity and dumbing down are generally very subtle. For example, Steve Job’s obsession with simplicity, for example, where he constantly challenged his designers working on the Apple iPhone to have only one button instead of two or three (one design had a different button each for Internet, phone and iPod) has been seen by other design experts as just an example of dumbing down and eliminating choice for users.
My view is that the simplicity is driven by eliminating un-necessary complexity without losing or distorting the truth or real value of the concept or idea. Dumbing down is a subtle distortion of the truth to hide complexity.
For example, in our approach to benefits management (introduced in Post 1), we have a practical and working model that recognises two very different types of benefits. One type of benefit is financial. The project results in changes that either increase revenues, reduce costs and so on. The other type of benefit is non-financial (i.e. non-monetised). The project produces changes that increases brand awareness, customer or staff satisfaction and engagement levels. Both types of benefits can and should be base-lined and measured.
The dumbed down version of types of benefits is that there are “hard” and “soft” or “tangible” and “in-tangible” benefits. In this version, the impact of the dumbing down is that there are projects where the benefits that are “soft” or “intangible” are not measured at all. After all they are intangible, aren’t they? Any serious examination of the typical intangible or soft benefits reveals that these benefits are, in fact, tangible, hard and add significant value. For example, if a project delivers a new policy that increases staff engagement and job satisfaction (both of which can be measured), hundreds of studies have shown that increased staff satisfaction leads directly to increased productivity, higher quality outputs and lower levels of turnover (all of which have a longer-term tangible/financial impact). The increasing use of Net Promoter Scores (NPS) by most organisations is another example of a “soft” benefit that can very quickly become a tangible benefit e.g. a project that makes it easier for customers to apply for a loan could be measured by an increase of NPS.
Perhaps a more disturbing example of simple not being the same as dumbing down is the common use of binary comparisons.
For well over a decade, advocates of Agile argue that Waterfall models of project delivery have failed and that Agile models address all the failures of Waterfall models. This binary dumbing down is very powerful. Agile is good, Waterfall sucks. However, as all of you know, Agile versus Waterfall is not that simple. Seven Consulting has identified a over 29 organisational and project factors that indicate whether a project is suitable for Agile or not (you are welcome to contact our Founder, Declan Boylan, if you would like to understand these factors – declan.boylan@sevenconsulting.com).
The fact that most Waterfall projects take too long to deliver was addressed long before Agile models emerged. Approaches emerging in the late 1980’s and 1990’s such as Fast-tracking and Time Boxing (a fundamental building block of Agile) and co-located teams of business and IT experts proved that Waterfall models could quickly deliver value. However, given that most organisations during that period were focussed on heavy methodology and control models such as C.M.M. and ISO certification, these innovations did not get traction leaving the door open for Agile models to emerge as an alternative approach.
Further, the Agile versus Waterfall dumb down ignores the fact that there are very few pure Agile projects. From my experience, the vast majority of projects will be a version of a hybrid involving some sub-projects being developed using Agile and some sub-projects using Waterfall. Further, Agile techniques such as daily stand-ups work just as well in a Waterfall project and a well-managed project schedule can be as powerful a visual tool as a Burn-down chart. Simple?
The Agile vs Waterfall binary dumb down, which can lead to Tribalism, is a perfect example of “deliberate oversimplification”. I know this will be seen as cynical but as long as people will pay to be certified in Agile or Waterfall (e.g. PMI), the binary debate will continue to confuse the truth … done properly by professionals both development models work!
More broadly, there are hundreds of books, papers and commentaries on the longer-term impact on our society of the dumbing-down trend. As early as 1990, Neil Postman in his wonderful book Amusing Ourselves to Death, argued that the shortening of news cycles and the decrease in amount of time spent discussing complex issues in most media outlets was lowering the level and intensity of public discourse. This was long before the arrival of iPhones, Twitter, Snapchat and other instant and on-demand gratification and distraction technologies.
Simplicity raises understanding without dumbing down natural complexity.
The next post looks at how unnecessary complexity makes it harder to see what is really going on.
Observation 4: Simple is more transparent, complex is more opaque
There is a wonderful paradox that we’ll explore in this post. The more complex you make things, the easier it is for people to confuse or hide the truth under that complexity. The simpler you make things, the easier it is to see what is going on.
I first really understood how increasing complexity can lead to greater ability to “get around things” when I was consulting with the Australian Tax Office many years ago. As the tax system was undergoing substantial changes with the introduction of new taxes such as Fringe Benefits, one ATO veteran commented to me “the more complex they make the legislation, the easier it is for certain people to find loopholes around it”. As a Parliamentary Committee in 2007 found, Australia’s tax laws are the third most complex in the world only behind the UK and India. To the cause of this complexity, the Parliamentary Committee stated “This has occurred because each set of interest groups have approached the tax system from their own particular perspective, instead of viewing it as a way of efficiently collecting revenue”. Simply as more people saw opportunities to use or challenge the tax system to their advantage, the more exceptions, new regulations and complexity were added to address the challenges of those various interest groups or stakeholders. In effect, as new interest groups emerge e.g. digital disruptors and the growth of global corporations, there is really no choice for governments but to increase the complexity of their tax laws and regulations enabling those who are being targeted to become more creative in finding loop-holes.
As we’ll now explore there are clear parallels between the growth of complexity in our tax laws and one of my favourite topics (remember Post 1) – project management methodologies.
Probably one of the most extreme examples of the dysfunctional impact of the complexity of these methodologies I found was in a leading Australian organisation a few year ago. Over a number of years of use this methodology had evolved (or devolved) to include over 500 individual artefacts (forms) that project managers, team members and sponsors could use to assist in delivering projects! Literally, there was a form for every contingency. There were standard Requirements templates (that didn’t address Agile), testing experts wanted forms for hand-overs, architects needed to approve proposed solutions, finance needed more detailed cost breakdowns, sponsors needed more information on their projects and so on. Different stakeholders’ requirements, all legitimate, adding more and more complexity (see Post 2).
A case in point was the standard Project Report which was meant to be produced monthly for the relevant Sponsor and his or her Steering Committee. The typical report was between 30 – 60 PowerPoint pages which took the Project manager up to 5 days to create. Filled with various RAG (Red, Amber, Green) reports on risks, issues, costs, scope and so on, multiple pages of financial data, complex technical updates these reports were often so complex that I struggled to get some sense of “the truth” of the project. Worse, these reports were being forwarded to very busy people who literally were reading the report for the first time during the Steering Committee meeting!
Given that all projects had a Business Case that was produced to get approval for the project, the most disturbing issue with the Project Report was that it could and, often did, contain changes to the project requiring approval that were never updated or reflected in the Business Case. In other words, a project could, through a series of Steering Committee meetings based around the Project Report, deviate substantially from the original purpose without anyone realising this had happened. Complexity rules. In other words, despite all the controls, artefacts and processes, it was relatively easy to hide the real status of the project.
As part of a refresh of that organisation’s approach to governing and managing projects, I implemented a simple model to replace the existing reporting cycle. To be honest, I was mirroring a concept developed by Taiichi Ohno, the Toyota guru, of Gemba. Gemba is a concept based on the idea that if an executive or manager wanted to really understand what was happening, rather than just reading reports filled with data, they should simply go to where the work was happening and talk with the people actually doing the work – a Gemba walk.
Instead of 60-page Project Reports, we implemented a simpler concept based around keeping the project’s Business Case updated and central to the conversation between the Sponsor (Steering Committee) and the Project Manager. The updated Business Case was the main focus of the status meeting and it was supported by a one to two-page update on costs and benefits updated project schedules. Other key project management information was also included when significant changes were being discussed. Given that the Business Case already included risks, costs, benefits and high-level schedules, etc., any changes to the Business Case which required the Sponsor’s decisions and approval were already documented – in the revised Business Case requiring approval!
The other simple idea was that all conversations between the Project Manager and Sponsor requiring consideration of options and decision-making were face-to-face. I also encouraged Sponsors to spend time with the team – where the team actually worked (a version of Gemba walk). Of course, many of you will realise that the Agile Manifesto and Agile Principles support the same ideas.
After a few months of using this revised model, the feedback from Sponsors and Project Managers was overwhelmingly positive. Waste was eliminated, substantial time was saved and projects became more transparent to Sponsors. It was also much harder for certain PM’s to “gloss over the truth”.
In the last post of this series, I’ll look at some simple ideas for you to eliminate unnecessary complexity in your work life.
Observation 5: Taking away complexity is simple – not easy
While consulting with many organisations struggling with the cost overheads and delays that un-necessary complexity has added to their ability to deliver change, I am constantly reminded of the 2nd Law of Thermodynamics. Please bear with me here.
This law states simply that when matter moves freely, entropy (disorder, complexity) in a closed system increases. To brilliantly illustrate how the 2nd Law of Thermodynamics operates, my colleague Daniel Freedman used the analogy of what often happens to empty garages when a new house is occupied. At first, the garage is used for the car but gradually boxes, used sports equipment, things that do not fit in the house, little bits and pieces are stored in the garage until there is no more room for the car. Unless some specific action is taken, for example, a trip to the waste recycling centre, this is too often the fate of garages and, in my experience, the bottom drawers in a kitchen which rapidly become the repository of pieces of string, useless kitchen appliances, tops of things and so on. Two examples of the 2nd Law of Thermodynamics in action.
Given some of the factors that drive people to increase complexity (remember Post 2), most organisations do not have a strategic plan to increase complexity, but, like our garages and kitchen drawers, without anyone noticing, little by little many people add little complexities that eventually result in an organisation’s processes and systems becoming overly-complex.
I believe all of us have some role in adding or supporting complexity and, more importantly, taking it away.
As an Agile transformation consultant, I start work with a client with a clear permission to find, evaluate and, if relevant, eliminate un-necessary complexity. However, I would be out of a job if more people in an organisation followed the following ideas and incrementally attacked creeping complexity.
Question its value. If you come across a process, form or standard that seems un-necessary or in-necessarily complex, see if you can understand the specific purpose of that process, what value does it add, what does it cost (time, effort) and, most importantly who requires it. In one of my clients, to progress a project beyond a certain point, a sign-off was required from the Enterprise Architecture group. This sign-off involved two different forms to be completed and generally involved a delay of at least 4 weeks. Some quick research revealed that the reason Enterprise Architecture required this process and associated documents was that some project managers had not been engaging architects effectively in the early stages of design. So, by placing a “hard gate” at the end of design, the problem was solved, right? No. By simply changing how and when project managers engaged Enterprise Architects, we managed to eliminate this process for the majority of projects. The architects were able to influence designs earlier to ensure the correct level of alignment to the target state they desired and signed-off in a simple email.
Become a historian. Very few people come to work with a specific desire to design a “stupid” process. Time and time again, I have come across complex and seemingly useless processes or behaviours that do not make sense. However, as I was taught by a wise person many years ago, there probably was a time in the past that there was a specific problem or situation that the process was designed to avoid or prevent and it made sense. A client of ours had a quarterly release process or cycle. Very quickly, it became clear that while all standard processes (testing, operational sign-off, etc.) were aligned to this quarterly cycle, weekly and sometimes, daily releases into production were happening, in a relative un-coordinated manner, as the window allowed in the quarterly cycle was too small for all the required system changes to be shipped. Of course, the inherent value of integrating all changes to production systems into a single window made absolute sense when it was introduced 5 years ago. Since that time, the organisation had undertaken a massive growth in demand for new systems and technology driven by competition. The world had changed but the old process was still treated as the standard … that, in reality, was no longer being followed. The organisation adopted a more flexible model for releases into production. Constantly challenging whether the current environment has changed resulting in a process becoming no longer being relevant is critical.
Propose a simpler alternative. One of the more perplexing behaviours I have seen in my consulting career is how easily the people who are experts in a process give up control of that process to another less-qualified person. Too many project managers, who are experts in planning and managing the delivery of projects, will complain about how much bureaucracy they have to endure from governance support groups rather than engaging these groups in proposing or finding simpler alternatives. I was consulting with a client who had very different behaviours across their various Steering Committees. Most PM’s had to spend days per month preparing PowerPoints and other reports prior to these reports being forwarded to the Sponsors and Steering Committees. However, one very professional Program Manager had developed an open and constructive relationship with his Sponsor which enabled him to not follow the accepted behaviour. He briefed her weekly and worked with her to restructure the Steering Committee to a smaller advisory panel. The Sponsor made all key decisions. As a result, the monthly Steering Committee process for the Program Manager’s projects was a short update conducted by the Sponsor. All relevant critical documents such as the Business Cases were kept up to date and the PMO, Finance and other support teams were engaged by the Program Manager typically in face-to-face meetings. Simpler, faster and more valuable and developed by the Program Manager and Sponsor. Eventually, this version of Steering Committees became the norm for the organisation.
Eliminate jargon where ever possible. This is a really powerful way to reduce complexity. Many years ago, I was learnt that a person who couldn’t explain a technical issue in simple English either didn’t want to (remember Power – Post 2) or didn’t understand the issue themselves. While jargon between people who share the same expertise can be very effective in shortening conversations and sharing learnings, it can also be a very destructive form of communication. The time-honoured game of Jargon Bingo shows how some people found the negative impact of jargon. I am not referring to dumbing down or use of euphemisms here, but rather taking the time to see if you can find a simpler way of explaining the “essence” of the complexity. It has been my learning that, while finding a simpler alternative to jargon can take some work and creativity, it always helps me gain a better understanding of whether I really understand the complexity of what I am trying to explain. Daniel Freedman’s example of a garage to explain the 2nd Law of Thermodynamics is a great example of jargon-busting. Better still, if you can find a way of explaining the jargon using the language, experience or context of the people you are communicating with … even more powerful. For example, if you were trying to explain Agile development to a group of medical experts you could use the example of an operating theatre team as a form of “Scrum”.
Don’t do it. Slightly risky but if you are not sure of the value of a process, artefact or control just don’t follow or use it. At worse, someone will let you know that you have not followed correct procedures and this will enable you to engage that person in an open conversation about why the procedure is required – see Question its value. At best, no one will notice which will really let you know how valuable the procedure is. Clearly, I am not arguing here for revolution or mindless rule breaking. You have a right to challenge seemingly un-necessary and time-wasting processes. Any saving of time, cost and frustration is an advantage to you and your organisation.
Final Post Comment
When I started to write this series of posts, I didn’t realise that I would be writing so many pages. Declan Boylan humorously reminded me of a quote attributed to Mark Twain “If I had more time, I would have written a shorter letter”.
I hope that as I shared my observations about simple versus complex I haven’t made it too complex. For those of you who are interested in exploring more about the power of simplicity I can recommend Ken Segall’s excellent 2013 book Insanely Simple: The Obsession That Drives Apple’s Success. As a key Apple person during the Steve Jobs era, Ken shows how Steve’s obsession with simple really did change the arch of technology. “Steve hit us with the simple stick” became a familiar phrase in Apple during the development of transforming technologies such as the iPhone.
Finally, when discussing simple and complex, I am always reminded of the words of Richard Riodan, who as Mayor of Los Angeles, was facing the difficult task of rebuilding the relationships within LA communities torn apart following the LA riots of the early 1990’s. Responding to critic’s comments that rebuilding trust simply required putting more money into destroyed communities and buildings, he replied “Simple and easy aren’t the same words”.
