Milestones and Glass Houses

Handling Rejection
Milestones and Glass Houses
Introduction
Page 1
  Page 2
  Page 3
    Page 4
     Page 5 
Conclusion

Many developers deal with milestone rejection quite professionally, seeing their job to be earning the publisher's satisfaction. With other developers, their reaction is sometimes akin to the stages that patients go through when they learn they have a fatal disease: denial, followed by anger, and eventually, acceptance. Actually, I admire developers who defend their position, especially when they make such a compelling argument, they change the publisher's assessment of the milestone. But beware of arguments of "that can't be done." When I was a programmer, that expression meant either "I don't know how to do it" or "I don't want to do it." A good producer and project manager need to know the difference between the two. In the former situation, they need to have the technical sophistication to discuss with the programmers why something can't be done.

It is damaging to all parties when milestone battles affect the morale of the development team. Too often, the team sees milestone rejection as a personal rejection, each team member becoming angry at publisher for rejecting their individual work. Usually this interpretation of a milestone rejection is erroneous, and a project leader needs to isolate the team members from milestone disputes and concentrate the team's focus on the game's progress.

Once the developer agrees that the milestone needs to be re-submitted, he should attempt to get a very clear idea of what he needs to do to gain the publisher's acceptance of the milestone - not just what problems need to be addressed, but in some cases, how they should be fixed. However, if some required fixes adversely affect the schedule or budget, then the developer should so notify the publisher.
Conclusion Next Page