Key Cards Flashcards

1
Q

LO1 Organisational Structure - Difference between Functional, Matrix and Project p.11

A

Role of Project Manager - F - PM relies on functions with little influence, get BAU distractions. Mat - Authority for duration of project. May be mixed management. P - Dedicated team who focus on project.
Resource Management - F - Maintain a body of skilled staff, M - flexibility to call on expertise as required. P - Report directly to project. May be procured externally, can have exact requirements though time fixed.
Employee’s View - F Secure career path, M - Variety as between BAU and Projects. P - Autonomous team goals, variety though insecure.
Client’s View - F - Wide skill set though lack project status, M - Single point of contact. F - Single point of contact who can react quickly to change.
Knowledge Management - F - In function, M - knowledge gained and retained across both. P - Shared during project may be lost when disbanded.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

LO1 Organisational Structure - Role of Sponsor overall P15

A
  • Accountable for ensuring the project is governed effectively and delivers the objectives that meet identified needs.
  • Governance link between business and project
  • Responsible for securing funding the project needs to succeed.
  • They own the business case and accountability for benefits realisation
  • Project champion and support PM with decisions
  • Chair steering groups and approve project through decision gates
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

LO1 Organisational Structure - Role of Sponsor by stage P16

A

Concept Phase
• Define the business objectives and identify the benefits.
• Ensure key stakeholders agree that the project is worthwhile.
• Create outline business case and secure its approval. Definition Phase
- Appoint the project manager (if not done in the previous phase)
• Agree and approve the project management plan (PMP)
• Secure final business case approval
• Set tolerances, delegate authorities and agree reporting requirements.
Deployment Phase
• Support the project manager during the project life cycle
• Monitor project progress and make control decisions when necessary
• Monitor the project’s external environment and business risks.
• Keep executive stakeholders informed and engaged.
Transition
• Sign-off the project and confirm the closure.
• Ensure business continuity and plans are in place for benefits realisation activities.
Benefits realisation
• Monitor and track benefits realisation through to completion. Some of these activities can be delegated.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

LO1 Organisational Structure - Role of Project Manager overall P15

A

The project manager is focused on delivering the project’s outputs to the agreed project success criteria, which include time, cost and quality.
Manage the project day-to-day
Responsible for planning/scheduling the resources and motivating the project team.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

LO1 Organisational Structure - Role of Project Manager By stage P15

A

Definition Stage
Develop Project management team to provide expertise and clarify roles and responsibilities
Produce Integrated Project Management Plan
Identify, assess and produce plans for managing stakeholders
Ensure adequate controls in place
Prepare for stage gate decisions
Deployment Stage
- Plan delivery stages in detail and delegate work to teams
- Manage risk, issues and change requests
- Report on project progress to sponsor
- Motivate and support team
Transition
- Plan for project outputs to user community
- Conducts post project review
- Disbands project team and ensures assets disposals
- Document project outcomes as required

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

LO1 Organisational Structure - PM vs Sponsor P18

A
  • PMP vs Business case
  • Sponsor commits resources, PM manages them
  • Sponsor approves project progression, PM prepares information for it.
  • Sponsor approves risk tolerances, PM identifies risks
  • Sponsor ultimate change authority, PM prepares changes requests.
  • Sponsor signs off completed project, PM completes post project review
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

LO1 Organisational Structure - Role of Steering Group

A
  • Support the sponsor with decision-making
  • Brings together key stakeholder at a senior level.
  • Typically includes senior representatives from users, suppliers and other key stakeholder groups ensuring strategic direction and guidance is provided.
  • Chaired by the sponsor who has the ultimate decision-making role.
  • PM may attend project board or steering group meetings but will not be a member of it.
  • Help resolve escalated risks and issues that the project manager and sponsor alone cannot resolve.
  • Support go/no-go decisions at the end of each phase.
  • Must be managed as they can become large and unwieldy.
  • Where there are many stakeholders it is quite common to have stakeholder, groups represented on the board. An example is where residents
  • Not all projects require a steering group
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

LO1 Organisational Structure - Role of User

A

Users are the group of people who are intended to work with deliverables to enable beneficial change to be realised
- Groups that will use the project outputs to generate the benefits during the operational/in-service phase of the life cycle
- key in defining requirements at the start of the project and agreeing acceptance criteria against which the products will be tested.
-To ensure project stays focussed on achieving the requirements
- Be involved in product testing and final acceptance.
- Ultimate judges of quality.
Note: Need to manage expectations which may not be within budget / time constraints.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

LO1 Organisational Structure - Role of Product Owner

A

