[font=comic sans ms,cursive]Hi everyone i hope you enjoy reading![/font]

[font=comic sans ms,cursive]

The game industry requires innovations, as publishers cannot profit from constant release of repetitive sequels and imitations. Every year new independent development companies open and some manage to develop hit titles. Similarly, many developers close down because they cannot find a publishing contract or their production is not profitable. It is difficult to start a new company due to high initial investment required.[/quote] [/font]


[font=comic sans ms,cursive]

What is a producer?[/font]

[font=comic sans ms,cursive] Technically speaking a producer is a person, company or country that produces supplies/grows goods etc.[/font]
[font=comic sans ms,cursive]In this case we're talking about a video game producer which means that the definiton of the title 'producer' would shift slightly. Simply put: a video game producer is a person in charge of overseeing development of a video game. Now, this can fall into a few categories such as executive producer for example.[/font]
[font=comic sans ms,cursive]“The producer’s job,” explains Universal Interactive Executive Producer Pete Wanat, “is to shepherd a product from the conceptual stage until the game code ships to the manufacturer (or is uploaded digitally).[/font]


[font=comic sans ms,cursive]

How do I become a producer?[/font]

[font=comic sans ms,cursive]There are many ways in order for someone to become a game producer, first of all you need to take steps to achieve this goal, by this i mean that not everyone becomes a game produces even with decent qualifications due to the fact that they need to have experience in this subject matter(production-related experience) combined with a high-level of understanding of how video game development works.
This is why people start off as a former programmer/artist for example, then you wait for promotion and learn from your former leaders/bosses or the department your working in.
So you could probably start off looking for some video gaming courses/schools, or if you have prior experience you can search for jobs.[/font]

What's the best project management software?

[font=comic sans ms,cursive]There are a variety of softwares that fit into this category which is mainly/usually decided by the company you are working for.
Recommended: http://www.gtdagenda.com/
http://www.rationalplan.com/[/font]
[font=comic sans ms,cursive]On top of this you'll find many more,also to add to this you can find professional softwares that will satisfy your needs greatly for reasonable prices if you do some research.[/font]
[font=comic sans ms,cursive]What's the best production method for my project?[/font]
[font=comic sans ms,cursive]if you have money you can buy this software: http://www.preactor.com/Landing-Pages/Production-Planning.aspx?lang=en-GB&gclid=CPaHutm_wrICFcENfAody3AAmg[/font]
[font=comic sans ms,cursive]If not then you'll have to do it the usual way The one that i have experience with is the software develpment life-cycle/process. This process expands and opens up lots of doors,the one that i approve of is the Waterfall Model which im familiar with since this was the model Java developers have used. I cannot go deep into how this model works since that would fit much better in another article dealing primarily with software development models.[/font]


[font=courier new,courier,monospace]More info on software development processes:[/font]
[font=comic sans ms,cursive]To name a few:
1. the waterfall model
2. Rapid prototyping methodology [/font]
[font=comic sans ms,cursive]3. The Spiral model( which combines some key aspects of the waterfall model and rapid prototyping methodologies.)[/font]

[font=georgia, serif]How do I find developers?[/font]

[font="comic sans ms, cursive"]developers? programmers? easy!(this is the case if you have enough money to pay them) You have to pay them unless they're voluntary workers which i will doubt, if that's not the case on this website there are 25 places where you can find a freelance worker for hire. It is, as you might have noticed, very easy to find a developer but the only problem might be money.[/font]
[font="comic sans ms, cursive"]Link: http://pragmaticoutsourcing.com/resources/25-best-places-to-find-a-freelancer/[/font]

[font=comic sans ms,cursive]You can also find many more websites by googling it.[/font]

[font=tahoma, geneva, sans-serif]Got the job, now what?[/font]

[font=comic sans ms,cursive]Now you need to sit back carefully and think.[/font]
[font=comic sans ms,cursive]In general you'll have the following responsibilities 8 responsibilities since they might vary according to the company you are working for:[/font]
[font=comic sans ms,cursive]1. Negotiating contracts, including licensing deals.[/font]
[font=comic sans ms,cursive]2. Acting as a liaison between the development staff and the upper stockholders (publisher or executive staff)[/font]
[font=comic sans ms,cursive]3. Developing and maintaining schedules and budgets.[/font]
[font=comic sans ms,cursive]4. Overseeing creative (art and design) and technical development (game programming) of the game.[/font]
[font=comic sans ms,cursive]5.Ensuring timely delivery of deliverables (such as Milestones)[/font]
[font=comic sans ms,cursive]6.Scheduling timely quality assurance (testing)[/font]
[font=comic sans ms,cursive]7.Arranging for beta testing and focus groups, if applicable.[/font]
[font=comic sans ms,cursive]8.Arranging for localization.[/font]

