Project startup difficulties - The usual suspects

Posted by Filip Ekberg on 15 Apr 2013

Preface

The following article is an article that I wrote duing my studies for a bachelor degree in Software Engineering. Minor changes might have been made to make it more suitable on this website.

Both my experience and writing style has changed since I wrote this article, but I still want to share my thoughts from 4 years ago.

Let me know in the comments below what your most common project startup difficulties have been!

Abstract

There are a lot of usual suspects in the terms of risks, problems and other aspects of failure that you need to take in mind, worry less about the customer and more about the communication. This is highly important for success; you must find your way of communicating.

Be prepared; There will be problems

In the writing moment of 2009 I am currently in a development project of which I have the benefits of being System Architect. Having this position in a project is not something that is totally new to me; in 2008 I had the same benefit.

This experience of mine will be used as a reference point, so keep in mind that my points of view is not strictly from a developers eyes. Being the System Architect you have a lot of responsibility such as keeping track of each developers work process, extending each person’s views of the project and being a leader which never falls apart.

Starting a project, not just development projects but generally speaking you face a lot of common problems; team-work issues, financial issues, third-parties, customer issues and many more. I will not focus on the financial issues because the project we current work on is strictly, as they would say in the world of lawyers, pro bono; which is what we mortals would call free.

So not having to worry about the financial problems, we can focus more on the other areas, which in my eyes actually does cause problems and have as it does in many cases, caused problems in our project. Problems don’t always mean that the project fails or that everything falls apart, it just means that we have something to handle. We also have problems that are planned or more likely anticipated more than planned; a planned problem would be fixed before it became an issue.

The usual suspects

As mentioned in the previous part there are a couple of problems that you might anticipate in your project. There is no common solution that’s widely used on all projects. As a lot of other things in this world; things are different depending on the situation. This is the case of projects as well. I will merely give an overview of what could be expected and how I would like them to be handled.

Team-work issues

Reflect over the following; is there anything like perfect team-work? I once said: Team-work comes from willing to cooperate it is not something that can be forced. It doesn’t matter how different you are; as far as we know, everyone is different. I would like to say something like: just work together, what is the problem?

However that statement is bold and doesn’t apply to reality. As mentioned earlier I work in a project, the project consists of 9 other developers where 7 of them are security experts and two of them are, just as me, software engineers. If you look closely enough you can see that there are a couple of things on both sides that resemble a similarity. The security experts have one way of solving problems and the engineers have another, what we need to achieve here is a common ground of both problem solving and the way of communicating.

Our project started out great, there were no direct flaws in the team-work, all parties liked to work together and we solved communication and other future problems very fast. However, as the project has evolved so has the teamwork, but has it evolved enough? As there is no direct answer to that, I can only speculate on the different outcome of today’s progress if we would’ve evolved more with the project.

As of the beginning, there were no issues with the team-work, we did not even argue about small things which can be a big problem in many projects. However as everything evolved and third-party problems came in place, we did come to the stage where we had to raise voices and stand ground.

Not all projects start out with a nearly perfect chemistry between its participants. And maybe it would be for the better to argue it all out in the beginning, finding all these communicational problems from the start and work from there? The outcome from our project is that you start to take things for granted, which is a dangerous path to take.

Customer related issues

The first thing that really comes in mind when I write "Customer related issues" is a direct link to money. No matter how you bend on in, when it comes to the customer, it’s always a matter of money. As for our project, this is somewhat a problem as well. Now, you might recall that this project is what we call it "pro bono"; free; gratis. So, what could possible be customer related that has to do with money? Well in our case the customer buys hardware for us, which they want to be further developed, this hardware is in a development stage and therefore not well documented. This means that we need to contact the producer of the product to get information. However, the producer being one of the world’s biggest companies; they do know when to ask for money.

Now this gives us a big problem, since the project doesn’t have any revenue we can’t afford this, so we need to ask our customer to pay for this. This results in a great problem;

• The customer places an order
• The customer expects everything to be done according to plan
• The customer is expecting everything free of charge

Now, the last two stated points above in the work-flow is where our problem is. Is there a solution to this? The project could be delayed, we could be put up in a workpool for other projects to gather resources from meanwhile the producer evolves the product and set up a proper documentation for it. However, we don’t have that time, so what has to be done is either brute-forcing the system gathering all information possible to solve it, or we ask the customer to pay for the education needed by the producer.

In our case the customer actually paid for this education, because this product is very important and scheduled to be delivered and sold after the summer 2009.

There are however a lot of problems not related directly to money, you can see these other problems a lot in the IT Consulting business where I usually work;

• Non-cooperative customers
• The all-knowing customer
• The non-paying customer
• The customer who says one thing and the customer who wants something else

I’m going to state something that many would disagree on; never trust the customer. You might get a surprised face when reading that, but in fact you should trust anyone than yourself; if you can even do that.

Now this is becoming fairly abstract but stay with me on this. If you really think about it, if you start trusting people you suddenly start relying on others to do what they say, always assume people are going to be late and if the customer says "How long will x take to develop?"; The first ting you need to think about is, does it take T hours? Does it take T – 100 hours? What’s the most accurate time? Before you say that, add a factor of 2. So, why add the factor of 2? Because you always over-estimate your skills, you might think that it takes 10 hours, but it takes 20 hours or even thirty hours. If you over-estimated and said for instance 50 hours, and it took only 25, your customer will be very satisfied. But if I take 100 hours and you said 50, you will have a big customer problem.

Managing the Team to avoid these problems

A great leader is one that makes the workers think they are doing everything that will benefit themselves. In my eyes a project manager is, or should be, very much like a great dictator; A great leader. If you were to revise the book The Deadline3 you would see how they speak of their mangers and what really makes a good project manager. Some of the points that you would consider is:

• The co-workers speaks well of you
• You are considerably good at understanding people
• Not scared of taking chances
• Risk your job every day

As a project manager you might need to risk your job every day, this meaning that you must do things that will benefit the group or the project in longer terms but might not be so good for yourself in the current situation. Managing a software project is just a game of risk management, if you were to find all casual risks and manage them, what else would there be to worry about?

Follow @fekberg