Category Archives: Project management

Project management deals with issues like scheduling, planning game and going through the plan.

How to Dramatically Get More Time By Using This Simple Principle

Yesterday I was watching an old The Apprentice show where one guy got fired because he wasn’t accomplishing much and was simply talking too much (as mister Trump put it). Naturally I realize that the show is edited and scenes are cut, so it’s not possible to really know if the guy was helping the team or not. Whatever the case, the bottom line was that others thought that this guy couldn’t get to the point – and eventually he got fired.

Not sure if people usually get fired because they cannot get to the point, but I was a bit surprised to see this element to be so important for Trump. Getting to the point was so important that it cost a job for this guy. In the show, Trump said: “I keep meetings short and to the point. There’s so few hours in a day, and I want to accomplish as much as possible.”

Whether or not you like The Apprentice show (or pay attention to Donald Trump) I still think the lesson is important: don’t waste time, get to the point.

Having useless meetings or postponing decisions over and over are two examples of how you can waste time. I think if there’s a need to chat with somebody about business, then make darn sure you have an idea about what you need to accomplish. Having meetings to “discuss ideas” or “brainstorm together” are nice… but I’m not sure if these type of meetings really deserve much attention. If you need to “discuss ideas” – then be 100% clear on what you need to accomplish. What’s the goal of “discussing ideas”? Will you have another meeting to “discuss more ideas”? When will that end? Or will you make one meeting to “discuss ideas” and then decide whether to proceed after that initial meeting?

I was asked to travel to another city for a business meeting. Before I agreed to travel, I simply asked: could we deal it over a phone or skype? The guy said “sure”. After 15 minutes of talk we realized that there was no mutual benefits for discussing any further, so we simply thanked each other and ended the conversation. I could have spent 5 hours in a train to get back and forth for a 15 minutes talk, but I knew our first meeting could be handled via skype would be sufficient. I wanted to get to the point via phone, and not waste time. Simple as that.

Do you waste time… or do you get to the point?

7 Deadly Management Sins

#1 – Dictatorship
“You are wrong, I’m right” attitude (or “it’s my way, or the highway”) is a deadly management sin. The guy who “leads” the team by dictatorship will soon be left alone with nobody to manage. Game producers and managers need to be ready to make tough decisions and tell how things will be done – but not always. Stubborn attitude leads to getting stuck – and nobody follows a dictator forever.

#2 – Lack of focus in production
Aimless game production or project work is another deadly sin: it leads to clueless work, that results to nothing. If there are huge number of open issues and possibilities then it might mean slowed progress as no decisions are being made. If the team is focussed on making progress through certain path, then it’s much more likely to get the project finished. Lacking clear focus and objectives are killing mistakes in game production.

#3 – Forgetting your team members when they’ve done a good job
Here’s a simple test for any manager out there. Simply answer yes or no in the following two questions.

Question number one:

“Have you noticed some poor work by your team members and required it to be re-done in your current project?”

Question number two:

“Have you given praise to your team members for some good work done within this month?”

If you answered “Yes” to both of the following questions, then you are in the right path. If you answered “Yes” only the first question – then you seriously should think about your current management style. Other combinations are possible, but the bottom line is: you have to make sure you keep certain level of quality, and make darn sure that you let your team members know when they’ve done a good job.

#4 – Not focusing on the outcome
Focus on results. That’s a simple piece of advice that’s so easy to forget. Sometimes there might be team members who like to do things on their way, and “not by the book”. As long as these team members produce the necessary results and don’t harm the team work, there’s no reason to require them to “work like everybody else”.

Some people insist that there must be certain working hours, but if somebody wants to take 1 hour nap during the day – that shouldn’t be a problem. If somebody would spend half day meditating, yet achieving twice as much as the rest of the team: there shouldn’t be any problem with this guy’s habits. As long as they are ethical, legal (you have to think your company), are align with the company values and vision (for example: there might be certain requirements for company image) then it shouldn’t be a problem.

I try to follow the guideline to let team members do almost whatever they want (notice the word “almost”) – as long as they get the job done. When I’m outsourcing some tasks, I really don’t care if they use voodoo dolls and prayers when they are coding: as long as the code is done as it was agreed, and as long as they produce good results – I couldn’t care less how it was done.

If focusing results works in outsourcing, why shouldn’t it work also work done in-house?

#5 – Getting nice people, instead of right people in the team
Another deadly sin: getting nice people instead of right people. I don’t put much focus on whether the team members should be friends or not (for the reason that was mentioned in the previous chapter), but I can assure you that “being nice” alone cannot be the factor when deciding who gets in the team.

