We often talk about common problems occurring on a Software project such as not having the business executives on board, recruiting the wrong Project Manager, having too many projects running at once, etc. These problems are true and valid. But what I want to talk about today is a small list of more Human oriented problems; the kind of problems that are happening without anyone really noticing, and for that very reason, very dangerous ones. For simplicity matter, I will stick to only three Software Project Management Mistakes in this article.

Making too many assumptions

Motorway

Human beings are communicating with unique and extraordinarily rich medium: natural language. We use it every day in every circumstance to sort out any problem. But using words to communicate ideas and concepts is also very time consuming. As a result of that, because we are efficient, we make many assumptions about what the people we communicate with already know. For instance, if I say to a friend that I was driving 50km/h on the motorway or 180km/h, I do not have to explain that it is very slow or very high speed. With the slow speed, this person will immediately imagine that I must have had a good reason for doing so: traffic jam, fog, heavy rain, car problems, etc. I can assume that the person I am talking to knows that there is a speed limit on the motorway and that the speed limit is say 130km/h. I can also assume that this person knows how drivers would usually drive in the country I am, if speeding is common practice or very rare. I could even make assumptions about the knowledge the person I am talking to, has about the weather in that part of the world at that time of the year, etc. In short, I can make many assumptions. …And I do! We all do, all the time!

Unfortunately, this kind of communication behavior will be a reflex on a software project as well. And here come the troubles. Assuming too much can lead to very costly mistakes. We have to lower down our natural level of assumptions. The more assumptions we make, the faster we indeed go, but the more dangerous the communication is, project wise. On top of that, all cultures have different practices about the amount of assumption one makes when communicating. According to Edward T. Hall’s studies, for instance, Latin cultures make very serious assumptions (rich context) when Germans make very few in comparison (poor context). If by any chance you have people from diverse origins on your project, the risks are even higher!

Solution:  

  • Make the fewest assumptions you can when communicating key ideas and concepts on the project.
  • Do not take offense when someone is repeating the obvious, it might be a bit tedious but it is safer than not.
  • If you make assumptions, make sure that they are shared with the people you are communicating with.

Relying principally on written communication

Old writing

Since the invention of writing, we never stopped improving our tools for communicating in writing. The first books were rare and expensive and we have developed along the centuries a sense of high value to written documents.  After all, knowledge is stored and conveyed from humans to humans in writing. It must mean something! Information is brought to us in writing! We make a huge consummation of news in the modern world. And nowadays, writing is simpler than ever. Everyone can and everyone does.

As a result, Software projects have naturally relied a great deal on written documents. We write requirements, meetings minutes, memos, reports, tests, code, emails, etc. Our days are mostly made of writing stuff for a project.

The problem is that natural language in writing was never made for such a complicated job. If sending an invitation to a meeting in writing is fine, producing the minutes of the same meeting is another story. It is quite hard to translate all events, the atmosphere, the body language, the politics, etc. happening inside a meeting. If I write: “The Sponsor of the project acknowledged the progress of the project”, it does not tell you very much what the project sponsor really thinks or how positive she is. It may very well be that yes the progresses are acknowledged but the speed is actually totally unsatisfactory in her view.

If I write that “The vast majority of the application has been successfully tested” it does not tell you if the key parts have been tested or even if the results of the tests were positive (after all, I could very well be satisfied by the fact that the test suites have all run providing the expected results, but this does not say what the results were).

Nevertheless, we routinely use written communication as a main way of conveying information inside a project. This is a great source of troubles, misunderstandings and conflicts.

 Solution:

  • Never forget the intrinsic weakness of written language. Double check routinely that what you meant is what “they” got.
  • Enforce written communication by regular face-to-face meetings where everyone can read the others’ body language (80% of our real communication).
  • Do not start heavy written communication between people who have never met. If you do (you do not always travel the world to meet everyone), take extra care. Use videoconferences and if the opportunity comes, meet with your colleagues!

Confrontational attitude

Confrontational attitude during a software project

In the life of a group of individuals, there are necessary periods of tensions. There is nothing wrong with that. We have individual expectations, experiences, cultures, personalities, knowledge, skills, etc. This is, in essence what makes a group efficient: diversity. But this diversity does not always go smoothly. There is always a time when you can barely stand your colleague(s).

Conflict is created by a gap between expectation and delivery (or in other words reality). Disappointment, frustration are the common consequences of this gap. The immediate reaction is almost always the same: blaming the other(s). After all, aren’t we the perfect example of perfect behavior? The others have so many defaults!…

Well, no, this is not the case. No one is waking up in the morning thinking: “Great, let’s have another screwed-up day! Let’s be as bad as I can!” You and your colleagues, intend every day to be brilliant, clever, helpful, and shine as much as possible. But things happen and everything does not always go according to plan.

In case of conflict, a phenomenon happens that is named by the psychologists The Fundamental Attribution Error. Basically, when a conflict arises, everyone is making a causal explanation of the reason for the problem to happen. So, when I deliver a lecture, it happens that students arrive late. My first human reaction is to think that they are lazy and could have made an effort to arrive in time. If not lazy, you could use the word careless. But it is not occurring to me immediately that this student could have an external factor that stopped her to arrive in time. This could be anything, from a higher priority meeting for a fantastic job to an unpredictable event such as a car accident on the way. No, these reasons do not occur to us naturally. And during a conflict between 2 persons, we both make the same mistake: the other is intrinsically bad. On the other hand, when I make a mistake, the main reason is external to me. Something stopped me from doing well. At least, so I think.

As a result most conflicts start on the wrong foot: I am good intrinsically and you are bad intrinsically!

 Solution:

  • Always realize that this phenomenon is happening. Change your own attitude and give a chance to the opposition. This attitude will help on the majority of the conflicts you will encounter.
  • Give the opportunity to the “opposition” to present their views. Be open minded about it.
  • Do not forget that evil people doing badly for the sake of it are rare. We all crave for recognition and rewards from our peers. Failing is a pain for everyone.

Conclusion

IT projects, although focused around technology are made by and for human beings. At both sides of the production chain are bright, clever, amazing, …imperfect humans. As long as we keep that in mind and behave accordingly we put all the chances of success on our side. Yes, it might sound difficult, but no it is not impossible. Knowledge is essential and attitude is key!

Let’s think about IT!

Keywords: Software Project Management, Human dynamics, Project Mistakes, conflict management, Communication