Please login or join to subscribe to this thread
If there are NO standards of any type for project management, then the only consideration should be meeting your manageability/control requirements for the context and complexity of the project.
There is no "bare minimum" list which universally applies but things like a charter, a RAID log, a budget, a schedule/task list would likely be close to that...
Although there is not a general consensus of what a PA does vs. a PM, in general I would say that decision is the responsibility of your manager ow whoever you are reporting the details of your project to.
Administration is really the action of carrying out plans rather than developing them. Where a PM might create instructions for teams to develop their WBS, and administrator would collect and compile them. The PM defines the KPIs and the baseline schedule; the admin collects the data and manages the charts. The PA schedules the meetings, runs the conference calls, and records attendance; the PM plans the content, leads the conversation, and summarizes the decisions.
That doesn't mean your own naming conventions won't have PAs doing planning work like deciding how much documentation is appropriate, or PMs performing mostly admin work like running meetings for someone else. What you need is role clarity because the question you are asking is often answered by senior PMs establishing acceptable standards.
Vipul: It will depend on your stakeholders: the managers, and users of the information. I suggest a notorious change without overwhelming them. Find out what information is useful for them, and keep in mind that no standard will tell what they want and need. That is why standards say you need to tailor your practice.
Documents that helped to maintain governance on: 1-budget was agreed and project was accepted which includes why/what/when/who/how much it cost in terms of project scope. 3-product/service/result requirements and design. 4-product/service/result acceptance. 5-implementation organizational readiness. Something which is cross to all these is risk and issues management process support.
Thanks, everyone. This was very helpful.
It will be best to consider the stakeholders' needs and then move ahead after thinking about the risks involved due to lack of documentation.
The only deliverable that is 'very important' is the project product - what you set out to achieve. Work backwards from there. What is defined as project success? What is required to achieve project success? This applies to documentation as well as the other project elements. Who needs to know what and when to keep things moving effectively? Make sure the stakeholders have what they need to proceed without disruption. In terms of final documentation you have to show that project success was achieved - all success criteria met and where not met, the reasons.
I also wanted to know if the free templates available here can be used for our own projects as per our needs or do we need to fill up the request permission form for author's permission?
Please login or join to reply