Some project teams are almost build like that: everybody gets to join and the guideline is “we just have fun making games”. While that is a noble idea… I really don’t think it will be such a good long-term solution. Taking everybody who is “nice and interested about the project” doesn’t guarantee that you get the rights persons to do the right job.

Instead of “nice persons”, pick “nice persons who have the necessary skills to produce the results you want”.

#6 – Asking recommendations, and then ignoring them
I’ve mentioned this earlier, but I have to say this again as this is one sure-way methods to kill the team spirit. If you ask recommendations from your team members: then make 100% sure that you actually check out those recommendations and consider them.

If you’ve already decided what you are going to do – then there’s no point pretending anything else. Team members will be much more grateful for a leader who tells them what to do than for a leader who asks recommendations and then does whatever he had already decided.

#7 – Not taking into account team members’ personal life
There are situations in every people’s lives that might affect to the work. Sometimes these can be very sensitive issues, and if you don’t notice what’s going on in team members’ personal lives – then you might end up seeing somebody’s work performance going down, or somebody even leaving the team for no apparent reason. It’s a deadly sin to forget that there’s life outside work.

7 Lessons I Learned From Playing Baseball

I played baseball for over 10 years in the past and there are some lessons that are applicable also to game production and leadership.

#1 – Sometimes there are not so good days
I remember when I was about 15 years old and on one summer I was learning to hit the ball to pretty long distances. Our coach was pleased with this and we trained this “new trick” over and over before the upcoming match.

When the match started, I remember getting instructions from the coach to try hitting those long shots I took earlier when training. I didn’t manage to hit the ball long even once. The coach was patient and we both knew what I should do and kept trying. In the end I had several opportunities to try hitting the ball as long as possible, but couldn’t succeed no matter how hard I tried. It just wasn’t my day that day – and coach also understood that.

Some days just are like that – you cannot expect every day to be all glory.

#2 – Sometimes there are good days
Then on the other hand I remember playing one of the best matches sometime before I quit playing baseball. I was maybe 18 or 19 and remember that no matter what I tried to do – I succeeded. I remember I hit short distances and long distances, and everything I did happened the way I wanted. I even remember when I hit one poor ball and accidentally the ball flew in a good spot. Even when I “failed”, for some reason I was lucky and got it right.

I’ve noticed that this happens also in game production (and life in general): sometimes there are good days, and sometimes not so good days. Sometimes things just don’t go well, but you have to keep doing what you want and eventually at some day everything will go the right way.

#3 – Concentrate on your own game
This is something I learned from the matches: I don’t think we ever had the problem that we would had need to watch for the mistakes made by the opponent. Most of the time the problem was our own game: we had to concentrate on our own game and keep it simple.

I think checking out competition in games and in business is okay, but I also think focusing too much on the competition is not going to help you. Basically I think you gotta do a darn good job by yourself. Balance is needed in this.

#4 – Don’t shout at the judges
I think I’ve heard our team members shouting at judges and complaining about their decisions hundreds of times. What I don’t recall is that it would have helped even once: the judges who were shouted at turned even more stubborn – and it probably did more harm than good to complain.

I don’t see there’s much reason to shout or whine (in baseball, life, work – or anywhere). If you have something to tell, you can tell what you think about and that’s it. Getting somebody on your side is not going to happen by shouting at him – this will probably just reinforce the opposite view.

The way to get people to see your point-of-view, is to first look at the situation from their point-of-view. Agreeing on something, and then presenting your alternative ideas gently.

#5 – Too heavy baseball batt should be changed
When I was a kid, I remember I was hitting the ball with a too heavy baseball batt – and it sure didn’t go well. There was a simple solution to this problem: a lighter batt!

Similarly in game production you really have to ponder what kind of tools you really need. You don’t need to have the most complex, the most expensive production software. Sometimes switching to a lighter alternatives might make things easier.

Just because “everybody else is using complex tools” doesn’t mean you should too.

#6 – Roles are important
I usually was player number 2, which meant I usually needed to get the first player from base one to base two. I sort of “specialized” in this job, and it suited well for me. There were other guys who were doing something else.

When you think about game production, it’s no different: you have people doing different things. Some people might do art, some music, some code – some manage the project. Indies might be exception to this rule since they often are lone wolfs, but even indies might consider using specialized services (such as outsourced art).

In baseball it worked fine – and it also works in game production.

#7 – Hamburgers and chips – rewards – are good
Then the juiciest lesson: after matches we went to eat hamburgers and chips. Boy it was a pleasure to get some junk food after matches.

