eight to late

My five year old son looked out through our living room window this morning and said, “Dad, I can’t write on the window today.”

“Hmm…,” I said, not really listening. I continued with my breakfast, looking down at the article I was reading.

He repeated, “I can’t write on the window.” Then added, “I did yesterday but I can’t today.”  …And shortly after came the inevitable, “Why?”

I looked up and realised what he was talking about: there was no condensation on the window. Yesterday  morning our windows had a thin veil of condensation on which he could write with his finger. But it was less humid today, so the panes were clear. There would be no writing today. Quite naturally, he wanted to know why.

I launched into a long-winded explanation about water vapour, temperature and condensation. He listened to me politely, but (obviously) didn’t really understand what I was going on about.

I stopped. There had to be a better way to explain this to a five year old.

I got up and went to the kitchen. “Let me show you something,” I said. The little fellow followed, with a somewhat dubious look on his face. I had lost credibility and he wasn’t about to cut me any slack.

I filled the kettle with some water and turned it on.

 ”Wait and watch,” I said, unfolding a step ladder so he could have a good look-see at what was happening.

He clambered on and watched as I held up a glass near the spout. I had his attention now.  “Tell me when  you see something,”  I said.

“I see it now, I see it now,” he said, pointing excitedly at a sheen of condensation on the glass. “I can write on the glass!”

I launched into another explanation of water vapour, humidity and condensation. But this time I could see that I was getting through. He listened, and asked questions which I answered as best I could. It was great!

I was late for work this morning, but it was worth it.  I’d  been given a refresher course on a vital aspect of communication: show, don’t tell.

I’ll start with a story that may sound familiar to some of you.

A project team member - let’s call him Ernest  -  appears to be a major asset to the team.  He is enthusiastic, volunteers to do stuff others don’t want to do and is always (seemingly) on the ball. The problem is most of his work is shoddy, riddled with errors and has to be redone. Worse, this is starting to have a negative knock-on effect on other deliverables. Other team members are having to clean up the mess and  are beginning to resent it. Yet Ernest is blissfully unaware of the repercussions of his earnest efforts. By his estimation, he’s doing a fine job and, quite naturally, expects to be rewarded for it.

It is clear the project manager has to do something about Ernest. Trouble is she can’t. She has no say in the composition of his team, and the functional manager to whom Ernest reports reckons that  Ernie is the best thing that happened to the company in a long time. Our PM’s in a pickle; one which I reckon isn’t an uncommon one.

There are two factors at work here:

• Ernest thinks he’s (way) more competent than he actually is.
• He isn’t aware of his shortcomings.

This story is an illustration of the Dunning-Kruger Effect, so named after the authors of this paper, published in the Journal of Personality and Social Psychology in 1999. In the paper the authors demonstrated, through a series of experiments, that less skilled individuals tend to:

• Overestimate their competence. 
• Fail to recognise the extent of their lack of skills.  

The paper suggests that improving the skills of such individuals not only increases their competence, but also helps them recognise and acknowledge their prior lack of skills - i.e. it improves their ability for self-assessment.

I should mention that not all authors agree with Dunning and Kruger (see this paper, for example). However, in a recent paper,  Dunning and others appear to address many criticisms that were levelled at the original work. So the current academic consensus seems to be  that the Dunning-Kruger effect is real.

So, going back to my original story, what can the project manager do about Ernest? Remember, Ernie can’t be relieved of his project duties because he has his manager’s backing.

The PM has a few options which I outline below:

• Provide Ernest with honest feedback. This has to be done with care as Ernest reckons he’s doing a great job. The PM should also be sure to provide Ernest with positive feedback where possible - compliment him on his enthusiasm, readiness to take on tasks etc.
• Channel Ernest’s positive qualities to good use. One way our PM could do this is to position less critical tasks as important, and suggest (or gently insist!) that Ernest take responsibility for them. This needs to be done carefully, as the PM needs to ensure that Ernest remains motivated.
• Suggest concrete actions that might help Ernest improve the quality of his work. This option is usually considered to be a non-starter given that there’s no time (or budget) for training in the middle of a project. However, there are a few other ways to achieve this: informal coaching, mentoring for example. These, however, are difficult to put into action because it is difficult to find time to coach or mentor while a project’s in progress. Besides, Ernest has to be willing to acknowledge and accept his shortcomings.

At all times, the PM has to be cognisant of the effect of the effect her actions (or inaction, for that matter!)  on team morale. Plummeting morale is the last thing she needs in the middle of a project.

