If you fail to demonstrate knowlege of key topics during the group work the assessors may ask you to answer writen questions. The APM has published the following sample questions.
Question A
Consider a project you have managed or one you know well.
a) Describe key factors in determining and managing the project’s context.
b) Critically analyse the methods used to ensure that stakeholder needs and expectations
were understood and managed over the whole life cycle of the project.
c) Discuss the importance of understanding project constraints (things that must happen)
and dependencies (things on which successful delivery of the project critically depend)
d) Describe the differences between project issues and project risks and your views on the
ways in which issues and risks should be managed
Question B
Consider a project you have managed or one you know well.
a) Describe the organisation for the project, showing the rationale for both the project
organisation and the fit of the project organisation into the wider organisation.
b) Critically discuss the project roles involved, highlighting positive and negative aspects of
each role and their inter-relationships.
Version 2.0 October 2006 9
Question C
Consider a project you have managed or one you know well.
a) Clearly describe the similarities and differences between project success criteria (critical
success factors or CSFs) and business benefits.
b) Using real examples to illustrate your argument, describe the usefulness of spending time
to understand and differentiate success criteria and business benefits at the start of any
project.
Question D
Consider a project you have managed or one you know well.
a) Critically analyse the business case for the project including the justification for investment
and, in hindsight, comment on its strengths and weaknesses.
b) Describe the lessons you have learned about the purpose and importance of the business
case to a project.
Question E
Consider a project you have managed or one you know well.
a) Define the methods used for capturing and managing detailed project implementation
requirements.
b) Critically analyse these methods, defending the aspects you believe were successful and
suggesting areas for improvement.
Question F
Consider a project you have managed or one you know well.
a) Critically analyse the project management plan (PMP) for the project and draw general
conclusions (pros and cons) on its value and usefulness.
b) Comment specifically on the use of:
• Breakdown structures used
• Estimating methods used
• Time scheduling techniques used
• Resource allocation and management techniques used
• Budgeting methods used
Hi you can’t really have model answer for these questions because at the PQ level they ask you to reflect on the projects that you have delivered. So the answers are specific to your project,
QUESTION A a) Project context
The project context is the environment in which the project takes place, it can be split into two categories internal and external both of which will affect the way in which the project will be delivered. Internal context covers areas such as organisation structure (function/matrix/projects) project governance, resource availability and strategic objectives. External context of the project can be assessed using the PESTLE analyse method (political, economic, social, technology, legal & environment) as well as the industry in which the project / organisation operates in: example a construction company is required to adhere to British engineering standards for all of its materials / craftsmanship.
The project in questions is the Jubilee and Northern Line upgrade project (JNUP). Upgrading the old fixed block signalling system to the new Thales dynamic bloke system across two lines on the London underground
Defining the project context was carried out by the project sponsor and the project manager in charge of delivery. It was initially defined in the concept / feasibility phase but developed on further when completing a stakeholder analysis and communication plan.
Internal factors defining the context can be determined through the delivery team. External factors, specifically technical / industry standards will be defined by suitably qualified technical personnel on the project, examples below:
The internal factors of the projects context where:
– Thales PMO governance (stage gates, design reviews, commitment reviews, etc)
– The delivery team, arranged in a matrix organisation, all resources had a functional lead and a project manager
– BAU – Thales has a repairs and spares operation with a variety of customers in the rail industry, undertaking of JNUP could not affect any SLA contracts currently ongoing
– Strategic objectives – To grow the GTS section of the business by 10% over the next ten years, the PM had to identify steps to deliver incremental % increase in market growth over the period of the project to enable the 10% total to be achieved
External factors
– The project has to adhere to all LU safety protocols
o Suitably trained and skilled personnel to carry out works of the construction, testing and installation nature
o LUCAS training for all personal attending the site (rail way training)
o Risk assessments and incident reporting protocols
– Civils and engineering standards to be adhered to
– Electrical safety standards to be adhered to
b) Stakeholder needs and expectations being understood over the lifespan – critically analyse
A stakeholder in a project is someone (or a group) that has a vested interest in the project, either in its delivery methodology, physical output, the benefit achieved or the impact of product / capability on the external project environment / context.
Stakeholders have subjective criteria of what makes a project successful and it is important to understand said criteria and tailor your management approach for each individual stakeholders. The key benefits are to avoid stakeholder conflicts in requirements / benefits, to keep everyone satisfied and to ensure all needs are accounted for
The following steps are most commonly used to efficiently manage the stakeholders of a project
a. Identify all stakeholders, via interview, brainstorming, internet research , lessons learned
b. Analyse their power vs interest in the project and display in the mendelow format
c. Comms plan: will be tailored per stakeholder with monitor, mange closely, keep satisfied and keep informed. These headings are developed on and should link to project milestones . The comms plan should be dynamic as stakeholder positions vary throughout the life of the project
d. Manage to stakeholders as per the comms plan. Feed back on what works well and what does not and update the plan. Continually managing and checking will ensure any changes in position will be captured and you respond appropriately
c) How these were performed and analyse
a. The basis of this activity was derived from the project supply chain and the individual organisational structures of each organisation involved
i. Mayor of London -> TFL -> LU -> Tubelines/Amey -> Thales uk-> Thales Canada -> supply base
ii. Thales UK and Thales Canada being the same company had already established communication channels and procedures which were known to both parties already
iii. Thales -> Tubelines, it was decided that all stakeholders above Tubelines in the supply chain would be managed by Tubelines, unless specifically requested or required.
iv. Identifying all stakeholders was carried out through brainstorming session between TUK , TCAN and Tubelines. Power vs interest was also mapped in this meeting and the output was a populated mendelow stakeholder map.
v. The comms plan was jointly agreed between Thales and Tubelines, Tubelines would handle all organisations above them and Thales would manage all those below. Communications should flow through each organisation and never skip. A “one team†ethos was adopted which emphasized open and honest communication
Disadvantages – Due to the requirement to pass information through Tubelines the decision making process was elongated, which had knock on issues as more often than not the access window to get work done on site was limited and if you missed said window you had to apply through the application portal which had a specific lead time.
Circumventing the communication channels was negatively received regardless of circumstances
Specialist groups were set up to manage the user interface of the network upgrade – Human factors – which represented the drivers. Therefore changes in requirement were immediately passed on through the supply chain. This was an established process meaning the change in relationships / requirements would always be captured throughout the life cycle of the project
Communication channels were set up but the document controlling the process and procedures per stakeholder was never updated to take into account declining influence / interest rates, as it was seen as non value adding
d) Importance of understanding constraints and dependencies
A project dependency is an activity which prevents the subsequent activity from starting until it has been complete.
Projects are essentially a series of dependant and independent activities. Dependencies have knock on affects should they incur a delay independent events do not have such knock on affects (within reason)
A project constraint is an element of a task that limits the possible options to implement said task. The constraints are usually factors such as resources (people/equipment), time, cost environmental factors
Understanding your project dependencies allows a PM to adopt a more holistic approach to planning; it also allows risk and uncertainty to be mitigated. If a key dependency is being managed by a third party it should be highlighted on the risk register and managed as such
Understanding project constraints again can be considered a risk management activity, and careful management of which will allow for a suitable mitigation to be put in place and ideally avoid the issue completely.
Constraints such as physical environment tend be known in specific industries (rail / construction) and suitable methodologies will already be available. Highlighting them and drawing on your organisation experience via lessons learned is a suitable and advisable method to manage known project constraints.
Constraint management Forces the collaboration between PM and “last planner†and propagates the notion of lessons learned being value adding and retention of best practises.
Your top project constraints should be part of your project risk register and managed as such
Dependencies of a specific value or importance, where the delivery responsibility is with a third party, should form part of the risk register.
Non critical or known dependencies and constraints should be managed through effective and regular communication
e) Project issues / risks, and how they should be managed
Risk – A quantifiable (impact and likelihood of occurring are measureable variables) event which has an impact on time / cost / quality of a project which is perceived as negative by all stakeholders involved. A risk is captured on a risk register and likely impact timeline can be created. Risks are perceived to be potential future events rather than currently occurring
Issue – is an event that is currently affecting the project and requires a resolution. The issue may not be completely stopping the projects but by definition is something that will need to be addressed prior to the project completion. A statement could be made to say issues are “previously unknown risks†that have occurred, as all known risks (as per the risk reg) should have a mitigation already in place
Management of each, what are my views
Risk management is an activity that occurs most intensely in the bid phase of a project, and once on contract is rarely attended to with as much importance. Most PMs will view the risk contingency as an opportunity to deliver a project to a higher margin which reflects well from a corporate / financial POV.
My view is that risk (project contingency) should be the second last pot of money touched when a WPs over spends. The focus should be on offsetting over spent WPs with those that are under spent. Risk management, if done correctly is a contractor’s commitment to delivering value and keeping its employees safe. The effort spent on mitigating risk should be mirrored in managing opportunities, many project as unique and transient as they are will share some elements with previously delivered projects, as such the lessons learned will yield best practise, what they should have done, various savings that could have been made etc etc .
Portfolio and programme management can aid in the opportunity management by capitalising on resource usage, non-repetition of ramp up and ramp down times, sharing equipment etc etc
Project Issues, depending on the size (major / minor) I believe can be managed effectively through frequent reviews, open communication and restructuring the issue definition into a question followed by brainstorming for a solution
Issue – “we (the project) do not have any qualified personal to operate a crane at this specific time in the project ergo the lighting of the pre cast concrete will be delayedâ€
Rephrasing – “what do we need to do to get a loan of a suitably qualified individual ? how long will it take? What enabling or percussing activities can we do in the mean time?â€
With any issue it is prudent to set up and maintain an issues log, with an owner, a resolution and a completion date.
The log should be reviewed daily or weekly depending on the severity of the issue.
does anyone have solutions to these questions so i can compare with mine, Many thanks