Don’t forget rewards: they play important role in game production. Rewards can be anything from hamburgers to trips to different countries. Reward yourself. Reward your team.

And for the record, it was Finnish baseball I played.

What to Do When Others Misinterpret Your Words

What should you do when a team member has not understand your task assignment? What do you do when somebody misinterprets your words? What to do when others are not doing what you meant?

The first reaction might be focusing on telling others what they would need to do. Some people might end up blaming others for not doing the job as it should have done.

Don’t do that.

If somebody misinterprets your words then it’s your job to articulate yourself better
The policy “If you are saying something, and others don’t get the message – then it must be on the receiving end” is a bad one. The first thing you might want to check is to make absolutely certain where the problem lies. Not for the reason to blame, but for the reason to solve the problem. As they say: unless you first locate the problem, you cannot fix it. Your team members might give you hints that will help you locate the problem. They might tell what you should have done, and you can use these clues to spot the problem.

If your focus on thinking what others should have done better, then you might be missing some obvious mistakes you are doing. Even if I first think that the other should have done a better job, I can think about my own behavior and see if there’s some improvements in my approach. Often I can spot some obvious flaws in my approach and can make the necessary adjustments.

Some practical examples:

  • If your sound artist is not doing the kind of music you want, then you can tell him what kind of music you want. You can also ask him to help you to help him. Ask him to tell you what he needs you to do, and then do that.
  • If your animator is not doing the kind of work you expect, then give samples to animations what you want to see. Heck, show examples using your own body. Wave your arms and jump if necessary. Again you can ask your artist to help you with it.
  • If the level designer cannot follow your plan, then you might want to check out your plan together and ask for specific details what’s wrong with it.
  • If the marketing department doesn’t get the idea on what’s the big idea, then go on and show examples on how other studios have marketed their product and describe and show how your product is different.

Do this
If you blame the other (or worse – don’t even say that aloud) you are kind of stuck. If others misinterpret your words as a leader, then it’s your job to take any necessary actions to make sure the message reaches the other end. Improve your own approach, involve the other party and ask specific questions regarding what’s not clear. Don’t focus on finding out whose fault it is. Make it a situation where both parties are focusing on finding the solution.

3 Mistakes to Avoid When Arranging Meetings

Don’t arrange a team meeting, when in reality you need to speak with one guy
Please don’t do this. If you have something to say that only one guy in the team needs to know, say that thing after the meeting or in some day. Programmers don’t really need to know how the UV map should be done, and modelers don’t really care to hear if that memory leak was fixed or not. Make sure you speak to the whole group when you arrange group meetings. Otherwise you might be wasting time, and basically boring your team.

Don’t make your team members travel if not necessary – use phone if possible
It’s horrible to see stories where workers were invited to a meeting where they had to travel 2 hours trip by train – just to realize that everything could have been said on the phone. Save traveling expenses. Save nerves. Consider having a phone meeting if you don’t really need to have a face-to-face meeting.

The argument “I like to have face-to-face meetings” is no excuse for telling things on the phone. It’s not what you like – it’s matter of productivity and what everybody likes. And not everybody likes to waste time on traveling when it’s not needed.

Don’t get people to read papers in the meeting – send those papers before the meeting
Don’t spend time on reading papers in the meeting… Getting everybody together can be sometimes really tricky and if you waste most of the time for reading papers then something is wrong. Reading can be done alone. Being together in a meeting must be used for talking about common issues, not on reading papers or documents that should have been read before.

The Words That No Producer Wants To Hear

The phrase “You should have told me that 4 days ago.” is something you don’t want to hear so often.

After being on a trip (without checking emails or team discussion) I had a brief conversation with our artist. He had been working on the assassin texture while I was gone, and I pointed out some parts that I’d like to see different. He had been doing the textures for several days already, so naturally the my news were bad for him – and he mentioned that “You should have told me that 4 days ago.”

It was a crappy situation. I had been away for the days when he was doing the texture, so I couldn’t give comments on the work when it was being done. In retrospect, I think we should have had a more detailed plan regarding the colors before any texturing is done. I think this same lesson goes with many daily issues in game production when you have a team.

You simply need to make sure that people know what you expect them to do. They are not mind readers (as I keep telling myself over and over ;). Even though team members might have good idea and vision, you might miss explaining them some crucial points. Most of the time the problem is not in the receiving end – it’s your job to make sure the message gets transmitted. It’s your job to speak language that others understand. Use examples, images, describe, talk – use any means to make sure the message is received in the right way.