I’m sure most project managers would have had first-hand experience of dealing with individuals like Ernest. If so, they’ll know that fixing the problem is hard, especially if the project manager has no authority over team composition. Although I’ve suggested some strategies to deal with such individuals, I acknowledge that the solutions can be difficult, time consuming and expensive to implement; especially in stressed-out project environments.

As Dunning points out in  this article, we’re strangers to ourselves. So we’re all potential victims of this effect (yes, I realise that includes me too!). Having said that, I leave you now to ponder this question: how do you rate your competence as a project manager? 

This is a tale of distress
caused by a system on Access,
which failed one day
in a spectacular way,
leaving users in a bit of a mess.

File-based databases are prone
to crashing for reasons unknown.
So it was no surprise
to the IT guy.
“I knew it would happen,” he groaned.

The boss went totally ballistic,
turning red and apoplectic.
He told the IT guy,
“It will be good-bye
unless you get off your rear and fix it.”

On hearing he could be history,
the IT guy rolled up his sleeves
and tried to revive
the system that died,
but gray stayed the monitor screen.

The lesson to learn from this tale
is to backup your systems each day.
Disaster can strike
any time, day or night .
Be prepared! It’s the only way.

Several years ago Fredrick Brooks wrote his well known article, No Silver Bullet , in which he explained why software development is intrinsically hard. I believe many of the issues that make software development inherently difficult have close parallels in IT project management - parallels which apply even in projects that don’t involve much writing of code. In this post I look at Brooks’ article from the perspective of an IT project manager, with a view to gaining some insight into why managing IT projects is hard.

Brooks defines the essence of a software entity as, “…a construct of interlocking concepts: data sets, relationships among data items, algorithms and invocations of functions…” This construct is abstract; that is, it has many different representations or implementations. A line later he states, “…I believe the hard part of building software to be specification, design and testing of the construct, not the labor of representing it and testing the fidelity of the representation…” The connection with project management (especially, IT project management) is immediately apparent: the hard part in many projects is figuring out what needs to be done, not actually doing it. Put another way, requirements, rather than implementation, are the key to successful projects. Project management methodologies deal with implementation reasonably well, but have little to say on how requirements should be elicited. Why is this so? To answer this it is helpful to take a closer look at the parallels between inherent properties of software entities (as elucidated by Brooks) and IT projects.

According to Brooks, the essence of software systems (as defined above) is irreducible - i.e. it cannot be simplified further. This irreducible essence, he claims, has the following inherent properties: complexity, conformity, changeability and invisibility. These characteristics are present in any non-trivial software entity. Furthermore - and this is the crux of the matter- any advances in software engineering or development methodologies cannot, in principle, solve difficulties that arise from these inherent properties. I discuss these properties and some of their consequences below, pointing out the very close connections with IT project management.

• Complexity: Brooks describes software entities as complex in that no two parts are alike. This complexity increases exponentially with entity size. Deriving from this complexity, he says, are issues of difficulty of communication among team members leading to product flaws, cost overruns and schedule delays. This should sound extremely familiar to IT project managers.In an earlier post I looked into definitions of project complexity. In a nutshell, there are two dimensions of project complexity: technical and management (or business) complexity. Brooks defines complexity in technical terms, as he is concerned with building software. However, in large part the complexity he talks about arises from business complexity (or complex user requirements). The latter is often what makes IT projects difficult, even when there’s not much actual code cutting involved. Furthermore, this characteristic is intrinsic to all but the most trivial IT projects.
• Conformity: software entities must conform to constraints of the environment into which they are introduced. To paraphrase Brooks, “…These constraints are often arbitrary, forced without rhyme or reason by the many human institutions and systems to which interfaces must conform…” This too has obvious parallels with IT project management - the deliverables of any IT project have to fit into the environment they are intended for. This fit has to be at the technical level (eg: interfaces) but also at the business level (eg: processes). I’m sure many IT project managers would agree that the technical and business constraints imposed on them are often arbitrary (but compliance is always mandatory!). So we see that this characteristic, too, is intrinsic to most business and technical environments in which projects are conceived and implemented.
• Changeability: Brooks describes the software entity as being “…constantly subject to pressures for change…” This, he reckons, is partly because software embodies function (i.e. it does something useful) and partly because it is perceived as being easy to change (italics mine). One would think twice (or many more times!) before asking for large-scale changes to a building that has already been erected, but there’s considerably less restraint shown when asking for major changes to software. This, again, has parallels with IT project management – shifting requirements are the norm, despite the high cost in terms of time, if not money. Change control processes are put in place to dampen this tendency, but it is ubiquitous nonetheless.
• Invisibility: According to Brooks, software entities are, “… invisible and unvisualizable…,” in all but the simplest cases. Unlike the floor plan of a building, which helps project personnel visualise the finished product, no pictorial model is available to software builders. Sure, modelling techniques do exist, but they do not (and cannot!) depict the complexity of a non-trivial software system in any meaningful way. This, says Brooks, “…not only impedes the process of design within one’s mind, it severely hinders communication among minds…” Here too, the parallels with IT project management are clear – communicating the requirements of the project would be so much simpler if there were a visual representation of what’s required. If Brooks is right, though, a search for such a representation is akin to the search for the philosopher’s stone.