The product owner acts on behalf of the product’s stakeholders and is responsible for maximising the value of the end product.
To understands the product vision and communicate vision to the team developing the products.
To understand the business objectives within a wider framework of the market, customer needs, competitors and trends.
To communicate effectively with stakeholders to lead the team’s discovery of the product and gather requirements.
To ensure decisions made are respected by the team. To be available and able to make decisions effectively.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

LO1 Organisational Structure - Role of Team Members

A
  • Report to and take direction from a team manager
  • Responsible for producing the projects outputs/products.
  • Often specialists on whom the project relies.
  • To agree and deliver work packages in accordance with the project manager’s instructions.
  • Maybe be external so work package should set out clearly the scope of work required, the success criteria, the constraints as well as the process requirements for reporting, escalating risks and issues, raising change requests and work package acceptance and sign-off.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

LO1 Organisational Structure - Benefits of a PMO

A

Deployment support
• Frees up the project manager’s time through administrative support to project managers, eg maintaining risk register
• Provision of expertise such as project tools, specialist techniques and information management e.g. scheduling software and risk modelling.
• Maintaining the filing system and configuration information.
• Supports decision making through the collection, analysis and reporting of project information.
• Support sponsors and senior management to drive projects by exception management and reporting.

Process improvement
• The project office can ‘own’ the project management methodology/framework and therefore promote best practice across the project management community.
• Supports continuous improvement through the consolidation and communication of project delivery improvements and lessons learned implementation.
• Develops and maintains project standards, processes and methods
• Assurance of project management processes.

Resource flexibility
• Assists in the allocation of project management resources
• Helps develop project professionals with skills and training.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

LO1 Organisational Structure - 3 types of PMO structure

A

Embedded PMO: Where the majority of the PMO functions are delivered under the control of the project or programme manager (depending on which is being managed). This is effective on large projects that need lots of support.
Central PMO: Where the majority of the PMO functions sit outside of the teams, providing a service to multiple projects. This is effective where there is a small portfolio of projects, where flexibility is valued.
Hub-and-spoke PMO: A hybrid form with a central enterprise or portfolio PMO linked to satellite PMOs within individual projects. This is effective when there are clear roles and responsibilities between project managers, the project embedded PMO and the ‘hub’ PMO.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

LO1 Organisational Structure - Governance components

A

Policies, regulations, functions, Processes, delegated responsibilities

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

LO2 - Project Lifecycles - Why structured in Phases in linear

A

Provides framework for budgeting, scheduling, allocating resources and assigning team members and experts. Phase completion can trigger the release of resources such as people and money.
• support governance through a series of control points referred to as gates. These are essentially go/no-go decision points. This ensures that only viable projects proceed. It also provides opportunities to revise budgets and timescales and reset the expectations of the stakeholders.
• provide a common structure for consistency across the organisation. Where all the projects in the organisation are using the same lifecycle structure staff can move between projects more easily, senior management can compare projects and people can be trained more efficiently.
• make them easier to manage. Each phase can be treated as a mini project with clear phase objectives, outputs and processes. This allows processes and procedures to be established and communicated across the organisation and inputs and outputs for each phase to be determined.
• facilitate continuous improvement through the passing of lessons from one phase to another and to other projects. This can include improved estimates for completion (time and cost) which will assist in managing stakeholder expectations. Plans for later phases can be updated based on the knowledge gained in previous phases.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

LO2 - Project Lifecycles - Concept Phase

A

takes the project from the initial idea/need through to the approval of an outline business case.
- Sponsor appointed
- Need confirmed and investigated
• high-level requirements are identified
• Alignment with the portfolio/programme checked
• Options identified and evaluated (including ‘do nothing’)
• high-level benefits, costs and risks are identified • stakeholders are identified
• plans for next phase are produced
• the outline business case is developed (and signed off)
• a project manager may be appointed at the start or during this phase although the sponsor is often supported by a business analyst for this phase
• a Gate review is held to decide if the project should proceed to the next phase

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

LO2 - Project Lifecycles - Definition Phase

A

Moves project from gate approval at concept phase to the approval of the project management plan (PMP)
• appointment of the project manager by the start of this phase
• confirmation of the preferred solution
• testing the preferred option (for the solution to the project need) against the high-level requirements
• development of detailed requirements and scope
• production of detailed plans for the development phase
• creation of the PMP
• updating/refining the outline business case as required, in light of the outcomes from the detailed planning estimates
• sign-off of the PMP and business case
• preparation for gate review

17
Q

LO2 - Project Lifecycles - Definition Phase

A