In this case I liked the 3D mesh very much, and thought that the colors in the concept would be used in the mesh. I had also said to have “artistic freedom”, and naturally this principle was applied. The overall result was good – but I had some concerns regarding the colors. The lesson learned: I should have talked about the colors in greater detail before any texturing is done.

Same goes with almost any parts of the production: naming conventions, animations, user interface, sounds – everything. While it’s not good to plan over and over, you gotta make enough planning to ensure your team understands where you aim at.

We had a long discussion and decided that in the future we would try to clarify questions beforehand. We decided to stick with the original texture. It would work in this project, and that’s it. Other people liked it, and it’s good quality – even though I had originally thought bit different coloring. We have lots of other work to do, so polishing one texture over and over would not be the best option at this time.

Military Leadership

Last weekend I saw two military officials discussing in a television show. They were asked what kind of leader they respect? What kind of qualities a good leader must possess?

Both responded: “They kind of leader who treats you as an individual and really listens to you.”

I bet you can see how efficient this piece of advice can be. It’s priceless for video game producers or leaders when dealing with others. It’s priceless for anyone dealing in customer service or in sales. The military officials continued by saying how motivating it is to work and carry out commands for someone who is listening to them.

Don’t you agree with this? Isn’t it true that those it’s easier to respect those who treat you with respect? Wouldn’t you agree that whenever you have been purchasing something and got somebody to deal with you personally, it has been easier for you to make the buying decision. You can do the same to others: you can motivate others to do what you want, by treating them as they want. Whether it’s leading the team or dealing with a customer, you can consider really listening to others and concentrating on solving their problem.

Could you use this style in your own work?

Why Emails Titled “It’s very important that everybody in the team reads this” Won’t Be Read

This article gives you tips on how to get your team members to read your important messages. Every game producer faces a situation where he needs other team members to read some documents. Some leaders try sending emails using subject line: “It’s very important that everybody reads this note” (or sometimes with subject line “URGENT! READ THIS”) – yet those emails are not read or acted upon.

Here are 3 reasons why people either read your messages or not:

  • First of all, people need to know why your message is important. Your job is to explain why somebody should read your email. If you just type “urgent” or “important” chances are that people just skip the email thinking “somebody will explain it to me if it’s that important”. But, if you simply tell people with couple of lines why the email is important, you have much bigger chances to get people to read your notes.
  • Second reason: Boy who cried wolf won’t be noted for very long. If every other email you send is tagged “important” or “urgent” then either something is terribly wrong in the project and you guys need to have a serious meeting, or you are simply tagging notes important too often. Instead of trying to keep everybody informed about everything, you might consider thinking if there are some things your team members doesn’t necessarily need to read (unless they voluntary want them). Think twice before making everything important.
  • Third reason: some people might not be sure if they need to read your email. “Everybody” is such a wide term that sometimes team members might not know if “everybody” really means them in this specific situations – especially if you’ve used “important for everybody” in the past without really having important information for everybody. If stakeholders have had a meeting and then you announce that “everybody needs to read their notes” it might not be clear to user interface artist or game play tester to know if they are really included. It might be useful to somehow indicate each individual who needs to read the note.

As in any situation when dealing with people: first think from their point-of-view. Make sure you are writing important notes and only bother those people who really need to read your notes.

Edoiki Design Improvements and Developer Role Talk

Edoiki gameplay benefited from the presentation

Yesterday I presented Edoiki in a Finnish game design event and while my presentation was simply a white board with green and red dots I got some great feedback and ideas. In the first game mode – without revealing too much – there is going to be an assassin which will try to eliminate civilians.

A very simple idea that I got from Eero Tuovinen (a real mastermind when it comes to game design) was this: “How about giving different targets for the assassin, not just civilians but buildings?” He suggested that assassin could bomb a building and when he the assassin is setting a bomb he becomes visible (normally assassin is invisible to guards). This was a very simple idea (like good ideas always are, right?) but it adds great variety and another strategical dimension in the game. I’m sure that will be added in the gameplay in some way.

I have a list of about 20 new ideas with me and can’t wait to start implementing those.

Funny how people think they are special

Since the event was focused about game design it was natural to hear designers’ point-of-views and arguments. I heard arguments stating how “core gameplay and a good design is probably the thing that makes a game fun”.