[font=comic sans ms,cursive]

[font=arial, helvetica, sans-serif]How do I estimate time[/font]

?[/font]
[font=comic sans ms,cursive]You might think: why do i need this? Think about it, imagine it took Fifa13 2 and a half years to come out! That would be a disaster, thats why you need estimate time carefully and this also reflects whether your project has succeeded or not depending on whether it was delivered on time and on budget[/font]
[font=comic sans ms,cursive]Key things to keep in mind when estimating times are:[/font]
[font=comic sans ms,cursive]1. understand what needs to be done, analyse the project.[/font]
[font=comic sans ms,cursive]2. identify the order of activities(order in which they need to happen), not how long they are going to take.[/font]
[font=comic sans ms,cursive]3. make estimates:
-time needed to complete a 'single' task.
-List assumptions, exclusions and relevant info.
+ Method for estimating: i wont go into all the methods but rather just explain one of them: Bottom-up estimating
- estimates the project as a whole
- break larger tasks into smaller ones(then estimate time that is going to be needed to complete each individual task)
- add up total amount of time.[/font]
[font=comic sans ms,cursive]This would make much more sense if you understood the software development processes.[/font]

How do I estimate cost?
[font=comic sans ms,cursive]The constructive cost model (COCOMO) uses a basic regression formula with parameters that are derived from the project data and characteristics. (NOTE: this method is only used for demonstration purposes)[/font]
[font=comic sans ms,cursive]Basic COCOMO computes software development effort (and cost) as a function of program size(lines of source code).[/font]
[font=comic sans ms,cursive]The basic COCOMO equations take the form
Effort Applied (E) = ab(KLOC)bb [ man-months ]
Development Time (D) = cb(Effort Applied)db [months]
People required (P) = Effort Applied / Development Time [count][/font]
[font=comic sans ms,cursive]where KLOC is the estimated number of delivered lines (expressed in thousands ) of code for project.[/font]

[font=comic sans ms,cursive]

[font=verdana, geneva, sans-serif]Oh crap, the project is in trouble!
How do I move up the ranks?[/font][/font]
[font=comic sans ms,cursive]Quit the project
Blame the team members and strategy
is that what you thought? even though thats not what you might think this is very common.[/font]
[font=comic sans ms,cursive]1. Review the project plan
2. Devise recovery plan[/font]




IF anyone wants an article dealing with software development processes let me know

thanks for reading!

Reading through your post I can only come with one conclusion: You are not a game producer.
You're tossing tidbits of knowledge here and there that are either out of context, imprecise or stricly wrong.

What is a producer?

Technically speaking a producer is a person, company or country that produces supplies/grows goods etc.
In this case we're talking about a video game producer which means that the definiton of the title 'producer' would shift slightly. Simply put: a video game producer is a person in charge of overseeing development of a video game. Now, this can fall into a few categories such as executive producer for example.
“The producer’s job,” explains Universal Interactive Executive Producer Pete Wanat, “is to shepherd a product from the conceptual stage until the game code ships to the manufacturer (or is uploaded digitally).

That is so vague that I almost forgot what my job was after reading this. What is your audience here? "Shepherding" is just about the closest word you've employed to describe the work a producer does, and I really don't consider myself a 'shepherd'...

This is why people start off as a former programmer/artist for example, then you wait for promotion and learn from your former leaders/bosses or the department your working in.
So you could probably start off looking for some video gaming courses/schools, or if you have prior experience you can search for jobs.

If you "wait" for promotion, its just not going to happen. Becoming a producer requires awareness and ambition. You have to be ready to take the fall for the whole team, not just for yourself, and you have to be able to stop pointing fingers when shit hits the fan. You could jump in straight into a producer position without prior game development-specific experience. A lot of the managers in this industry are freshly out of other technology-related fields (Web, hardware, etc). While I personally consider knowledge of game development to be a key aspect of my job, I can see how a senior manager with no prior knowledge would quick get the hang of it.

There are a variety of softwares that fit into this category which is mainly/usually decided by the company you are working for.
Recommended: http://www.gtdagenda.com/
http://www.rationalplan.com/