Yet, Brooks is not a pessimist. Towards the end of his article, he mentions some techniques that can alleviate some of the essential difficulties of building software. These include: rapid prototyping and iterative / incremental approaches. Grow software, he says, instead of building it. Such an approach, which incorporates frequent interactions between users and developers, reduces risk associated with missed or misunderstood requirements and clarifies design in small, digestible steps. This is also good advice for IT project managers, as I’ve pointed out in a previous post.

In the last section of his article, Brooks states, “The central question of how to improve the software centers, as it always has, on people” and then goes on to discuss how talented designers (or architects) can greatly reduce the essential difficulties in building software. I believe the parallel here is between designers and project managers. A talented project manager can make all the difference between the success and failure of an IT project. What are the attributes of a talented project manager? Well, that’s a topic for another post, but I think most of us who’ve worked in the field can recognise a good project manager when we see one.

Brooks believes the essential difficulties associated with building software make silver bullet solutions impossible, in principle. The parallels outlined above lead me to believe that the same applies to project management. Methodologies may help us along the road to project success (and some do so more than others! ), but there are no silver bullets : managing IT projects is intrinsically hard.

The adjective complex is often used to describe projects that are in some sense hard. I’ve used the term without defining it in a few of my previous articles on this blog  (see my post entitled, rumours of a new project management paradigm, for example).  I’m sure most project managers (PMs) have at least a qualitative notion of what makes a project complex. However, if you ask a bunch of PMs what the term means, you’d probably get answers varying from, “large projects involving many people” to “projects involving unfamiliar or new technologies”. It is worth gaining a general understanding of  the term because it is often used in project management practice and research. Hence my motivation for this short, critical look at a few definitions and measures of project complexity.

A good place to start is with Dr. Lew Ireland’s paper entitled Project Complexity: A Brief Exposure to Difficult Situations. In the paper, Dr. Ireland identifies two dimensions of project complexity:

• Technical Complexity: This includes all technical aspects of the project, such as,
  • Number of technologies involved
  • Familiarity of team with technologies
  • Bleeding edge or well established technology.
  • Number of technical interfaces
• Management Complexity: This includes all business and organisational aspects of the project, such as,
  • Project staffing and management (team composition, size, management hierarchy etc.)
  • Number of parties involved (external vendors, internal departments etc.)
  • Change-related issues.
  • Stability and complexity of requirements
  • Political issues
  • Time / cost issues etc.

Dr. Ireland also highlights the need to identify and understand the elements of complexity in every project.  He does this by describing a few real-life cases of complex projects which went wrong.

The approach described above is similar to that outlined in The Project Manager’s Desk Reference by James Lewis. In the book, Lewis identifies four kinds of projects on the basis of the two dimensions listed above (note that he uses the term business complexity instead of management complexity). These are:

• Type IV (Routine project): low technical and business complexity
• Type III: low technical complexity but high business complexity
• Type II: high technical complexity but low business complexity
• Type I (Complex Project): high technical and business complexity

One can get quite specific in defining dimensions, but some caution is necessary. As the number of dimensions increase, individual dimensions become narrower in scope and there’s a danger that some elements of complexity will not be captured.  How this might happen is best illustrated through an example. Consider this project complexity model which uses the following eight dimensions:

1. Time / cost
2. Team size
3. Team composition
4. Competing demands
5. Problem / solution clarity
6. Stability of requirements
7. Strategic importance / political implications / number of stakeholders
8. Level of change

Question: Look at these measures carefully. Is there something missing?  

Answer:  All the listed measures relate to business complexity. There is no measure of technical complexity!

So I end  this note with the following: It is important to understand what is meant by project complexity because the term is often used by project management professionals in conference presentations, trade journal articles and research papers (and blogs!). However, it is equally important to ensure that the elements used in a definition capture all relevant aspects of complexity in projects.