There is a fundamental difference between being an employee and an employer. There are many things employees cannot do that employers can do. You just need to stop seeing TFP the development studio as an employee of some job because they are not. They are an independent entity that can make an estimated target and then choose to go past that estimate because they deem it necessary to deliver a product that is in good form rather than meet the target and deliver something poor and not have to worry about getting fired.
You are probably an employee and can only view situations from your own experience/point of view. TFP is not an employee. They are also committed to quality over meeting target estimates.
I didn't intend for this to become personal, but if you want to dangle the ham, I'll bite. I'll start by saying that this is a fairly clear ad hominem fallacy. You're stating that my input is not valid, because I am not a company like TFP, but am only an employee, which has nothing to do with the validity, or lack thereof in my remarks. However, due to your status, I respect you, and am going to take the time to offer a proper response, rather than just give you a buzzer sound like this is some sort of msn chat room.
I am an employee; however, the reference was towards what it means to set expectations and the reactions to them, not TFP's existence as a boss or employee. I'm also a project manager. It's 'my' job to set the timelines, to establish expectations, and meet them. There are certainly times when I need to adjust timelines, and I need to manage those expectations with clients. In my job, I don't report to my "boss" aside from the odd beer Friday, I report directly to clients. The boss takes the payments, and as long as the payments are coming and complaints are reasonably limited, they're happy. I operate the same way TFP would, in that you don't set internal expectations, you set expectations directly with clients/customers/consumers, whichever term you want to use. I agree, my critique has been very critical of TFP, and I'm sure it bites a bit, I'm not trying to beat around the bush. One thing about setting expectations - you have to be clear.
Delays, internal or external, should be the exception, not the rule. with TFP, it is a rule - multiple delays happen every release. This screams to me that there is a lack of proper project management. Scopes are not being clearly defined, work is not being clearly estimated, and no deliverables are being formed. Before I have my programmers or designers write a single line of code, or look at a single reference, I have created a clear deliverable for them to be working on. This outlines exactly what features, content, or functions are going to be included in the next push. This is discussed as a team, we cover each of the tasks within the deliverable, estimate the work required to implement it, and discuss interactions and potential conflicts. I then take that discussion, and form it into the deliverable scope, with a breakdown for each part, who should be working on it, when they should be working on it, and when it's expected to be completed by. Then, and only then does work start. During the project I touch base with my developers once a week to twice a week to check the state of each of the items so that progress, and any delays are clearly known and tracked at all times. There is also a large block of time provided between expected completion, and next deliverable start so that a.) I have time to work on the next schedule, and b.) developers have time to iron anything out still lingering. If I was expecting to release a deliverable in a month, then my team should simply be testing and bug fixing. There should not be anything at all new added within the last 20% of a deliverable's timeline.
As a project manager, I also fully understand "quality concern". But this is taken into account when designing the deliverables. If something isn't up to allowable quality by the set dates, that means either the scope was breached, or the work required was underestimated to the point that not even the extra allowances were enough to cover it. as I mentioned, this can certainly happen - but not within the last 20% of a cycle, as everything should either be completed, or near completion before this point. So if there is a delay, it should be a well understood delay. Multiple delays means many things have gone wrong, which typically means the deliverable was too large to properly establish and estimate. At any point during a project, I can state all cores of what the project will be once it's complete, what each deliverable (or 'part', or 'release') of it will contain, and an outline of anticipated completion times for each deliverable.
And while TFP cannot be fired, it can go bankrupt. So I don't really see how that's an easier risk than getting fired, and shouldn't be taken as seriously. An employee can get a new job, the business is gone. I certainly appreciate your disregard for random people's discussions regarding a project's progress, though actions do speak louder than words. I'm not the one repeatedly adding delays to deliverables.
I love the game, I love the content, and I currently do want to continue supporting it. I simply explained what I believe is causing the failure to meet expectations based on my professional experience and training. If proper project management were occurring, we would not be seeing the types of regular delays we are, among other things. I said earlier I didn't want to turn this into a discussion about what project management is and means, but like a feral knocking at my front door: if you're going to try to call me out on my home ground, I'm going to have to answer. TFP can run things however they want, but it doesn't mean the criticism is invalid.
