There are reams of books written about the difficulty of managing software projects. The Mythical Man Month being one of the more famous ones, IIRC, written all the way back in 1975. This is not a new problem, nor is it one that has been solved. From the mentioned book came Brooks’s law - “Adding manpower to a late software project makes it later”.
Gaming software has all of the problems inherent in any software management situation, plus a lot of pressure (fanboys, deadlines) and likely entire levels of management that have no training or experience in software project management.
And this is exactly why unionization, which keeps Hollywood from being so exploitative, will never happen in the games industry. “Oh, you want to start a union? Well, there’s this other guy who is almost as good as you, but he doesn’t want to rock the boat.”
Oh, we’re all very aware, I assure you. Even management knows. But to compete with all the other companies, corners have to be cut… and, sadly, it’s cheaper to burn out workers than to spend money on them.
True this. I’ve been in the games industry for almost 18 years. I’ve worked on 10 games in that time. On those games, I’ve used six different effects tools. Whenever I take a new job, most of my first year is spent in learning whatever new software package I’ll be using. The concepts transfer, but each program has their own, unique interface and procedures.
Years ago, I was art director for a small garage game company. We had an existing MMO, one that we’d developed on our own. We ran out of money, and eventually got bought by a fairly large publisher. The publisher wanted us to make some changes to the game, and part of my task was to schedule out the changes such that they’d be done in three months.
I managed to do so (even though we weren’t really being given any additional support). I sent in the revised schedule to my lead at the publisher, and his (emailed) response was, “Well, this looks good, but I’m a bit concerned that you didn’t schedule any overtime.”
We didn’t need the overtime to get the job done, but it’s so endemic to the industry that it’s expected.
My response to him was, “If management has to schedule overtime to get a job done, they’ve already failed.”
As far as unions go, Games are possibly the worst industry for them ever.
Hollywood in practice tends to have more guilds than unions, although the line can be a hazy one. The jobs and tools are often reasonably standardized and the skills to use them right are not quickly acquired. Thus, big production companies know they can get some halfway-decent quality and ensure long-term supply. While individuals may turn over and obviously go from job to job, reputation does count and the hiring organizations (bigger and smaller studios) are usually reasonably long-lived.
Software is not like this. A handful of big publishers like EA manage to survive over the years, but many studios won’t make age 10. Even the in-house studios owned by the major publishers routinely close down, their employees scattered to the four winds. Employees have no loyalty, skillsets and tools are constantly changing, and new startups form so often that shocked biologists are sputtering “Spontaneous Generation!” The employees themselves are not always highly paid, but they are highly individualized white-collar thinkers, who always have a Bachelor’s and frequently some graduate education. Nobody expects to work for a given company for too long, unless they’ve fallen into a sweet gig as a Blizzard dev or something.
In that kind of environment, unions are almost impossible, and likely wouldn’t last long or do much good. The entire industry is simply in too much flux.
I’m reminded of an article by one of the people behind Sins of a Solar Empire, commenting that one of the common problems that ruins a developer is that they not only chase after the big hits, but budget and design the game as if it’s going to be a big hit. They’ll spend like they are making the next best seller, and then end up taking a loss when the game merely sells well instead of fantastically.
Commenting on this: look at the difference between Dark Souls and Tomb Raider (2013). The sales for both are pretty similar and they’re considered high-quality games with a lot of replay value, but the former was a surprise hit and the later a dismal failure… at least according to their respective companies. Dark Souls was made on a relatively slender budget, but hardly a pittance, and turned out a quality product that had wide appeal. Tomb Raider sold very well indeed, but cost so much that Square Enix called it a failure; the implication is that that it would have had to sell at least five million to be a success. Which is absurd, as only the absolute best can do that, and it’s almost never predictable.
Or look at Star Wars: The Old Republic. Likely between 200-300 million dollars got sunk into this, and it’s unlikely to ever really be profitable. (We could go into the accounting of all of this, but given time value of money and the fact that it simply did not live up to EA’s ludicrous expectations and had to go F2P in record time, the initial costs are probably sunk to hell and back.) And to anybody outside the bubble that was basically “No Duh, Sherlock” time. It’s an interesting game and not terrible, but a mediocre bland WoW clone with a cool story mode wasn’t going to burn up the sales charts. Meanwhile, that much money would have funded 5-10 quality games with solid sales.
One of the main differences between computer science and other engineering disciplines is that software operates on a much shorter timeframe and is in a much greater state of flux. A car manufacturer doesn’t have to worry about the car fundamentally changing every few years. They can make constant iterative changes to their production models and manufacturing processes and pass on the lessons learned.
In software, you will typically assemble a team from assorted consultants, contractors, freelancers, subject matter experts, vendor firms, outsourcing agencies, even the project managers for a specific project. It might be the release of a new game, a software startup venture, some Accenture led enterprise system implementation or whatever. They will work for the duration of the project and then disperse. Even the lessons learned are largely irrelevant unless you plan to use the same technology on a similar project for a similar company in the same industry using the same project management methodology. And by then the technology might have changed anyway. There’s no cohesion or longevity with anything.
Another thing, speaking as someone who majored in civil engineering as an undergrad, the other engineering students are no where near as weird as many of the computer science students. A lot of programmers have this rebel hacker Occupy Wall Street screw Big Business and The Man with my disruptive tech which will make me a billionaire by 30 mentality. And a lot of companies play into this by creating cult-like environments that make their people feel “special” and “passionate” so long as they work 100 hours a week.
For example, I worked as a project/program manager at a tech startup founded by a bunch of ex-McKinsey consultants and some weirdo tech genius who looked like a homeless Zack Galifranakis. People there used to say how brilliant and creative everyone was, but it didn’t reconcile with their actual results. Much of the code that was developed lacked any sort of standards, documentation or quality control (what is often called “cowboy code”). Many of the groups my teams needed for support often missed deadlines or the quality was for shit. At one point I’m writing code myself because the VP of the group never staffed up our office to backfill people who transferred out or left the company entirely. The facilities were a half-finished, roach-infested Silicon Alley, open-plan loft. Management used to…not yell. Real men yell..more like bitch like petulant over-privileged nerds who know that societal convention is the only thing keeping them from getting punched in the face. Analysts and developers would just be tossed into projects with no support and expect to work until 2am for weeks at a time. I feel like on many occasions I had to tell my manager “we are a startup” doesn’t fly as an excuse for why the phones don’t work in a 6 year old company with 100 employees.
And yet people used to say they “loved” working there and felt passionate about the company. One thing these tech companies are good at IMHO is creating this cult-like Stockholm syndrome abused housewife mentality where they can treat their employees like shit by hiring overachievers and challenging them to a shit-eating contest.
Part of the problem is that the managers (including senior executives) are often people who are good at what the company does but not good at managing. Thus law firms are run by people who got to where they are by being good at law but who aren’t trained at managing. Magazines are run by people who are great writers or designers, but not great managers. Restaurants and chefs, the same way, etc.
Based on my experience, it’s the sorry fucks in marketing and sales that give everyone ulcers, heartburn and gray hair.
They make deadlines without regard to anything other than their own stuff, they promise and sell features that don’t even exist, and at every chance and turn, they’ll throw the technical staff/operations staff under the bus for not meeting the deadline.
It’s like if JFK had said that he wanted to put a man on the moon by 1963, not the end of the decade, and then blamed NASA when they couldn’t pull that off.
That’s not entirely true. People who reach that level can’t be a complete dunce when it comes to managing people.
Plus, there is a difference between being a functional manager and being a project manager. Functional managers tend to worry about long term things like staffing levels, performance reviews, P&L and general direction of the group. Project managers have the unfortunate task of taking a bunch of people and getting them to deliver a specific project by a specific deadline.
There’s a difference between “not a complete dunce” and “actually good at the job”; I speak from experience. In the past, a company I used to work for had a VP level executive who had been promoted out of engineering. Turned out he was a great engineer, a pretty good leader of small teams, and an absolutely awful department head, because you just can’t do things the same way with 90 people that you can with 9. Sometimes, people just get promoted because they are good at what they do, rather than good at what they are going to be doing.
It’s called the Peter Principle. A person will keep getting promoted until the eventually get to a position they suck at, where they remain and continue to suck.
Recently, a developer from Obsidian mentioned that with the success of their Kickstarter campaigns publishers are suddenly believing in these lower-budget, lower-risk niche markets.
I’ll believe it when a publisher actually announces a project aimed at one of these “niche markets” without Kickstarting it first. (And no, companies that have been releasing for niche markets all along continuing to do so does not count.)
I find it hilarious, too. A mill could support four such projects easily, with a high return individually as they don’t have to sell much. I think part of the problem is that the big publishers are and have been glued to the consoles, which have a higher bar to entry per game and narrower, less flexible distribution. You can’t sell a cheap indie game for 60$ at Gamestop; you can sell it through STEAM. You may not even be able to get Sony or Microsoft to validate your game as a tiny indie; but GoG doesn’t care.
More like the difference between being a company commander and a division commander (or higher). It’s not only tactics vs. strategy, but details vs. concept as well.
However, it’s not that the functional manager won’t be aware of the projects, but rather that he’s running several project managers at once on several projects.
I still think the biggest corporate management/leadership failure is the lack of realization that ultimately management is about managing people and not so much about managing projects.
If these knuckleheads would manage their people properly, the projects would tend to fall into line, assuming their people are reasonably competent.
But harping on deadlines, deliverables and milestones without keeping tabs on your employees’ workloads, competing priorities, and often, interference from other managers, is inviting disaster on your own projects, and inviting turnover from your employees.
Often, functional managers don’t think in terms of projects 99% of the time - the projects managed by a factory’s production manager or quality manager are either tiny but many (production orders and their inspections, continuing with the example) or very large (such as “introduction of a new product which comes directly from RnD so at first it will be crap”). On the other hand, someone who’s always worked on a project basis can have serious problems comprehending “but I don’t manage any projects, we make a single product the whole time!”
(And no, companies that have been releasing for niche markets all along continuing to do so does not count.)