That sounds like you're just selling out here. With no prior knowledge as to these two, I'd state the obvious MS Project for waterfall projects, and anything like Jira/Hansoft and the likes. Also, you mysteriously don't mention project steering software which is just as (if not more) important than planning.

This process expands and opens up lots of doors,the one that i approve of is the Waterfall Model which im familiar with since this was the model Java developers have used. I cannot go deep into how this model works since that would fit much better in another article dealing primarily with software development models.

Waterfall, as nearly all professionnals from the industry would tell you, is clearly insufficient for the game dev scene. There are a numbers of methods, some of which are agile, but generally an hybrid between Scrum and Waterfall, which are currently employed in the industry. Planning a project in waterfall is prone to disastrous results.

Got the job, now what?
Now you need to sit back carefully and think.
In general you'll have the following responsibilities 8 responsibilities since they might vary according to the company you are working for:
1. Negotiating contracts, including licensing deals.
2. Acting as a liaison between the development staff and the upper stockholders (publisher or executive staff)
3. Developing and maintaining schedules and budgets.
4. Overseeing creative (art and design) and technical development (game programming) of the game.
5.Ensuring timely delivery of deliverables (such as Milestones)
6.Scheduling timely quality assurance (testing)
7.Arranging for beta testing and focus groups, if applicable.
8.Arranging for localization.

The term producer is much wider than you seem to be describing. I can see producers whose job do not include either of these.
Also, in many offices, contract negotiations are handled by a legal department or something similar, and creative control is held by larger leads, directors or VPs. A lot of focus groups occur only if you work at a publisher and a lot of projects won't go through localization.

How do I estimate time?
You might think: why do i need this? Think about it, imagine it took Fifa13 2 and a half years to come out! That would be a disaster, thats why you need estimate time carefully and this also reflects whether your project has succeeded or not depending on whether it was delivered on time and on budget
Key things to keep in mind when estimating times are:
1. understand what needs to be done, analyse the project.
2. identify the order of activities(order in which they need to happen), not how long they are going to take.
3. make estimates:
-time needed to complete a 'single' task.
-List assumptions, exclusions and relevant info.
+ Method for estimating: i wont go into all the methods but rather just explain one of them: Bottom-up estimating
- estimates the project as a whole
- break larger tasks into smaller ones(then estimate time that is going to be needed to complete each individual task)
- add up total amount of time.
This would make much more sense if you understood the software development processes.

You make it sound like the producer is the one making the evaluations. Sure, you could, but unless you're a proven artist, kickass programmer and the likes and have kept up to speed on the technologies employed where you stand (and know the capabilities of your team members) your estimate will be a lie, leading to failure. A big part of being a producer is knowing how to surround yourself with clever individuals and trusting their judgment. And this is something a lot of producers still struggle with.
Your real job in during evaluations is to ensure that the documentation provided by the designer or project owner is clear. You want everyone in the room to be exactly on the same page about the definition of each item/feature. You also need everyone to understand their share of that job (little aparte here about backend and frontend engineers disagreeing on who should handle a part of the logic, and both of them underevaluating because they expect the other to handle that part).
Your best tool here is reformulation. This helps you narrow things down for everyone and generally gets a few 'oh, that's not what I thought he meant'

In terms of project breakdown, you need to speak with creative members and tech members alike to find a breakdown structure that can be understood by both. For example, you could break everything down by each UI screen you have, but that may actually be counter-intuitive for your programmers. Likewise, you may breakdown everything by modules from the tech perspective, but your artists and designers will be confused about the terminology. Find something that works for everyone and stick to it. Terminology is critical, and everything needs to be properly defined so you avoid problems down the road.

Defining the order of things is always temporary. Your system needs to account for the fact that priorities will change, items will be removed and added. If your system causes frustration to team members when this happens, you are failing. One method is the inclusion of a backlog and a breakdown sprint by sprint (choosing items from the backlog right before starting the sprint, ensuring that the next sprint always reflects the topmost priorities at any given point in time (aside during the sprint)).

As far as task breakdown is concerned, you don't need to break it all down to the smallest detail. That would make you a control freak, and a lot of developers are a lot more efficient if they feel they have some kind of control over what they're doing. Breaking tasks down to tasks about a day long, or 4 hours long makes sense. It will be up to them to manage their time efficiently for that give day or half-day, but any decent team member can easily do that, and they'll thank you the morning after when you're asking them if Item X was done rather than items a,b,c,d,e,f,g (which are tasks broken down from X).