I’ve heard different points from somewhere else, and I couldn’t help thinking an imaginary conversation between different game developers. If a game designer, programmer, artist, marketing specialist and a game producer would sit around a table, the conversation might go something like this:

  • “If the core game mechanism isn’t designed well, no matter how nice graphics you have it simply won’t work”, the designer starts.
  • Programmer would interfere by saying: “everybody can get ideas, but somebody must actually take action and code those features to make sure the game ever sees daylight”.
  • Graphics and sound artist would continue: “okay, you’ve got some boxes moving on the screen but without great voice acting, music and sounds it’s not possible to reach a great level of immersion – game needs to be visually stunning to work. Without artists you cannot reach that level.”.
  • Marketers adds “okay, you might have the greatest game play, the greatest code and the greatest visuals but if you lack marketing – who will buy your product? Marketing is the most important part to make the game sell“.
  • Game producer or team leader would add: “Okay, you got all the different pieces – but who is going to make all the parts work together and make sure the project is actually finished before the next ice age? Without a great leader, a project won’t succeed”

Who is right?

I believe everybody is right. Producing a video game is teamwork. I think the designer is right about stating that the gameplay and mechanism must be designed properly. Every game production team will benefit from having a designer in the team or at least reading about game design.

The programmer is also right. If project is just about having nice ideas it won’t get very far. Programmer is definitely a key person in the team.

What about artists then? Some people might say that they aren’t needed (and all 3D games should be done in 2D) but I believe there is no reason why game couldn’t look good. And nowadays art and visuals can actually play a big role in games: shadows and lights are good examples about the artistic elements that can be used in gameplay and to add depth in the game. I think artist is right here as well.

And so is the marketer. He is right: if your game is not promoted in any way, and nobody knows about it – then it won’t sell. It might be a fine game, but it won’t be a very successful product if it lacks marketing.

Are game producers needed? Well, yes. Somebody must take the lead and manage the project and lead the people. Producer is also right. Sometimes there must be somebody who says what happens next and makes sure the project is finished.

Naturally in indie (and other) projects one man can have several roles: artist, designer, marketer, programmer and producer hat might be worn depending on the situation. Whenever you need more than one person in a project, it will change. There aren’t (always) no right or wrong answers, and there doesn’t need to be. It doesn’t really matter whether the designer is right or the programmer is right, what matters is that the project is done and finished.

I believe everybody is right.

3 Practical Tips For Better Leadership

Be fair. I believe every game producer and team leader out there should be fair towards every team member. This means that everybody is treated the same way. If you let some people behave the way the want, you need to give this privilege to everybody in the team. If one guy can be late from meetings, then everybody can be late from meetings. If nobody is allowed to be late – that means nobody. If you require lots of work from team members, be sure that you don’t require more than you are willing to do. Being fair includes you and everybody else.

Show leadership using stick and carrot. Even though I really haven’t met one, I’ve heard that there are bosses that are concentrating on the stick part, and forgetting carrot: they only “punish” and never reward. Then there might be leaders who use only carrot – rewards – and never use any ways to punish people. They say that “stick is demotivating” or say that “using carrot is the best way to act”.

While I agree that rewards are the things that motivate, but that doesn’t mean there wouldn’t be consequences for critical parts in the project. For example, if some team member constantly mocks everybody else and disagrees with everything (just for sake of disagreeing) I would seriously consider dropping that team member out. Naturally every situation must be acted fairly, take into account what’s important and what damage this team member does and discuss things openly with him before taking any action – but leaving somebody out is sometimes the right thing to do.

Other forms of “punishment” could be that “those who are late from meetings buy donuts to whole team”. If some guy has been late several times, you might be surprised how miracleously there’s no more reasons like “traffic jams”, “alarm clock didn’t work” or “had to take children to school” – even the “laziest” guys get to meetings on time when they know they will get consequences. And it’s extremely important to be consistent with this: if you put the late-donut-policy in action, you must be 100% sure that this policy is followed – it’s your job to make that happen, every time.

Say what you think, honestly and intelligently. It’s good to express your thoughts and say what you really think. Some people go into extent that they bash anything that comes to their mouth and validate their actions by saying “it’s good to say honestly what you think”. I agree that it’s good to say honestly what you think, but there’s no reason to bash others. If somebody has done a poor job, it’s right – and producer’s responsibility – to say that. The way you say it is what matters. If you say “You did a shitty job, fix it” it has a quite different attitude that expressing “Your work has always been great quality, but this time I think this work could need some improvement. Overall the job is well done, but requires some improvement here and here – what do you think?”. I don’t mean that you should say “you’ve always done great job” if the guy really isn’t. There’s no need to lie about the work, but if the guy’s work has good parts you can mention that you like about those, and then you can express what needs improvement.

Being fair, use of rewards and consequences and communicating well are tools that can help you leading your team.