How to talk about PM in a PM document?
Mr Smart writes:
Project Plans are not academic works
Project plans are used in professional settings to get work done. There are many things that distinguish a good project plan from a poor one. In general though, effective plans will provide the information required by the reader and no more. Like good software, they should allow the user to get the job done and otherwise get out of the way.
This is quite different from an academic essay, where other criteria may apply. The purpose of an essay assignment may well be to provide a means for the student to display a repertoire of knowledge and skill, or to show off in a structured way.
Project Plans must talk about Project Management
Despite this distinction, many real project stakeholders have a sound interest in the management principles being used by a project teams. This is an integral part of quality management, whereby one investigates the relevant characteristics of any resource being used for work. Here the situation is of the customer who wants to know the characteristics of the supplier. Since the project is proposing to deliver a unique product, the customer cannot simply test an example of the product, and they must look at the product provider to gain some insight.
So, what should a project team talk about, in the area of management itself, in order to satisfy a customer? It will be insufficient to simply indicate, by quotation, that the project team has read the usual textbooks. It is likely that the customer will have read them too, and re-reading extracts from them will simply signal the naivety of the team.
The customer wants to know about their project
What the customer wants is evidence that relevant management tools will be applied to the project at hand. They will be looking for:
On the Project Plan Outline, one of the sections is 'Project Management'.
Everytime I think about how to tackle this section I start writing, Why project Management is important in our Library Refurbishment. Im sure this cannot be right as its like a way i'd answer an exam question or something from coursework 1, not a page that we'd include in an actual project plan?!
Could you explain this point a little further for us please?
Project Plans are not academic works
Project plans are used in professional settings to get work done. There are many things that distinguish a good project plan from a poor one. In general though, effective plans will provide the information required by the reader and no more. Like good software, they should allow the user to get the job done and otherwise get out of the way.
This is quite different from an academic essay, where other criteria may apply. The purpose of an essay assignment may well be to provide a means for the student to display a repertoire of knowledge and skill, or to show off in a structured way.
Project Plans must talk about Project Management
Despite this distinction, many real project stakeholders have a sound interest in the management principles being used by a project teams. This is an integral part of quality management, whereby one investigates the relevant characteristics of any resource being used for work. Here the situation is of the customer who wants to know the characteristics of the supplier. Since the project is proposing to deliver a unique product, the customer cannot simply test an example of the product, and they must look at the product provider to gain some insight.
So, what should a project team talk about, in the area of management itself, in order to satisfy a customer? It will be insufficient to simply indicate, by quotation, that the project team has read the usual textbooks. It is likely that the customer will have read them too, and re-reading extracts from them will simply signal the naivety of the team.
The customer wants to know about their project
What the customer wants is evidence that relevant management tools will be applied to the project at hand. They will be looking for:
- An explanation of the management structure. Not an essay on all possible management structures, but what roles, reporting lines and duties will be in this specific project.
- Areas of work that will be addressed in certain ways. For example: which areas of work will have detailed critical path schedules or resource plans? Which items within the product will be subject to configuration management techniques?
- Styles of management in certain themes: when will the first risk register be prepared, what is the approach to quality and testing, and so on. In all cases, the reader is interested in how standard techniques are actually applied in this particular case.
- References in some cases. If it’s not safe to assume that the customer has encountered new or unusual tools or systems (i.e. developed in the last decade) are to be used, then a reference may well be helpful. For example, a project may plan to use the DOORS requirements management software in conjunction with an Extreme Programming (XP) approach. Both these would require an informative reference within a plan document. On the other hand, Gantt charts and Work Breakdown Structures need no specific introduction. The APM Body of Knowledge is a good guide as to what may be assumed to be known.
0 Comments:
Post a Comment
<< Home