Project specific outputs (products) are developed. This phase may be broken down into smaller stages to aid in team focus and management control, e.g. detailed design, build, test, install/deliver.
• implementing the plans in the PMP
• developing and delivering the product/solution
• optimising and signing-off the product/solution design • executing the project through work packages
• the project manager monitoring and controlling the implementation activities to ensure the project is delivered within time, cost and quality constraints
• managing risks, issues and changes
• updating progress and project status and reporting to stakeholders
• holding end-of-stage reviews as required, e.g. signing off the detailed design before moving to the build stage. Stage reviews are often more about the product’s journey than the phase gates, which are about the project’s journey
• getting ready to hand over and close the project and ensuring plans to do this are confirmed and agreed

18
Q

LO2 - Project Lifecycles - Transition Phase

A

ensuring that the project outputs are handed over and accepted by the sponsor on behalf of the users
• the project outputs are formally accepted and handed over to those responsible for using/ operating the product (a formal transfer of ownership is essential)
• the handover of all associated product documentation
• any commercial settlements
• completion of all project documentation and archiving it as agreed
• closing down the project team and associated infrastructure
• reviewing project performance (hold post-project review)
• a final capture, consolidation and dissemination of lessons (lessons learned)
• provide a final project report to the sponsor
• accept the final report and confirm the project closure

19
Q

LO2 - Project Lifecycles - Extended Phase

A

Extended lifecycles ensure that accountability and governance of the investment stays with the change teams until the change is fully embedded and avoiding a knowledge barrier between project teams and operations. The purpose of this phase is to ensure the change is adopted and the benefits are realised as documented in the business case
- Tracking and measuring the benefits. Benefit owners are responsible for monitoring the actual benefits realised against the planned benefits. Examples of this include monitoring sales of a new product, measuring improvements in efficiency and cost savings.
• Identifying problems regarding the quality and performance of the products. This will allow remedial actions to be taken and the improved product to be further monitored.
• Identifying opportunities. This will allow actions to be taken to maximise benefits. Examples include more advertising to increase sales of a new product, technical changes to improve efficiency and exploiting new uses for a product.
• Capturing lessons from this investment. This can lead to improved future investment decisions.

20
Q

LO2 - Project Lifecycles - Iterative lifecycle

A

Repeats one or more of the phases of a project or programme before proceeding to the next one with the objective of managing uncertainty of scope by allowing objectives to evolve as learning and discovery takes place
- Used where prototypes or parallel activities are used to acquire new insights, obtain feedback or explore high risk options.
- Based on idea of concurrency or simultaneous engineering where different development steps are performed in parallel.
- One or more of the lifecycle phases are repeated before proceeding to the next one.
Recognises uncertainty and allows objectives to evolve as learning and discovery takes place. Allowing the specification and design to run in parallel ‘fast-tracks’ the deployment.
Often uses prototyping to provide rapid feedback from stakeholders. This in turn, drives adaptation and improvement.
This ‘agile’ approach requires collaboration between the product developers and the customer. To achieve this, a product owner is appointed by the customer and will represent the users. The product owner will provide the initial high-level requirements and work closely with the team to further develop the requirements and facilitate the feedback process with the end users.
Many agile methods apply the idea of timeboxing, an iteration with a fixed end date which will not change, thereby adjusting the scope and quality to deliver on time and to cost.

21
Q

LO2 - Project Lifecycles - Linear vs. Iterative

A
  • L Set steps vs. I no set steps, done in cycles
  • L full requirements before proceeding, iterative evolves from learning
  • L full control with go/ no go decision points, Iterative shorter and relies on feedback to proceed
22
Q

LO2 - Project Lifecycles - Reviews

A

Decision gates, post project review, benefits review, audits

23
Q

LO2 - Project Lifecycles - Premature closure

A
  • Cost greater than benefits
  • Technical failure
  • Fundamental change in requirement
  • Objective becomes obsolete
  • Force Majeure
24
Q

LO2 - Project Lifecycles - Knowledge and information informing decisions

A

Supporting gate decisions.

  • By understanding progress to date in terms of cost, quality and time, and how these affect future phase/stage plans, the sponsor can decide if the project should proceed to the next phase.
  • By understanding how the data available (e.g. actual costs) affects the viability of the business case, the sponsor can decide on the future course of the project including the decision to prematurely terminate it.

Anticipating changes to the project and responding to them in a timely way.

  • May include gathering data from the stakeholders and understanding their changing needs.
  • Can allow a project to plan and obtain resources to respond to changes.
  • An example of this is a new regulation that requires a technical change to a product that is being developed.

Avoiding mistakes and repetition of errors through the gathering of lessons learned.
- Where impacts of previous errors are understood, organisations can decide to change processes, improve skills, adopt different techniques etc. to ensure new projects do not repeat the same mistakes.

