The human factor

If you have been working in the IT industry for a while, it is probably not entirely new to you that projects don't always go as expected. They get delayed, people get fired, companies go bankrupt...

Ok, let's imagine a slightly less pessimistic scenario, one that each of us has probably gone through: A product launch has to be postponed, because one of the key features couldn't be delivered on time.

Finding the cause

When evaluating the reasons, it mostly comes down to some sort of communication issue. Which is true in the majority of the cases, because if a problem doesn't bubble up to the surface early enough, the solutions are postponed until the last minute.

But does this really take us to the very root of the problem? Or can the real problem also be something different, such as poor planning, lack of discipline, missing commitment or insufficient knowledge?

Usually, when making estimates, team members or freelancers are asked to provide an hourly breakdown of how much a certain project will take. Depending on each one's professional experience however, the level of precision can of course vary immensely.

One thing though that is hardly ever taken into account while doing this is the human factor.

Some examples

Since human beings are not machines, the success of a project still depends largely on the qualities of the people involved. So we have to pay attention to some very common aspects which can make people less productive:

• Unforeseen events
• Overestimation of ourselves
• Underestimation of the responsibility
• Unexpected dependencies
• Lack of knowledge
• Lack of commitment
• Laziness
• Depression
• Frustration

These kinds of issues can occur at any given time, and the consequence is most of the time that the project, or at least part of it, is at risk. So regardless of how meticulously you have planned everything in theory, the human factor still is a very critical factor.

What to do against it?

With careful planning, good communication skills and proper experience you can probably already anticipate some of the above mentioned issues, but there is still a lot of uncertainty left that you have to deal with. Here's what I have learned during my journey as a technical project lead:

Multiply your contractors' time

You receive an estimate for a certain deliverable (e.g. 2 weeks). Depending on how good you know the person, you can guess if this is a rough approximation, or if it is based on a highly detailed action plan. In any case, doubling the estimate before communicating it further makes perfect sense if you want to keep the supply chain unaffected.

Cover all responsibilities

It has happened more than once to me that quite important tasks during a project have not been noticed until the very end. This usually happens when the project hasn't been thought through from the beginning to the end, or when certain responsibilities haven't been assigned. It's actually a no-brainer, but requires some initial effort that we usually tend to avoid. Take the time to accurately think the whole product through from the beginning to the end.

Resolve dependencies

Since a chain is only as strong as its weakest link, be aware of all the external factors that affect your project. This can be most critical when using 3rd party plugins, where you expect a certain functionality to fit into your specific use case, and while testing it, find out that there are certain pitfalls. Testing and prototyping those critical components in the initial phase of your project is a good strategy to prevent such issues.

Adjust regularly

While there may exist a parallel universe in which an initial project timeline has been followed through as anticipated from the beginning until the end, on Planet Earth there are usually a lot of external factors that occur on a daily basis which affect your team members' progress. Make sure to review your targets and progress on a daily or weekly basis and re-arrange accordingly. It doesn't make sense to aim for objectives that have become unrealistic.

Be relentless

Some may remember the negotiation paradigm "Be hard on the problem, soft on the people". If you realize that one of your partners or team members is doing harm to your project, you should get rid of them. It doesn't mean you have to yell at them like Steve Jobs. There is probably a more friendly, human way to do so. But you should be thorough and decisive and do it early enough to not let it affect your project too much.

Create trust and ownership

People like to be trusted. Obviously the more involved someone feels the more she can live up to her potential. It also creates a sense of ownership when someone is given responsibility for a project, or at least part of it. Though it requires to provide a certain degree of operational freedom, it also guarantees that the person takes it seriously and won't let you down for random reasons.

Be human yourself

Ever told someone about a personal problem, like a disease or an embarrassing situation? They probably replied with a similar experience they had just to be empathetic. Show your human side, and people are going to be more honest to you. If you hide the truth from the people, they will probably be uncommunicative as well about their concerns. If you open yourself, people are going to do so as well.

Wrapping up

I hope this article has given you some ideas about the role of the human factor inside of projects from my point of view. I think it is a critical parameter in many companies and organizations, but it doesn't always get the deserved attention, since it cannot be measured as easily as other success parameters.

Please feel free to leave your thoughts about this topic if you have made any interesting observations in this field, or if you have made an experience that you think is worth sharing. Thanks for reading!