Feedback for Project Definitions
Overview:
• Follow the template; a paragraph to give an overview of the company (relevant to the
project) and a paragraph to give an overview of the project itself.
• Be clear who your company (and client) is and what they do.
• Be succinct! If you are explaining the client’s motivation, you do not need to provide a high
level of detail. For example, it does not make sense to write they aim to increase efficiency
by 10% as rarely would your audience (your management) have the details to interpret this.
• Tactical Goals can be okay for first paragraph but make use the strategic goal is also clear.
• Justifications for a project may make claims of fact; if so, consider if they should be
referenced.
• Language needs to be professional but also clear of multi-disciplinary audience.
• If the project claims to improve performance or efficiency, try and be as specific as you can
be. Consider making some estimate of the cost-benefit ratio or other financial (or triple
bottom line) assessment (for example, ROI, payback period). Note, it is not expected that
you perform a full cost-benefit analysis.
“Is / Is not” Table:
• “Is / Is not” Table is to help define PROJECT SCOPE (rather than time or cost management)
by summarising broad inclusions and exclusions. The Is/Is not descriptions should generally,
therefore, be as close to either side of the boundary (or terminal point) as possible.
• It must be about a specific project not operations or on-going maintenance.
• It is not about capability of deliverables or benefits of outcomes.
• Exclusions should be relevant and not obvious.
SWOT:
• Be clear on the subject matter of the SWOT. For a Project Management Plan, it should be
about your organisation’s or PM team’s ability to deliver the project rather than the project
outcomes, the project purpose or customer benefits. So, for:
o Strengths, list the strengths of the organisation and/or the project team that will
assist in the successful delivery of the project
o Weaknesses, list the weaknesses of the organisation and/or the project team that
may hinder the successful delivery of the project. Weaknesses may lead to the
identification of Issues.
o Opportunities, list the opportunities that come from outside the organisation that
exist to deliver a successful project or that a successful project will bring to the
organisation (not unrelated business opportunities for the organisation)
o For Threats, list the threats that come from outside the organisation that exist that
may hinder the delivery of the project or that an unsuccessful project will bring to
the organisation (not unrelated threats to the project). Threats may lead to the
identification of Risks.
• In you introduction paragraph it would be useful to the reader to briefly indicate how
Strengths and which Opportunities are going to be exploited and where management of the
Weaknesses and Threats is detailed.
SMART Goals:
• When presented in the table form, make sure that all boxes are filled appropriately.
• For some reports, the SMART elements of the goal did not seem to relate to each other.
Each row of a SMART goal is about a single goal.
• Do not simply state the timeframe of every goal as the duration of the project. Sometimes
the goals can be achieved earlier (for example, when they relate to a milestone), or later (for
example, efficiency gains which will be determined well after the project has been
complete).
• Goals must not be self-contradicting or contradict other goals
• Some of the goals read more like the company goals, ie the reason for doing the project.
Goals should not be too far removed from immediate outcomes of project.
• Each Goal should have a single focus (ie be specific), that is, avoid complex goals. For
example, “increasing client comfort levels with reduced energy consumption”, can be
confusing as the reader does not know if this Goal is about client comfort of energy
reduction.
• Goals need to make sense for the specific project. Eg Increase installation by 5%. The
equipment is either installed or it is not. If you mean the number of installations (ie sales)
then write that.
• The “R” can refers to relevance of your company or the client’s motivation for the project.
The “S”, however, should be a specific project goal, and if possible, expressed with respect
to your company. If this causes confusion, then it is okay to write the specific project goal
with respect to the client (after all, if the project outcome is important to the client, its
important to the project team).
Success Criteria:
• The success criteria should be complete. For example, to state success as “To increase
efficiency by 10%” is open to interpretation. The term “efficiency” should be defined or an
explanation of how the efficiency would be determined (calculated) should be provided.
• Success Criteria should be measurable on completion of the project
• In many cases the metric and the metric value for the goal and the success criteria may
differ. For example, a project may have a goal to install a piece of equipment operatable at
the rated capacity to achieve a certain yearly production, whereas the project will be
deemed successful if the piece of equipment meets the commissioning requirements to run
continuously at 95% rated capacity running for 85% of normal operating hours over a oneweek period.
• Success Criteria should also have the SMART elements, for example, if you set a Success
Criteria as increasing customer satisfaction by 5%, then you should indicate how it will be
measured and relative to what.
• Project success is not just achieving the project benefits, deliverables, or outcomes (ie the
project owner objectives). Also consider meeting the project team (ie project management)
objectives.
• For projects undertaking a trial, be careful how you determine the success of the trials. For
example, if the objective is to determine a roll-out cost, the gaining of the reliable
information represents success, not necessarily that the costs are below a feasibility
threshold. In other words, identifying a bad investment prior to investing can be a very good
result.
Project Classification:
• Justify the rating you give each classification element of the NTCP Diamond Framework.
• Consider a brief explanation of the implications of the determined project classification. If,
for example, you are dealing with a complex system of systems, there will be implications on
Quality management (such as testing each individual system prior incorporating it into the
system of systems. On the other hand, if you are dealing with a pace that is Blitz or Crisis,
then costs may increase to greater amounts than projects of lower time pressure.
Management Approach Adopted:
• Justify the Management Approach chosen and then ensure it is used throughout the PMP.
• Do not provide theory of the approach rather provide details relevant to the project. For
example, if stage gate, do not explain what stages and gates are, rather provide details of
the stages and gates specific to your project. Provide details of the decision to be made
prior to proceeding to the next stage (for which there is usually a report required for the
decision maker and the creation of this report should therefore feature in the scope or the
Document RACI).
• Do not simply use the textbook descriptors for the approach. For example, for Stage-Gate,
tailor the descriptors of the stages and gates to suit your project rather than the descriptors
for New Product Development
• Do not invent new approaches. Its best to stick to those from OPS935 else provide a
reference.
Utilisation Matrix:
• The Utilisation Matrix should add clarity or justify the deliverables within the scope.
• For the Utilisation Matrix, list your goals or benefits in order of priority
• Many of the noted Utilisation Matrix deliverables were tasks (tasks are not deliverables).
Deliverables are nouns, not verbs.
• The Utilisation Matrix deliverables are those within your project, not the benefits of the
project for the organisation. For example, your project might be to acquire a piece of
equipment to open new markets for the organisation; this does not mean the new
equipment will deliver increased profits within the project itself (they are outcomes).
• For the Utilisation Matrix itself, some of the relationships between deliverables and benefits
are poorly considered. Do not force it; if you have a deliverable that does not have a
relationship with a goal, ask yourself why do it. If it is not readily evident how a deliverable
relates to a goal, consider changing the way you describe the deliverable or explaining the
relationship.
Milestones:
• Milestones are events without a duration or moments in time, they are not a set of tasks, for
example a milestone is not the testing of a prototype, it is the issuing of a certificate for the
successful testing of the prototype.
Risk (Known-unknown) Planning
• Some risks were generic or irrelevant. They should be specific to your project.
• Be specific on actions you plan to take. Writing “take appropriate actions” is not adequate
as a mitigation plan.
• Consider the Threats of the SWOT to help identify Risks for the project
• Some PMPs had an empty or missing “Reason” column. The “Reasons” may explain the
cause to be addressed but consider using this column to explain why the risk is important to
manage and puts the risk treatment into perspective. For example, there might be a risk of
“rainy weather”, and the reason this is a risk might be; “project delays”, or it might be one of
“safety”, on the other hand it might be one of “equipment damage”. Plainly, depending on
the “Reason” being addressed, the respective mitigation and contingency plan would differ.
• Provide a Key for the probability (or likelihood), consequence (or impact) and risk scales.
• Provide some evidence or commentary to justify the proposed treatments or verify their
effectiveness. This may include consideration of the residual risk, i.e. whether the proposed
treatment reduces probability or consequence adequately. Rarely does one treatment
reduce both and sometime more than one treatment is necessary to reduce the risk level to
an acceptable level.
Main Issues (know to exist and needs to be managed)
• These are often related to, but not limited to, the weaknesses of the SWOT analysis.
• If you have addressed the “issue” in the Risk Management Plan, you do not need to repeat
it.
• Do not just mention an issue without giving the reader (ie management) an explanation of
how you plan to manage the issue (an action plan). This is important to demonstrate that
your team can deliver this project.
• Issues should not include standard aspects of the project that need to be managed.
Constraints/Assumptions
• Some statements are too brief that the meaning is unclear or open to interpretation.
• Some confusion about what Constraints and Assumptions are.
o Constraints are typically externally applied or forced upon the PM team, for
example, a deadline or statutory approvals. Don’t confuse constraints with risks
(which need to be managed). The PM team simply must work within the constraints
o Assumptions are assertions regarding uncertain details that are set at the time of
Planning, which then need to be monitored and accounted for during the execution.
For example, “the schedule assumes no delays due to rain”. Stating this assumption
tells the reader that if rain occurs, the schedule will need to be adjusted accordingly.
Note that assumptions are often a source for identifying risks.
• An assumptions list of several different financial rates is not wrong but hardly impressive.
General:
• Make sure you follow the PMP template provided for OPS936. Do not use the one from
OPS939 – there are some differences for reason which will be explained as we progress.
• Remove the template instructions.
• Your PM Plan should suit intended audience, the approvers of the project (you want to
provide assurance that you have the plan and skills to deliver the project).
• For tables, for example, information is often in truncated form, rather than full sentences.
This is okay, but your meaning must be clear.
• Grammar, Spelling, Punctuation; Get all team members to check the report.
• Define acronyms when first used.
• All diagrams and tables should, as a minimum, have a lead-in sentence. It looks
unprofessional to simply have a subheading and a diagram with no explanation of the
diagram.
• Make sure diagrams that need a key (or legend) has one.
• The PMP does not need to contain the PM theory unless it is relevant to explain choices
made. Don’t use theoretical diagrams unless it matches your project perfectly, rather tailor
the diagram to your project. For example, do not show a standard stage gate diagram for
product development unless you are developing a product, rather show the diagram with
your specific stages and gates.
• All reports should have some closing remark. (to inspire the PM team, or to assure the CEO
and sponsors you have a well-considered plan)
• If symbols are used in diagrams or tables, they must be explained.