Taking actions in response to progress data (e.g. timesheets and booked costs).

  • Helps PM to understand the project status in relation to the baselined plan.
  • May be in the form of earned value graphs/charts.
  • The PM can then make decisions regarding project progress. This may involve allocating more resources to improve performance or escalating the situation to the sponsor.
25
Q

LO3 - Situational Context - BAU vs Projects

A

Output - P - Deliver unique output. BAU - Use unique products to generate benefit.
Timing - P = Start and Finish so need to be clear on timings. BAU - established and ongoing
Risk - P - Higher as unique, thus contingency. BAU - lower as mitigated through established plans.
Teams - P - Temporary into high performing units. BAU - Established with clear reporting lines.
Funding - From business case highlighting benefit thus each need to be justified. May need contingency as high unknown unknowns.
Planning - P - All time, cost and quality planned in advance by project with need for contingency due to uniqueness. BAU - Planned on a longer term basis and builds on established plans with fixed resources.

26
Q

LO3 - Situational Context - Project management processes include:

A
  • A starting process to identify the need and the justification
  • A defining and planning process detailing what project will deliver
  • Monitoring and control process
  • A risk management process
  • A change management process
  • A learning and control process
27
Q

LO3 - Situational Context - Programmes

A

Combine new deployment with elements of BAU. Capex to acquire assets, products and capability alongside operating expenses for normal BAU
- Has a vision of an end state and usually starts with a vision of a changed organisation and the resultant benefits.
• has a definition of the programme end state – this is normally called a ‘blueprint’
• may not have a well-defined path at its start.
• has coordinated outputs delivery (from its constituent projects).
• realises its benefits both during the programme and following its completion.
• includes projects not directly delivering benefits (enabling projects).
• is longer in duration than a project.
• is more strategic than a project, which is more tactical in nature.

28
Q

LO3 - Situational Context - Where to use programmes

A
  • Where strategic change is required though a number of projects
  • A group of projects leading to a single vision of change
  • Where there is significant interdependencies between projects
  • Where projects share common resource
29
Q

LO3 - Situational Context - Programmes include

A

Coordinating projects: identifying, initiating, accelerating, decelerating, redefining and terminating projects within the programme.
• Managing interdependencies between projects and BAU activities.
• Taking project outputs and managing change within business-as-usual so that outputs deliver outcomes/capabilities.
• Defining, quantifying, measuring and monitoring benefits.
• Managing key stakeholders so that relationships are developed and maintained, enabling proactive two-way communication.
• Managing resources across the programme so that projects can be prioritised properly.
• Managing processes, such as risk and change at a programme level, allowing the bigger picture to be seen and efficiencies to be achieved.

30
Q

LO3 - Situational Context - Portfolios include

A
  • Numerous projects and/or programmes that need to be coordinated and aligned to an organisational goal.
    • Improved management of resources across the projects and programmes is required, e.g. improved utilisation, efficiency.
    • Opportunity for improved delivery of projects and programmes, through a portfolio-wide view of risk, dependencies and scheduling to reflect the capacity to absorb change.
    • Where there is risk that poorly performing projects may continue, and non-strategically aligned projects may exist.
    • Where changing conditions may require a constant review and adjustment of the projects and programmes.
    If the portfolio is not managed, the following can occur:
    • Projects and programmes may be initiated that do not ‘fit’ with the aims and objectives of the organisation.
    • The organisation may not be able to fulfil its obligations as resources become stretched and stressed through overwork due to too many projects being approved.
    • Project and programme outputs may be of poor quality caused by insufficient skills and resource levels.
    • The organisation may be exposed to high levels of risk as it takes on either too many or the wrong types of projects and programmes.
    • Projects and programmes that no longer fulfil the requirements of the organisation may not be cancelled and continue to consume valuable resources.
31
Q

Stages of requirements management

A

Gather requirements
- Wants and needs of stakeholders
- Ensure clear understanding of what the solution must do.
- Workshops, questionnaires, specialist knowledge, surveys.
- Requirements at this stage described as functional ie solution to achieve.
Analyse requirements
- Requirements further defined
- Look for gaps, overlaps and conflicts between requirements
- Each requirement should be unique, verifiable with an agreed acceptance criteria to enable progressive acceptance during transition.
Justify requirements
- Not all Requirements have same priority.
- All requirements to be justified by those requiring them.
- List of wants may be greater than what viable from business case.
- MoSCoW
Baseline Requirements
- Requirements must be agreed and signed off before solution development begins
- Must have consensus with stakeholders otherwise conflicts and scope creep later.
- Marks point of agreement and starting point.
- Change under version control giving audit trail.
Test During implementation
- Vital to ensure progressive checking that solution meets requirements
- Can be seen as series of reality checks
- Important to refer back to original requirements to avoid stray.