There are complicated and there are complex projects
(Part 2 of 2)
ADVISORY ARTICLE
By Charles Villanyi Bokor
Ottawa, Canada
“Got it.” Bob said in a manner that was most satisfying, because it made both of us feel that we understood that any easy, ‘off-the-cuff’ answer offered by an SME (subject mater expert) to a complex project’s problems, is probably going to be insufficient to actually solve the problem. So, the ensuing silence indicated that he was after a more thought out explanation of why his project was in trouble.
Life is simple, but for the decisions (we need to make)
“Many system development projects start out being relatively modest in size and relatively straight forward, as for example your project, which was to replace a legacy system.” I started out saying breaking the silence. “Generally, and exemplified by your case, the aim of a project is known and documented in the business case. When the existing business processes are to be left unchanged, whether they need to be reengineered or not, and no new functionality also known as new business requirement, is to be added to the expected output, the scope of the project is also known. So, the so called ‘high level’ system design, is straight forward, almost ‘doable over coffee on a napkin’. Therefore, based on the amount of work to be done dictated in part by the level of difficulty the project presents, the existing environmental capability and the operating executive governance, the trained professional project manager (PM) can define the resources and the skill level needed for an impending success. So, most people assume that development should be a ‘slam dunk’, and that the PM will produce the specified-in-the-design output, by following the PMI (Project Management Institute) manual and / or the dictates of the organization’s standard development methodology. However, often the results differ from expectations, as exemplified by many projects still struggling to deliver their new application systems years after they started development.
Unlike the jingle: “It all started with a big bang”, on the TV series called The Big Bang Theory, some projects start out as small-ish and then grow. Some also morph. According to one definition, when a project employs more than 25 people, goes on for over two and a half years, adds new stakeholders during development, uses up more than 60 person-years in developing over 100 thousand (K) lines of code (LOC) [1- Gibbs, 2013], and costs more than $10 million in development (excludes cost of deployment), it is said to be a different type of project. Some call such a project a Super Sized Project (SSP) [2- Villanyi Bokor, 2017].
For some of these SSPs, the number of planned tasks or steps, some of the planned tasks or steps, as well as the development methodology, have to be tweaked during the development cycle, due to changes to the technological platform (e.g. adoption of cloud computing), changes in the understanding of the problem, introduction of new constraints, changes in people and / or their existing relationships (caused by the addition and or replacement of the original stakeholders and / or executives conducting the oversight). In turn and as a consequence, these changes impact other project tasks or steps, so other unforeseeable changes have to be made. Rick Nason states (Preface xv) this as: “… what worked yesterday may not work today…”. So, it is to note that for these SSPs, continuous planning is more important than following the original plan, and their predefined outputs end up being somewhat different than what was originally planned. We will refer to these types of projects as complex [3-Nason, 2017].
Bob, the standard project development methodology was developed on the assumption that projects are complicated because they have a large number of interconnected parts. So, many PMs are trained to manage complicated projects. However, as a result of this, probably 19 out of 20 PMs will argue that there is no difference between complicated and complex projects, except of course in size, and that therefore all projects can be managed the same way. This is to be expected. “Paul Wason’s experiments in the 1960s on “confirmatory reasoning” revealed the human tendency to look for and select evidence that supports a particular hypothesis, rather than that [evidence] which contradicts it.” [4- Cooke-Davis, 2011] Further, most PMs (the (Solomon) Ash Conformity Experiment), [5- McLeod, 2018] are seriously bolstered by the views of others, and many do not have the authority to manage as they wish, thus they prioritize the safety of consensus, even if it differs from their professional opinion and allow ‘groupthink’ which often leads to flawed decision making. Arguing or thinking that these two types of projects are the same, does not make it so, even if that is the consensus of the majority. Remember most people will argue that there are 24 hours in the day, forgetting the 59 seconds. Some may think and argue that a Ferrari and a Jeep can both be driven through snow the same way because they are both cars, or that they both make financial sense, but that does not make it so. There is nothing wrong with PMI’s methodology and the preceding is not to argue that current project management practices and standards are to be updated, but that the current project development methodology is for managing simple and complicated projects “… that do not warrant the label “complex”. [6- Cooke-Davis, 2011]
More…
To read entire article, click here
How to cite this article: Villanyi Bokor, C. (2020). There are complicated and there are complex projects; The Problem with Complexity, Part 2, PM World Journal, Vol. IX, Issue XI, November. Available online at https://pmworldlibrary.net/wp-content/uploads/2020/11/pmwj99-Nov2020-Bokor-the-problem-with-complexity-2-complicated-and-complex-projects.pdf
About the Author
Charles Villanyi Bokor
Ottawa, Canada
Charles Villanyi Bokor is a Strategic Management Consultant focused on Leading to Better Decisions. Principal activities include Business Transformation, Problem Project Recovery & Leadership, and Strategic Planning. Charles works mostly in Ottawa but has successfully completed assignments in Florida, Wales, Malaysia, Sweden and Australia, and was key-note speaker in Johannesburg, South Africa and Victoria BC. Formal education includes an Executive Development and Diploma in Management (McGill), M.Sc. Mathematics (Université de Grenoble, and de Montréal) and B. Sc. Mathematics (Concordia). He is ITIL Certified, an ISP and a TBS Independent Project Reviewer and was Program Director of the Corporate Performance Management Program, Sprott, Carleton U.; Director of IS/IM at Royal Trust; and at Northern Telecom; CMC; CMC Board Member; PMI-OVOC Board Member; Governor of ICCC. Charles can be contacted at Charles_bokor@rogers.com.
