It doesn’t take expertise to fall

There is this one thing that often still surprises me while working. I have been working producing the creative side of IT projects for the last 15 to 18 years. And even with all the ranting I do about how things work, I still love what I do, almost every single day. And to be honest, all the things I write about are learning moments for me to. I have made my own financial and business mistakes and they have costed me a lot of money, but also delivered me a lot of experience. And I have taught myself to also learn from other ones’ mistakes, so that I will not make them too later on in life. But there is this one fault I see with almost every project that I run for smaller companies, or projects that are managed in a team for larger ones. People do not trust each other or don’t listen.

When you pick someone for your production, no matter if it is for a team or a company, in my mind you will pick out the people you need. And with that I don’t mean you should not be picky. I know it is a hard market out there, and sometimes it takes a lot of time to find the right people and have them work for you. And sometimes it might even seem to be impossible. But it is of so much importance not only that the people you work with are good in what they do, you also personally like working with them (because you have to) and you trust these people. When you have done your homework and built a business-plan or a project-plan you should already know who you need, which is half the work. One of the threats in your plan should already be; ‘what if you cannot get the right people in your team?’.

The reason why this is so important is because this is usually why a project fails before the product is released; people are good in what they do, but don’t see the overall picture.
I work on a daily basis with a programmer. I like working with this guy, he is pleasant to be around. He is not a top-level programmer, but getting better. But most of all, he starts to see beyond the scope of his code in projects, which took long, but at least he does.
Because for example, a programmer likes to see things in code. If you want something that loops 100 times and tells you in the end 42, then you will get that. For me personally, I would not like to work with this person then, because for me to like him to work with him, his response should be; sure, what do you need it for.
I am not a programmer, so why should I tell the programmer exactly what to do? I am interested in the result, and I want a programmer to be interested why he is building what I request.

This brings me back to what I wanted to write about. Because if a team is set up like this, you should be able to trust each and every member of the team. The problem is only one person that might be a problem; the owner of a project. That person is not selected, not reviewed, he or she is the one with the money. That puts him/her in an awkward position.

A good production team questions the authority. It should. A project owner should also not be afraid of it, and answer the questions that might rise. But then, the team should also know it’s area in the project. In the end, it is like a sports team, all in it for the success of the product, because it will be a win for everyone if it does.

That is in an Utopia. Because we all know that usually it doesn’t work like that. People who are not that good are usually excellent in appearing good in the selection procedures, personalities collide and people usually overestimate themselves. And a lot of people question authority, even when there is no reason to.

But even worse than that, is an owner who does not know his or her own production, who does not follow up on it. I had to deal with one project owner who had sent us out to produce a large online production that while we were creating it, he was trying to sell. The problem was, that he was more concerned about the sales-pitch than actually selling the product, so he lost touch with his own original project, and started selling what he thought the project should be in the future.
And suddenly, there they were, contracts, signed, for a product that we never even heard of. It had some small resemblance of the product we were working on, but it was like version 4 or 5 from it, maybe 2-3 years ahead. The problem on top of that was, that in the contract was a delivery date was set in 6 days.
The owner went almost ballistic when I questioned him about this, because, well, he was the boss and did not want his decision making process to be questioned. But he refused to realize that because of this, not even discussing delivery times, he would hurt himself a lot more. It would hurt his credibility with both the client as with the team working on the project. And a failing team-member could always be replaced, but the owner of a project can’t, although for the sake of the project, it might have been better to take a step away, or sit down once in a while and read the project plan, to see what the team is working on, and what the time lines are.

Now, this might sound like a unique situation, but it really is not. I have seen this many times happening. It is too bad, because at that moment you feel that a project might have a very big chance of failing.

The conclusion is mainly that the rules for a good production and production team are plain and simple, maybe an Utopia. But it takes even far less to make a winning production in an utter failure even during the production fase, that has nothing to do with the team or the product itself.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s