Home › Forums › Program and Project Management › Calling all Project Managers - I need your Pro Tips! › Reply To: Calling all Project Managers - I need your Pro Tips!
One of my pet peeves about project management classes that I was forced to endure over the years was a desire on the part of the course to "live or die by the documented process". Of course more projects end up dying due to the process than actually live by it. What I mean is this -- every project should be considered unique. The documents and processes needed to make a project successful should be scrutinized for each project. The goal is ALWAYS to complete the task and it is never to complete the documentation. Is documentation important? Absolutely! However, the documentation is the tool and not the project.
That being said, I believe the key document to ANY project is a project charter. The charter must describe what is the team's goal and what success looks like. If you can't describe success, you have absolutely no chance of getting there. Besides a good description of success, a charter could also define the project's relative importance ("this is top priority" is only true of one project in an organization) and key stakeholders.
Writing a good charter is more of a function of what is known or not known about the key stakeholders' desires. If the project is starting on a vague footing (more common than anyone would be willing to admit), then it will be crucial to find a way to take the vague instructions and make it more concrete. I usually find that interviewing both the stakeholders and the eventual end users is a great place to start. For example, I was hired on for one project that would deliver a scheduling system for the pilots in an airline. The key stakeholders were the CIO, VP of operations, VP of labor relations and the pilot union board of directors. At that level, they all knew what they wanted the thing to do, but none of them had enough experience with the potential technology to know what was possible or even practical. I therefore interviewed many random pilots, the personnel in the crew scheduling office and vendors to get a sense of what everyone's expectations were. From all of that, I was able to put together a charter (and an initial outline of the project tasks). Ultimately I learned far more than I ever needed to make the project successful, but "starting" a project that has more than it needs is far easier than trying to play catch up or get stakeholders to compromise after the start of the project.