Regarding sums: don't just make the sum of tasks and say 'this is going to take X amount of time'.
You're making a lot of wrong assumptions:

- That every single task can be worked on by a person while somebody else works on another task. You might be in a project where the last task is 3 days long and cannot be shared amongst more than one developer. You just can't split everything evenly; its a shortcut that will cost you down the road. Instead, plan for de-staffing plans and the likes and really define your critical path and crash it (see MS project and anything similar).

- Scalability of resources: If your project is 1000 hours and you have 1 guy, its safe to assume that one guy will bill 1000 hours. If you have 2 guys, don't expect it to go down to 500h each, and counting. At any rate, don't expect a 1000 hour project to take 1 h if you have 1000 guys. There are two main reasons for that:

First, many tasks require others to be performed before them. They have pre-requisites. If you take the worse-case scenario of tasks that are pre-requisite to one another and put them one after the other, you get the 'critical path'. This is the series of task that will determine the lenght of your project. These tasks may not be scalable (i.e. you may not shorten them by adding more people) and should be one of your main point of interest for that project.

Second, the more developers/artists/designers you have, the less efficient they will become. Not because they aren't good, but because communication takes it toll. Someone will have to keep track of who is doing what, and you will not have the qualifications/time to do it to that micro-level. You need leads, and possibly sub-leads, etc. These people won't give you 100% efficiency, so don't enforce it on them.

How do I estimate cost?
The constructive cost model (COCOMO) uses a basic regression formula with parameters that are derived from the project data and characteristics. (NOTE: this method is only used for demonstration purposes)
Basic COCOMO computes software development effort (and cost) as a function of program size(lines of source code).
The basic COCOMO equations take the form
Effort Applied (E) = ab(KLOC)bb [ man-months ]
Development Time (D) = cb(Effort Applied)db [months]
People required (P) = Effort Applied / Development Time [count]
where KLOC is the estimated number of delivered lines (expressed in thousands ) of code for project.

I don't think it applies well to the game dev industry sadly. There are a lot of unknowns you're not taking care of.
I personally employ a buffer based on historical data from previous projects. This buffer represents:
- Communication (amongst team members)
- Meetings (required to explicit and steer production)
- Support (that a given individual has to give to another for a given task. i.e. a backend developer pushing code for a frontend dev.)
- Resources shifting (people coming in and out and their learning curve)
- Prog/Art-testing
- Code review
- etc.
I also employ another form of buffer for Quality Assurance.

Oh crap, the project is in trouble!
How do I move up the ranks?
Quit the project
Blame the team members and strategy
is that what you thought? even though thats not what you might think this is very common.
1. Review the project plan
2. Devise recovery plan

Project steering doesn't appear to be your forte. "Damage control" is not something to be taken lightly either.
Reviewing the project plan and devising a recovery plan is something that requires intricate understanding of the software development process.
One of the key concepts that is crucial to grasp is the triangle. A lot of folks explaint his in a lot of different ways, but basically, a producer has control over 3 axis of a triangle.
- Scope (The actual project's content in terms of features)
- Time
- $

When one of these 3 fails, you have to identify:
- Which of these axis am I allowed to control (which axis your client/upper management might be willing to modify)

For example, a project may be going over-budget, and you are explicitly told that it needs to remain under budget. When you look at scope and time, and ask for which is more important, your client is always going to say both, but you can test their elasticity. Let's assume the client has a deadline he can't skip. Your contingency plan here might be to revise the scope, aka, cut down features.

In another scenario, you may foresee that the project is not going to launch on a given date. When asking your client which other axis you can modify, and the client lets you know that his hands are tied when it comes down to the scope and budget. Sometimes the answer is in plain sight: the project CAN ship late.

While understanding the triangle is important, it is not the only thing that a producer can do. The triangle essentially assumes no gain: I will transfer this problem into this other problem that my client is more willing to live with.
A real producer shines by his ability to be creative about problem solving strategies and to discuss these problems with his team in a way that allows them to figure ways to minimize the impacts of the said problems.

I'd probably have a lot more to say, but the structure of this post makes it impossible to tackle basic notions in the appropriate order. I'd suggest reading further on the matter of Project Management (a lot of good authors have explicited these concepts a lot better than me).

rewrite the article: thats w hat. lol///

I won't rewrite the article. For once, I don't consider myself an everflowing source of true knowledge. I'm giving you my personal experience, that's all.