I recently finished working on a fairly long-term project at Microsoft Australia. It was my first project at MS, working with a great team and by all accounts the project was a great success. We never missed a single milestone, and had very few issues when we went “into production”. Now that I’m starting on a second project at MS with a different team I’m looking back at the first one to try and analyze what we did well, and what we could improve on. Looking back I think one of the biggest reasons things went well was the way the project was managed - our project manager (or program manager in MSF-speak) worked extremely hard with the customer to define what they needed, but at the same time put a lid on “nice-to-have” features that would have required a large amount of effort and were not part of the core rationale of the product we were building. Sometimes that meant throwing cold water on flights of developer fancy that could have lead to scope creep. Sometimes that meant slogging it out on the phone for hours with the customer explaining why it was in their best interests not to build a certain feature. In addition to that they spent many hours in “negotiations” with third parties working hard to ensure our project interests were properly represented. If you’re a project manager and you’re everyone’s best friend you’re probably not doing your job properly.