Please enable JavaScript.

Coggle requires JavaScript to display documents.

Chapter 15: Project management, •Project costs include: - Coggle Diagram

- - - - • a start/end (defined timelines)
      - • specific/ one-time goals/ objectives within budgets/ constraints
      - • new, unique, time-bound task; • interdependent tasks that determine sequence
      - • require cost control, organization
      - • resources allocated include money, facilities, staff etc.
  - - - Pre-initiating tasks for senior managers:
        
        •Determine project objectives and constraints:
        
        Set project scope
        
        Identify time and cost limits.
        
        •Select the project manager.
        
        Project Manager Responsibilities
        
        Planning:
        •Perform detailed planning of budgets, resources, and schedules
        Manages project resources, budget and schedule
        
        Communicating:
        • Keep stakeholders informed and properly brief project team. Manage expectations.
        Reports to the project sponsor on project status
        
        Coordinating:
        • Coordinate project activities between team, suppliers, owner, and end users.
        Responsible for managing the day-to-day activities of the project
        Develops the project plan and assigns tasks to team members
        
        Monitoring:
        • Monitor progress against the plan and take corrective measures as needed.
        Monitors project progress and makes tactical decisions to keep it on track
        
        Problem solving:
        • Resolve problems.
        
        Quality control:
        • Manage quality procedures and trade-offs of functionality vs deadlines.
        
        Leading:
        
        Build team cohesion and team spirit.
        
        Obtain necessary resources.
        
        Ensure the desired result is achieved on time and within budget.
        
        -> Manage changes:
        
        Three ways that project changes may be forced are listed with bullet points:
        
        Changes in the environment
        
        Internal changes impacting resources, production, etc.
        
        The project sponsor changing the scope
        
        When changes are enforced, what the project manager should do:
        
        Revisit the project initiation document and update it
        
        6 more items...
        
        Reconsider if goals can still be achieved
        
        3 more items...
        
        Agree a new business plan with the sponsor if needed
        
        2 more items...
        
        Treat it as a slippage problem (project delays caused by change) and use control actions (a few options for controlling the schedule and getting the project back on track)
        
        2 more items...
        
        Negotiate with the project sponsor rather than simply accepting changes
        
        6 more items...
        
        Suggest the changes are considered as a new follow-on project
        
        8 more items...
        
        •Identify the project sponsor.
        
        Project Sponsor Role:
        
        Resourcing:
        • Provide and be accountable for resources invested in the project.
        
        Owning:
        • Responsible for achieving the project's objectives.
        Ownership of a project refers to who is ultimately responsible for its success or failure.
        
        Delegating:
        
        • May not be involved in managing the project or supervising the project manager.
        
        • May appoint a project owner to:
        
        Monitoring:
        •Review project plans and progress regularly.
        
        Arbitrating:
        •Arbitrate conflicts between project and line management.
        
        The project sponsor has more strategic power. They decide if the project goes ahead, what its priorities are and how it fits with business goals.
        
        The project manager has more tactical power. They manage the tasks, teams and day-to-day decisions required to execute the project plan.
        
        •Take part in initial planning and scoping:
        
        Ensure viability of business case
        
        Align project with business strategy
        
        Establish success criteria
        
        Having a sponsor who can define the project scope and objectives quickly helps get the project initiated properly.
        
        •Liaise with stakeholders:
        Ensure project scope meets needs
        
        Requirements gathering stage from post project review:
        •Failure to consult external stakeholders (catalogue supervisors and agents)
        
        -Only internal stakeholders consulted
        
        -External requirements and needs not captured
        
        -Lesson: Include external stakeholders in requirements gathering
        
        •Support project manager and team:
        Escalate issues
        
        •Provide information to the board
        
        •Coordinate closely with project manager
        
        Sponsor role: Formally defining the sponsor's responsibilities would have held them accountable for promoting/approving the project. The changing sponsor's unfocused approach caused issues.
        
        Sponsor role:
        
        Every project needs a sponsor to make decisions, provide resources and sign off deliverables.
        
        Ideally, a single person acts as sponsor for consistency. Group sponsors can work but must present a united front.
        
        The steering group here exhibits conflicts and lacks unity, signaling unclear sponsorship.
        
        The key issues were:
        Group Management:
        
        The steering group was factional, stuck in a 'storming' phase.
        
        split into competing subgroups focused more on in-group/out-group dynamics than uniting around common goals.
        
        In the scenario, the steering group exhibited several storming behaviors:
        
        Doctors held more power and resented support staff inclusion. Nurses sided with doctors.
        
        Terry failed to manage differences, undermining progress by questioning a doctor's ethics and bringing in an external stakeholder.
        
        This refers to the concept of group stages or group development theory. Researchers have proposed that groups tend to progress through several typical stages as they form and work together:
        
        Forming: The group comes together but members are still strangers. Politeness and uncertainty dominate.
        
        Storming: Conflict arises as members jockey for position, power and influence within the group. Disagreements and tension increase.
        
        Norming: The group establishes norms and processes for working together. Conflicts are managed constructively.
        
        Performing: The group settles into a high-performing team where members work interdependently and collaboratively.
        
        For the steering group to be effective, Terry or another leader would need to
        
        manage the political tensions
        
        help members establish trust and work through their disagreements.
        
        help the group progress from the storming stage into norming and performing to actually achieve their objectives.
        
        Here is a summary of how group development stages relate to project management
        Group formation matters - A team that can't get past storming together Will struggle to work performing. The PM guides them through the process.
        
        Many Projects Involve Teams:
        Most projects involve forming cross-functional or multi-stakeholder teams to do the work.
        
        Stages Impact Success:
        How well teams navigate each stage, especially storming, impacts productivity and outcomes.
        
        PM Manages Stages:
        The project manager facilitates the team's development:
        • Helps them through storming into norming/performing
        • Manages political tensions that arise
        
        Not 1:1 Mapping:
        While group stages and classic project stages don't align perfectly...
        
        Early Performance Helps:
        Teams tend to reach performing by execution to be coordinated and collaborative.
        
        Subgroups Also Impact:
        subgroups "stuck" in storming can lower overall productivity, so the PM must manage these dynamics too.
        
        Project Sponsor:
        
        Usually a senior executive or business leader
        
        Provides funding, resources and support for the project
        
        Champions the project within the organization
        
        Makes strategic decisions about the project scope and priorities
        
        Holds the project manager accountable for project progress
        
        Sponsor - The new mayor must confirm she will sponsor the revised project as it has lost its original sponsor.
      - Building the Business Case
        
        Justification:
        • Developing a strong business case justifies the resource investment to management
        
        Objectives:
        • Reasons for a business case:
        
        Obtain funding
        
        Compete for resources with other projects
        
        Improve planning
        
        Improve project management
        
        Scope:
        • Assessing the strategic context
        • Identifying constraints
        
        Strategic fit:
        Demonstrating how the project aligns with Rush's strategic goals can support a business case, especially given Rush's focus on innovation. If not aligned, the project may dilute strategic efforts.
        
        Weakness from post project review:
        •Scope of implementation was too ambitious
        
        -Implementing all supervisors and agents immediately was risky
        
        -Lesson: Risk assessment of scope is important; reduce scope to mitigate risk
        
        Risk Management:
        • Analyzing risks and risk management
        
        Evaluation:
        • Evaluating project benefits, costs and how they will be managed
        
        Types of Project Benefits
        
        Strategic benefits:
        Gain competitive advantages
        
        Productivity gains:
        Increase efficiency and eliminate nonessential activities
        
        Management benefits:
        Increase organizational flexibility and managerial agility
        
        Operational benefits:
        Improve resource and asset utilization
        
        Functional benefits:
        Improve HRM, marketing, service, etc.
        
        Intangible benefits:
        Improve morale, satisfaction - though difficult to quantify
        
        Emergent benefits:
        Secondary, unexpected benefits that emerge over time
        
        Cost-benefit analysis: Conducting an analysis of the costs versus the benefits would help determine if the event is financially justified. This includes quantifying any projected revenue gains from new sales.
        
        Feasibility:
        • Not every proposed project can be undertaken due to:
        
        Limited resources
        
        Costs that exceed benefits
        
        Financial feasibility: Assessing whether sufficient funding exists for the event helps determine if the project is feasible. Limited resources could jeopardize its success.
        
        Operational feasibility: Considering whether the event fits operationally with Rush's workflow ensures practical feasibility. Undertaking unrealistic projects increases the likelihood of failure.
        
        A feasibility study is needed to determine technical and cost implications of prioritizing buses.
        
        Approval:
        • A business case seeks approval and adequate resources
        
        Business Case Document Sections:
        
        Summary:
        • Executive summary:
        
        Key considerations
        
        Options
        
        Recommendations
        
        Financial numbers summary
        
        Context:
        • Current situation description:
        
        Strategic and operational assessment
        
        SWOT analysis
        
        Identify problems and opportunities
        
        Evaluation:
        •Options considered:
        
        Assessment of options
        
        Reasons for rejecting options
        
        Financials:
        • Costs and benefits analysis:
        
        Quantifiable benefits and costs
        
        Intangible impacts
        
        Project appraisal outputs
        
        Comparing costs/benefits (2):
        Belongs in the business case for approval.
        
        Impact:
        • Impact assessment:
        
        Effects on organizational culture, management, roles, etc.
        
        Risk management:
        •Risk assessment:
        
        Identify risks and risk management strategies
        
        •The 3 elements of risk analysis are:
        
        Identification
        
        • Identifying risks involves:
        Anything that negatively impacts constraints: time, cost, scope
        
        Identify risks: Determine key risks relating to project scope, resources, timing and other factors unique to the project and company. This ensures risks do not pass unnoticed.
        
        Assessment
        
        •Risks are analyzed based on:
        
        Likelihood:
        
        The probability they will occur
        
        Impact:
        
        The effect on the project
        
        Assess impact/likelihood: Evaluate the potential impact of each risk and its probability so risks can be prioritized. Higher impact/likelihood risks require more mitigation effort.
        
        Management
        
        •Risk management examples include:
        
        9 more items...
        
        Mitigation strategies:
        •Match strategy to risk level:
        
        5 more items...
        
        Documentation: Record all risks, assessments, strategies and contingency plans. This provides a reference to revisit and adjust as the risk environment changes over time.
        
        Risk:
        No attempt made to consider key risks upfront.
        No contingencies for risks like lost personnel.
        
        In the planning stage:
        
        The risk assessment is fairly high-level and broad since project details are still being defined.
        
        The focus is on identifying as many potential risks as possible based on similar past projects, knowledge of the industry, and inputs from stakeholders.
        
        The assessment of likelihood and impact of risks is also fairly rough since many specifics of the project are not yet known.
        
        The goal is to identify major risks that need to be considered in the project plan and budget.
        
        Recommendations:
        •Project justification:
        
        Pulls together information to recommend path forward
        
        Appendices:
        •Detailed costs, benefits, and schedules for analysis
        
        Business Case - Strategic Analysis
        
        Justification:
        • The strategic analysis justifies the strategic reasons and drivers for the project linked to external changes.
        
        Analysis:
        •A SWOT analysis:
        
        Assesses the organization's strategic position
        
        Justifies proposed project changes
        
        Internal Assessment:
        •Identifies:
        Strengths to exploit
        Weaknesses that may impact the project
        
        External Assessment:
        •Identifies:
        Opportunities to exploit
        Threats to defend against
        
        Constraints:
        • The key project constraints are:
        
        Cost
        
        • Initial budget
        • Benefits must exceed costs
        
        Time
        
        • Completion deadline
        • Man-hours available
        
        Scope
        
        • Tasks to perform
        • Quality levels
        
        Interrelationships:
        • Constraints are interrelated:
        
        Changes in one dimension often require changes the other two dimensions to maintain feasibility
        
        Shortening time may require increasing costs for more resources to maintain scope and reducing scope by removing tasks
        
        Increasing scope may require extending (more) time to accomplish additional work and increasing budget/costs to cover additional resources
        
        Decreasing costs may require reducing scope or extending (more) time to accomplish same scope but cost savings from fewer resources
        
        Control:
        • In control, understand the priority of constraints and:
        
        Change the most important constraint as little as possible.
        
        Determining Constraint Priorities
        Importance:
        •Determining which constraint is most important and least important allows managers to:
        
        Focus:
        Focus resources effectively
        
        Problem solving:
        
        3 more items...
        
        Scope-driven:
        
        1 more item...
        
        Scope-flexible:
        
        1 more item...
        
        Changes:
        
        2 more items...
        
        Business Case and PID:
        
        Would have provided justification and details to inform the project team.
        
        Especially critical with turnover of key personnel, to retain original details.
        
        Lack of these lead to issues with:
        
        Could have addressed issues around: roles, objectives, scope, budget and risk management.
        
        Likely reduced issues that led to delays and cost overruns on the project.
      - A project initiation document (PID)/ Project term of reference / Project charter:
        A PID formally approves and launches the project once the business case has been accepted.
        A formal, detailed document containing planning information from sources like the business case, risk assessments, Gantt charts Contains all information necessary to execute the project More operational focus than the business case
        
        •Project title
        
        Project: Online Ticketing System
        
        A brief name that succinctly describes the project.
        
        •Purpose/ Objectives:
        Purpose statement
        Objectives
        
        •Enable customers to buy tickets online
        •Increase customer satisfaction
        
        Defines project objectives
        
        A short summary of what the project aims to achieve and the problems it seeks to solve. The key objectives are also listed.
        
        Objectives (SMART): Define specific, measurable marketing goals to assess success beyond simply hosting an event. This can guide planning and execution.
        
        Objectives (project vs business):
        
        Clarifying distinct objectives would have aligned stakeholders and assigned accountability, rather than blaming the builder for not meeting unspecified business goals.
        
        Clarifying project versus business objectives upfront would have aligned stakeholders on what could be feasibly achieved by the project team.This would have prevented misaligned expectations and 'finger pointing'.
        
        The key distinctions here are:
        
        Business Objectives: The higher level goals of the organization that the project supports.
        
        Business Objectives: Improving health outcomes for patients.
        
        Project Objectives: The specific, achievable goals of the project itself which contribute to business objectives.
        
        Project Objectives: Unclear. They seem to range from establishing a strategic planning system to developing an information system. No single, specific objective is defined.
        
        Technical Objectives: The functional requirements of any technology solutions used in the project.
        
        Technical Objectives: The features and functions of the Eurotek software package.
        
        The issues:
        
        The CEO confuses business and project objectives, contributing to a lack of focus.
        
        A technical solution (software) is chosen before clearly defining project objectives and requirements.
        
        Project participants are unclear what they are actually supposed to achieve, lacking a consistent objective.
        
        To fix these issues for future projects:
        
        Define a single, specific and achievable project objective in a Project Initiation Document.
        
        Distinguish this from the broader business objectives the project supports.
        
        Separately define the technical requirements to meet the project objectives.
        
        Do not choose technical solutions before defining project objectives and requirements.
        
        Objectives - The objectives have fundamentally changed from reducing congestion for all vehicles to prioritizing buses and encouraging a shift to public transit. The focus is now on discouraging car use.
        
        Objectives:
        
        Objectives were unclear and unsupported by data.
        
        Business objectives were defined, but no project objectives.
        
        •Dates/ timing:
        
        The planned start date, finish date and timeframe of the project. Important milestones may also be included.
        
        Start and finish dates
        
        •Time
        
        Complete within 12 months
        
        Operational within 12 months
        
        Schedule: High-level timeline
        
        •Roles:
        
        •Project manager (Rail Co)
        
        •Development team (external)
        
        •Rail Co director of projects
        
        •Non-executive director
        
        Identifies sponsor and manager: The PID should clearly define:
        
        The owner/sponsor's role and responsibilities
        
        Their authority level in terms of decision making and resource allocation
        
        Any constraints they operate under from senior management
        
        The roles and responsibilities of key players involved in the project like the sponsor, manager and team members. An organization chart may be included.
        
        Roles and responsibilities:
        For key team members
        
        Team roles: Clarify roles and responsibilities of the diverse functional team to coordinate efforts and reduce ambiguity.
        
        Having a clearly identified and empowered project owner is important for several reasons:
        
        It provides a single point of accountability for the project's outcomes
        
        There is a clear chain of command and decision maker for the project team
        
        The owner can intervene and resolve issues that stall the project
        
        The owner can champion the project within the organization and remove barriers
        
        A lack of clear ownership often leads to:
        
        Unclear accountability and finger pointing when problems arise
        
        Mixed or changing priorities that reduce focus
        
        Inability to quickly make decisions or allocate needed resources
        
        Lack of support and authority to overcome obstacles
        
        Responsibilities:
        
        Roles and responsibilities were undefined.
        
        Project manager assigned after announcement, with full-time job.
        
        High turnover of key staff like sponsors.
        
        Stakeholders:
        
        •Customers
        
        •Staff
        
        •Board of directors
        
        •Rail Co Trust Board
        
        •Government
        
        A list of the individuals and groups who have an interest in or may be impacted by the project.
        
        Purpose:
        
        Formally launches the project:
        Provides authorization and framework to launch project:
        
        • Authorizes resources and work
        
        • Assigns roles and accountability, risks and measures
        
        • Gains stakeholder buy-in
        
        Outlines objectives, benefits, scope
        
        Specifies deliverables and constraints
        
        Complements business case by:
        Giving go-ahead for work to begin
        
        • Documents project requirements for:
        
        Approval
        
        Planning
        
        Implementation
        
        • Bridges gap between:
        Idea (in business case)
        Execution (project plan)
        
        • Provides basis for next planning stages:
        
        Scope management
        
        Time management
        
        Cost management
        
        Quality management
        
        etc.
        
        In summary, a PID specifying objectives, scope, constraints, roles and resources clearly from the start would have aligned expectations, assigned accountability, documented agreements to prevent confusion and ensured required inputs were available. This would have improved management and likely outcomes for future projects.
        
        A Project Initiation Document provides clarity around:
        
        Objectives: Clearly outlining project vs. business objectives ensures alignment and accountability.
        
        Scope: Formally documenting all scope details prevents scope creep and disagreements.
        
        Constraints: Explicitly defining constraints up front facilitates compliance.
        
        Sponsor role: Formalizing sponsor responsibilities prevents lack of direction.
        
        Resources: Identifying required resources ensures appropriate inputs are available.
        
        confusion around objectives, scope and ownership suggest a formal PID could have improved management
        
        While business case focuses on:
        Establishing need for project
        
        Benefits:
        
        Project: Online Ticketing System
        
        •Reduce ticketless travel
        
        •Improve revenues and profits
        
        •Increase customer satisfaction and loyalty
        
        •Enable customer data collection for marketing
        
        •Lower marketing costs
        
        •Adopt targeted marketing approach
        
        Risks:
        
        •Cost overruns
        
        •Delays
        
        •Lack of customer usage or satisfaction
        
        •Security breaches
        
        A summary of potential issues, challenges or threats that could impact the project, along with initial responses to mitigate these risks.
        
        Gateways and performance measures (updated regularly)
        
        •Tickets sold online
        
        •Repeat online purchases
        
        •Reduction in fraud
        
        •Customer accounts created
        
        •Revenue growth
        
        outline the specific metrics that will be used to track and evaluate project performance and success. This could include things like:
        
        Timeliness (adherence to schedule)
        
        Budget compliance
        
        Quality standards met
        
        Outcomes achieved
        
        Customer satisfaction metrics
        
        Productivity gains
        
        Business benefits realized
        
        Scope:
        
        Preliminary work outline
        
        A high-level outline of what is and is not included in the scope of the project. More detailed scope statements come later in the planning process.
        
        •Extend website to include online booking and customer contact
        •Create customer database for CRM and marketing
        
        Project scope (background, dates, costs, scope): Outline the broad context and boundaries of the project to ensure focus and manage scope creep. This is especially important given the marketing objectives and budget constraints.
        
        Scope:
        
        Documenting all scope changes related to quality would have resolved confusion, rather than relying on undocumented agreements. Formal sign-offs prevent misunderstandings.
        
        Scope: Documenting all scope changes, especially around quality, through formal sign-offs would have resolved confusion and prevented disputes.
        
        Scope - The scope has widened from a technical traffic light system to a broader initiative including policies to boost bus services and reduce car use through parking fees and restrictions. The exact revised scope must be confirmed with the new sponsor.
        
        Scope:
        Scope was poorly defined initially.
        Changes to design scope led to delays and cost overruns.
        
        Deliverables:
        
        •Fully operational online ticket sales within 12 months
        
        A list of the major outputs or outcomes that the project will produce. These serve as measures of project success.
        
        •Resources
        
        outsource system development
        
        A preliminary list of the people, equipment, materials, facilities, etc. that will be required to complete the project. Budget estimates may also be included.
        
        Budget:
        
        Initial funding
        
        •Funding - Require cost/benefit analysis
        
        Budget:
        Budget was set but may not have been documented.
        New COO was unaware of budget.
        
        Resources:
        
        Identifying all required resources, like disability access expertise, would have ensured they were available rather than relying on contractors' initiative. Substitutes should be defined for unavailable resources.
        
        Resources: Identifying all required resources, like disability access expertise, would have ensured appropriate inputs were available rather than relying on contractors to improvise.
        
        Resources - Once the revised scope is set, resources must be allocated to the new and potentially expanded set of tasks needed to complete the project.
        
        Key factors to review:
        Resources: Identify people and equipment allocated, assess sufficiency.
        
        Approach:
        
        A high-level overview of how the project work will be carried out, divided into key phases or stages.
        
        Constraints:
        
        Any limits or restrictions that frame how the project can be implemented, like budget, timeline, technical or external factors.
        
        Constraints (time, cost, quality): Prioritize key limitations upfront to make trade-offs and make the specified dates and required quality levels. The health and safety quality aspect is important given the nature of the event.
        
        Constraints: Explicitly outlining all constraints upfront regarding labor/sourcing requirements would have ensured compliance rather than causing tension later.
        
        Constraints:
        
        Schedule - The project manager must assess if the original delivery date is still feasible given the revised objectives, scope and resource needs.
        
        If not, the project manager must negotiate either:
        
        Reducing the scope
        
        Increasing resources
        
        A combination of both
        
        with the new sponsor to meet the schedule constraint.
        
        •Authorization:
        
        Signed by stakeholders
        
        Sign-off from key stakeholders formally approving and launching the project based on the parameters in the PID.
        
        Authority: Formally defining sponsor responsibilities would have held the sponsor accountable for promoting and signing off the project. The unfocused approach of the changing sponsor caused issues.
        
        In summary, fundamental changes are needed to the project objectives, scope, resources and schedule due to the shift in priorities and expansion under the new mayor's vision. The project terms of reference must be extensively revised and re-approved by the new sponsor to reflect this new direction.
        
        Use of a PID:
        
        Provides guidance on what is expected, when and at what level of performance
        
        Contains detailed plans like Gantt charts and risk control plans
        
        Clarifies roles and responsibilities
        
        Is revised and updated throughout the project life
        
        Potential issue:
        Updating the PID can move it away from the original objectives
        Requires benefits management to stay on track
      - • Definition:
        
        project defined
        
        resources committed: Integrating resources to meet goals
    - - goals
      - schedules
      - resource plans set
      - Planning: Specifying constraints, appointing a full-time project manager and team, and developing quantifiable objectives are all part of the planning stage.
      - The key plans that are usually produced after the PID include:
        
        1. Project scope statement: elaborates on the initial scope outlined in the PID by defining in detail what will and won't be included in the project; assign ownership of specific tasks and subtasks.
        
        2. Project schedule: A more detailed timeline is created that breaks down the overall project schedule into individual tasks and milestones, with start and finish dates assigned. Use tools like networks or Gantt charts.
        
        3. Project budget: A more precise budget is developed that defines the funding required for each part of the project. This budget builds on the initial estimates provided in the PID.
        
        4. Resource plan: Resources like human, physical and financial resources are identified and allocated to the specific tasks and deliverables in the project schedule. The resource plan ensures the project has the means to accomplish its work.
        Staff Planning - Determining staff roles (3):
        Should be in the project plan, after approval.
        
        5. Risk management plan: Potential risks are identified and plans are put in place to mitigate, transfer, accept or control those risks.
        
        6. Communication plan: A plan for communicating project information to stakeholders throughout the project lifecycle is created to keep everyone informed and aligned.
        
        Quality standards: Establish external (e.g. regulatory) and internal quality criteria for each deliverable. This ensures high quality outcomes that meet expectations.
        
        Evaluation metrics: Clearly define how success will be measured. For example, this could be based on increased sales, brand awareness or other KPIs relevant to objectives. Measurement drives accountability.
      - The procurement process involves:
        
        Defining requirements - This occurs early in the planning stage as the project team identifies what they need to procure.
        Identifying options - The team researches potential vendors and solutions, usually by issuing requests for information (RFIs). This also occurs during planning.
        
        The key issues were:
        
        Eurotek was chosen before requirements were defined, indicating a flawed selection process.
        
        Solution: Define requirements before selecting a technology solution.
        
        The software was a poor fit, requiring costly customization that threatened the project.
        
        Solution: More transparent selection involving multiple vendors could have identified a better solution.
    - - Execution: Identifying and resolving potential issues early helps ensure the project stays on track during execution.
      - The procurement process involves:
        
        Selecting a vendor - Based on the evaluation, a vendor is selected and a contract or purchase order is issued. Also part of executing.
        
        Monitoring performance - Once the vendor is onboard, their performance is monitored to ensure they deliver to requirements. This continuous monitoring occurs throughout most of the executing stage.
        
        Evaluating options - Once options are identified, the team evaluates them against the requirements. This begins the executing stage.
      - Making changes to achieve benefits (5):
        Belongs in project execution.
    - - monitoring costs, schedules, performance: Managing trade-offs between performance, time and cost
      - • The 'triple constraints' are:
        limit every project
        
        • Scope:
        
        •- Software package scope is predefined
        
        • - Product scope at launch may be limited
        
        all deliverables defining success linked to quality/ refers to deliverables, specifications and requirements
        
        • - Time: delivery/project deadline
        
        •- Implementation date is desirable but not critical
        
        • - Launch date is fixed so time is a constraint
        
        Scheduling - Subcontractors often have their own schedules that may not align well with the master project schedule. Coordinating schedules can be challenging. Facing time overruns due to extensive subcontracting
        
        Key factors to review:
        Time: Check progress reports, determine if on target for deadline.
        
        • - Cost: authorized spend/ budget allocated
        
        • - Budget is fixed so cost is a constraint
        
        • - Extra funds should be available for successful launch
        
        Disputes - There are often contractual and financial disputes (Budget 'creep' and cost control issues) between the primary contractor and subcontractors, which can delay projects.
        
        It can be difficult to control budgets in large projects
        
        Key factors to review:
        Costs: Compare actual to original budget, estimate further costs.
        
        • Quality
        
        • - Quality should be good as it's a popular solution
        
        • - Quality issues may not be solved
        
        • - Key functionality must be demonstrated
        
        is also important and some include it as a fourth constraint
        
        Quality issues - The primary contractor has less visibility into and control over the subcontractors' work. This can lead to quality issues and rework.
        
        Key factors to review:
        Quality: Check if quality standards set for stages, assess compliance.
      - Monitoring and Control: Benefits realization and post-project reviews are part of monitoring progress and controlling the project to stay within scope and budget.
      - Reviewing progress against measures (1):
        Should be part of project control to determine if corrective action is needed.
      - difficulties in maintaining internal controls
        when working with subcontractors
        
        A subcontractor
        
        is a company or individual that signs a contract to perform part of the work that a main contractor has agreed to perform.
        
        Subcontractors work for and are paid by the primary contractor, not the project owner.
    - - project conclusion
      - resource release
      - Closing: Lessons learned from the post-project review can be applied to future projects, closing the loop and improving the organization's project management process.
    - - So in summary, these elements highlight the importance of thorough planning, issue management during execution, monitoring progress, and learning from the project to improve future projects. They touch on key stages throughout the project life cycle.
  - - - The work is carried out by a team of people, often from varied work and social backgrounds.
      - The team must ‘gel’ quickly and be able to communicate effectively with each other.
    - - There is normally no benefit until the work is finished.
      - The lead-in time to this can cause a strain on the eventual recipient who is also faced with increasing expenditure for no immediate benefit.
  - - - Cost overruns make the project unfeasible
      - Schedule delays make the project no longer viable
      - Objectives or requirements change, making the project unnecessary
      - Technology or market changes reduce the value of the project
      - Vendors are unable to deliver as needed
      - Stakeholder priorities shift and support for the project wanes
    - - Negotiate - Try to negotiate cost reductions, more flexible terms or royalty models with vendors before fully cancelling. Vendors may be willing to compromise to save the business.
      - Consider alternatives - Evaluate alternative vendors or options that could still meet the objectives at a feasible cost. Cancelling an existing contract may be necessary.
      - Conduct a post-mortem - Perform a thorough review and document lessons learned from the project. This ensures insights don't get lost.
      - Recover costs - Seek to recover as much of the project costs as possible from vendors through negotiations, contract clauses or legal means.
      - Communicate formally - Formally announce the project cancellation to all stakeholders in a transparent manner. Avoid rumors.
      - Reassign resources - Reassign project resources to other necessary work. Avoid having people left idle with no direction.
      - Update documentation - Update any impacted procedures, budgets, charters and plans to reflect the project cancellation.
      - Implement learnings - Use lessons learned from the failed project to improve processes for future success. Make any needed changes.
      - Inform management - Ensure senior leaders and oversight bodies are informed of the project cancellation, reasons why and next steps.
      - Mark as cancelled - Officially mark the project as "cancelled" in all relevant records and budgets to avoid confusion.
- - - - Identification:
        
        Here are the key things to do in the benefit identification stage:
        
        Classify benefits - Categorize them as tangible/financial or intangible/non-financial.
        
        Measurement:
        By determining what can be:
        
        Quantifiable:
        
        •Impacts can be estimated before project:
        
        Productivity and operational benefits often fall here
        
        Measured objectively
        
        Quantifiable - Benefits can be reliably forecast.
        
        Example:
        
        3 more items...
        
        Defines a quantifiable benefit as one where:
        
        3 more items...
        
        Says energy savings appear to be a quantifiable benefit because:
        
        3 more items...
        
        Concludes this provides a good basis for predicting the energy savings, although:
        
        The actual savings won't be known until after implementation
        
        an outline of the ideas and steps in the examiner's evaluation:
        
        7 more items...
        
        Financial:
        
        •Benefits can be assigned monetary value:
        
        Cost reductions
        
        Revenue increases
        
        Financial - Quantified benefits tied to financial value.
        
        Example:
        
        Car park sale proceeds
        
        Increased car park income
        
        STEP 1: Classify benefits as financial, quantifiable, intangible, etc. based on definition
        
        2 more items...
        
        STEP 2: Assesses whether specific benefits fall into the relevant category:
        
        4 more items...
        
        STEP 3: Consider factors that could impact the:
        
        3 more items...
        
        FINAL STEP: Conclude on the quantifiability and predictability of the benefit
        
        Aim:
        
        Demonstrates value to stakeholders
        
        Informs benefit management
        
        •Valuing benefits at higher levels:
        Improves business case and feasibility analysis
        
        Issues:
        
        •Managers may overstate benefits to obtain approval:
        
        inflate appeal of business case
        
        inflate perceived project feasibility
        
        • Manager has overstated financial benefits:
        Excluding unrealistic figures, net benefit is:
        $60,000 cost (savings from redundancy minus project costs)
        
        Observable:
        
        Example:
        
        4 more items...
        
        Clarifies the term "observable benefits"
        
        9 more items...
        
        Suggests using clear criteria and independent assessment to evaluate such benefits, for example by surveying staff morale before and after the new centre opens.
        
        Evaluation:
        
        2 more items...
        
        Measurable:
        
        Example:
        
        5 more items...
        
        Assess the ability to credibly estimate the actual improvement
        
        3 more items...
        
        Clarifies that a measurable benefit is one where
        
        6 more items...
        
        Intangible costs and benefits that are difficult to credibly estimate in advance:
        -Disruption costs (intangible costs difficult to predict)
        
        Increased student numbers (difficult to credibly estimate improvement)
        
        1 more item...
        
        •Benefits range from observable to financial
        Financial/Quantifiable benefits are more concrete
        while Measurable/Observable benefits are softer and based more on estimates and judgment.
        
        Assign benefit owners and measures.
        
        Set baseline performance.
        
        Create realization plan.
        
        For Tailia College:
        
        Measures would be set for benefits like enrollment growth.
        
        Examples:
        
        •Increased revenue:
        
        3 more items...
        
        Irrelevant claims:
        unsuitable for inclusion in the cost-benefit appraisal.
        
        • Economies of scale:
        
        3 more items...
        
        • increasing student numbers
        as a result of the restaurant initiative
        
        4 more items...
        
        Unplanned: Emerge as project progresses
        
        Planned: Identified at project outset
        
        Agree clear project objectives - Beyond just financial benefits, the objectives should capture all desired outcomes of the project.
        
        Ensure objectives align with organizational strategy - The benefits should support the higher-level goals of the business.
        
        Identify all potential benefits - Create a comprehensive list of all possible outcomes, both financial and non-financial.
        
        Assign benefit owners - Assign individuals responsible for delivering each benefit to keep focus.
        
        Determine success measures - Define how you will know if the benefits are realized.
        
        Establish baseline performance - Determine current performance levels to set improvement targets.
        
        Set desired performance levels - Specify how much improvement is expected from the benefits.
        
        Estimate benefit values - Try to assign quantitative or qualitative values to benefits where possible.
        
        Crucial for business case.
        
        Requires:
        
        Ownership - Identifying benefit owners.
        
        Measurement - How benefits will be tracked.
        
        Identify and structure objectives and benefits.
        
        Identifying:
        Defining and organizing project objectives and benefits.
        
        Structuring:
        Assigning benefit ownership.
        
        Purposes:
        
        This provides the foundation for realizing, tracking and maximizing benefits over the project lifecycle.
        
        Without properly identifying and structuring benefits up front, an organization risks not fully capturing the potential value from a project.
        
        For Tailia College:
        
        Objectives would be clarified beyond just revenue/enrollment.
        
        Benefit owners would focus on delivering specific benefits.
      - Execution:
        
        Execute benefits/ benefits realization plan.
        
        Implement plan and resolve issues.
        
        For Tailia College:
        Plans would identify enablers and limiters of benefits.
        Problems would be resolved along the way.
        
        Here are the key things to do in the benefits plan execution stage:
        
        Assign an overall benefits manager - Someone responsible for overseeing the full benefits plan and benefit owners.
        
        Communicate the benefits plan - Ensure all stakeholders understand their part in delivering benefits. Remove any confusion.
        
        Track benefit milestones - Monitor progress against interim benefit targets to flag issues early.
        
        Provide support to benefit owners - Help owners resolve barriers within their control or escalate issues that need executive attention.
        
        Adjust plans as needed - Make changes to benefit delivery approaches as barriers emerge or circumstances change.
        
        Challenge benefit owners - Hold owners accountable for delivering their assigned benefits. Push for results.
        
        Escalate major issues - Raise major benefit delivery problems that cannot be resolved at the benefit owner level to executives for resolution.
        
        Reassign benefit owners - Replace owners who are not delivering assigned benefits with more capable individuals.
        
        •Late allocation of full-time administrators
        
        Administrators were part-time at first, hampering progress
        -Software delivered 2 months late
        -Lesson: Deadlines will likely slip without full-time employees allocated
        
        The key goal in this execution stage is to actually operationalize the benefits plan through strong governance, active issue resolution, plan adaptability and accountability. The focus shifts from identifying and planning benefits to delivering benefits through effective coordination, communication and challenge.
      - Review:
        
        Review and evaluate results against plans.
        
        Monitoring:
        Track progress and adjust plans.
        
        Evaluation:
        Formally assess benefits realized.
        
        For Tailia College:
        Results would be formally evaluated after project completion.
        
        the key things to do in this stage are:
        
        Conduct a formal benefit review - After the benefits realization plan has been executed, perform a structured review to assess actual benefit delivery.
        
        Compare benefits delivered to planned benefits - Determine any gaps between what was intended and what was actually achieved.
        
        Identify reasons for benefit shortfalls - Analyze why certain benefits were not fully realized to learn lessons for the future.
        
        Capture lessons learned - Document insights around what worked well and what challenges emerged in benefit delivery.
        
        Update benefit register - Record actual benefits achieved to update the benefit log maintained earlier.
        
        Recommend benefit improvements - Suggest changes to approach, processes, tools, etc. to better realize benefits in the future.
        
        Obtain stakeholder feedback - Survey benefit owners and impacted parties to collect their perspectives on benefit delivery.
        
        Report results to executives - Communicate overall performance around benefit delivery to senior leaders.
        
        The key outcome of this stage is an objective, evidence-based assessment of how well the identified benefits were actually realized due to the project. This helps the organization learn valuable lessons to improve future benefit management practices.
      - Improvement:
        
        Establish/Identify potential for further benefits.
        
        For Tailia College:
        Potential for additional benefits could be uncovered.
      - By going through these stages, an organization can work to maximize the full potential of value from a project.
      - Planning: Plan benefits realization. How to realize planned benefits.
        
        Here are the key things to do in the benefit realization planning stage:
        
        Create a benefits dependency network - Map how investment objectives enable specific benefits, and how benefits depend on each other. This shows the cause-and-effect relationships.
        
        Assign benefit owners
        
        Ensure clear accountability for delivering each benefit. These owners should track progress and resolve issues.
        
        A benefit owner is someone responsible for defining, agreeing and delivering a defined benefit in the business case.
        Explain that benefit owners, not project managers, are ultimately responsible for benefit realization
        The project manager is unlikely to be the benefit owner - their responsibility is delivering the project, not operationalizing the outcome.
        
        Without benefit owners, benefits are unlikely to materialize.
        Many projects that promise cost savings fail to deliver them because no one had responsibility for actually achieving the savings.
        
        Recommend appointing a benefit owner for specific benefits
        
        It is important for the IIA to appoint a benefit owner for the administrative cost reductions.
        
        A benefits map
        
        The map can also show how benefits relate to organizational objectives.
        
        Benefits may require business and enabling changes to be put in place first.
        
        The benefits map shows exactly what must be done to actually deliver the promised benefit.
        
        helps the benefit owner determine what must be put in place to deliver the promised benefit.
        
        Importance of benefit owners
        
        A benefit owner is responsible for defining, agreeing and delivering a defined benefit
        
        Without benefit owners, benefits are unlikely to materialize
        
        The benefit owner should have authority to make decisions that help deliver benefits
        
        Many projects fail to achieve benefits because no one had responsibility for achieving them
        
        It is important for the IIA to appoint a benefit owner for the cost reductions
        
        How this ultimately leads to the realization of actual benefits
        
        Benefits maps outline exactly what must be done to actually deliver promised benefits
        
        Projects managers deliver projects, but benefit owners operationalize the outcomes
        
        Identify potential barriers - Anticipate any people, process or system issues that could prevent expected benefits from materializing.
        
        Develop enabling changes - Propose changes to address barriers and better position the organization to capture intended benefits.
        
        Establish benefit milestones - Set interim performance targets to track benefit realization over time. This provides checkpoints and clarity around timelines.
        
        Create a benefit register - Maintain a log of all identified benefits, owners, milestones and current status. Update this regularly.
        
        Define responsibility - Clarify who is accountable for planning, tracking and resolving issues around benefit delivery.
        
        Establish an escalation process - Create a routine (e.g. monthly meetings) to raise issues that benefit owners cannot resolve themselves.
        
        The key goal of benefit realization planning is to anticipate and prepare for challenges in benefit delivery, enable changes to address these, and establish systems to track progress, flag issues early and resolve them quickly. This dramatically improves the chances of fully materializing the benefits envisioned for the project.
        
        Benefits realization is a post-implementation activity that:
        
        Compares actual delivered benefits and costs to what was forecast in the business case
        
        Is a key role for benefit owners
        
        Due to the annual delivery of benefits, benefits realization should be:
        
        A series of reviews, not just a one-time check
        
        The objective of benefits realization reviews is to:
        
        Determine which benefits have been delivered
        
        Identify benefits that have not been delivered
        
        Investigate reasons for under-delivery
        
        Take remedial action where needed
        
        Consider any unanticipated benefits that emerged
        
        Lessons learned are fed back to improve benefits management over time.
        
        It can be difficult to isolate the exact causes of benefits after time has passed, e.g.:
        Increased student numbers may be due to the new system but also many other factors
        
        However, benefits realization is still worthwhile because:
        Someone must have ongoing responsibility for achieving promised benefits that justified the investment
    - - Enhance benefits identification and realization.
      - Maximize project outcomes.
      - Reduce non-value adding activities.
      - benefits management ensures:
        
        Complete benefits are defined upfront.
        
        Plans are made to realize benefits.
        
        Issues are addressed during execution.
        
        Actual benefits are formally evaluated.
        
        Further benefit opportunities are identified.
      - This process helps organizations maximize the full value and outcomes from their projects.
  - - - •Hardware/software costs included properly - Strength
        
        The weaknesses are:
        
        • Food costs (80% of revenue) not included - Weakness
        
        •Unclear if maintenance fee will increase - Weakness
        
        •Difficult to accurately forecast energy costs - Weakness
        
        •No allowance for increasing energy prices - Weakness
        
        •Forecast based on single year - Weakness
        
        The main weaknesses are the omission of some key costs like food costs, uncertainty around cost increases over time for maintenance fees and energy, and forecasts that may not be accurate enough.
        
        The staffing costs also appear to have room for improvement to be managed more efficiently.
        
        •Staff overtime necessary but duties could be rescheduled - Area for improvement
        
        •10% pay increase in Y3 seems excessive without hours increase - Area for improvement
    - - Capital costs are "one-time" investments that enable future benefits
      - Operating costs are ongoing and must be covered by those benefits
      - Implementation costs bridge the gap between current and future state
  - - - Profit as % of investment
      - Speed of investment recovery
      - Discounted cash flow surplus
      - Breakeven discount rate
    - - Profitability:
        Accounting Rate of Return (1):
        Average annual profit as % of average investment.
      - Liquidity:
        
        Payback Period (2):
        
        Years to recoup initial investment from cash flows.
        
        Payback Method Critique:
        
        Ignores cash flows after payback.
        
        Excludes time value of money and risk.
        
        Should use NPV or discounted payback instead.
        
        Simple payback determines cumulative net cash flows and point payback is achieved.
        
        Payback here is 2 years, suggesting the project is viable.
        
        Advantages:
        
        Easy to understand
        
        Ensures funds invested are repaid quickly
        
        Disadvantages:
        
        Ignores future cash flows after payback
        
        Doesn't consider time value / risk of money
        
        Mitigations:
        Use discounted payback or net present value to include time value and risk
        
        Omissions:
        
        Only includes actual cash flows, not non-cash expenses like depreciation
        
        Improvements:
        
        Calculate return on investment for a clearer financial picture, though that also has limitations
        
        ie. Doesn't consider - •Project risk •Qualitative factors •Timing of cash flows & Focuses only on - Past investments, Not future growth potential
        
        Return on investment is the only technique that includes depreciation, since it incorporates the project's depreciable assets in the denominator of the ROI ratio.
        
        So on its own, none of these techniques provide a full assessment of a project's viability.
        
        for example, seeing that both simple payback and ROI metrics meet the required thresholds - we gain more confidence in the feasibility of the project.
        
        An optimized analysis would likely combine both cash flow-based methods and return-based metrics like ROI.
        
        together they can give a rough approximation of a project's viability that considers:
        
        Speed of investment recovery
        
        Time value of money
        
        Risk adjustment
        
        Depreciation / profitability
        
        Both financial and intangible benefits must be considered to fully evaluate the initiative.
        
        For Andrew's purposes:
        
        •Even with net cash outflow,
        Project can be justified by...
        
        •Enhancing student performance
        
        •Achieving educational goals
        
        •Fulfilling the college's mission
        
        :<3:
        
        So for Andrew, the project's ability
        
        To realizing non-financial objectives
        
        May be reason enough to proceed,
        
        Beyond any financial return metrics.
        
        Financial measures alone may not justify the project if non-financial benefits exist
        
        :red_flag:
        
        Financial measures alone cannot capture
        
        The full value the restaurant may provide.
        
        Qualitative factors like learning outcomes
        
        and student experiences matter greatly too.
      - Net Present Value (3):
        
        Sum of discounted future cash flows.
        
        Questions the chosen discount rate and basis:
        
        Little information provided about how it was selected
        
        Suggests it may have been set artificially low to produce a positive NPV
        
        Questions the 7-year duration of the investment appraisal:
        
        3 to 5 years are more common
        
        Basis for 7 years needs to be investigated and confirmed
        
        Recommends performing sensitivity analysis:
        
        A small change in initial software cost could make the NPV negative
        
        This shows the financial viability is sensitive to assumptions
        
        Recommend performing sensitivity analysis to test the impact of key assumptions
        Some key assumptions to test in sensitivity analysis for NPV calculations include:
        
        Revenue projections: Changes to the assumed revenue from the project over time can significantly impact NPV. Testing sensitivity to revenue is important.
        
        Cost projections: Just like revenue, changes to the projected costs and expenses over the lifetime of the project can have a big impact on NPV. Cost inputs should be sensitivity tested.
        
        Discount rate: As the examiner noted, the discount rate is a key assumption that can dramatically change NPV results. Testing sensitivity to the discount rate is critical.
        
        Project life: The number of years the project is expected to generate benefits impacts NPV. Sensitivity to the assumed project duration should be tested.
        
        Timing of cash flows: The timing of when costs are incurred and benefits are realized can impact NPV. Sensitivity to changes in the phasing of cash flows is important.
        
        Tax rate: For projects involving tax considerations, the applicable tax rate is a key assumption that should be sensitivity tested.
        
        Initial investment: As the examiner noted, sensitivity to changes in the initial investment cost can significantly impact NPV and viability. This should always be tested.
        
        Note that the current result (positive/negative NPV) is based on questionable assumptions
        
        Suggest recalculating the financial viability with different assumptions to verify the result
        
        Conclude whether the project is likely to actually be financially viable based on:
        
        Realistic discount rate
        
        Appropriate project duration
        
        Sensitive assumptions tested
        
        Overall, critically evaluate:
        
        Key assumptions underlying the financial calculations
        
        Sensitivity of the results to changes in those assumptions
        
        Likelihood that the actual assumptions will differ from those used
        
        Robustness of the conclusion on financial viability
      - Internal Rate of Return (4):
        Discount rate that yields NPV of zero.
- - - - Contents:
        
        Detailed plan:
        
        Gantt chart
        (or diagram to illustrate phasing)
        
        A graphic tool used within the project plan
        
        It relies on the WBS and budget.
        
        Does not clearly show interrelationships between activities
        
        Can show actual vs planned time
        
        Shows resource deployment over time
        
        Network analysis/critical path:
        Phasing of work and dependencies
        
        Ensures project is completed in minimum time
        
        Identifies tasks on the critical path
        
        Delays to these tasks delay whole project
        
        Can assist in allocating resources
        
        Another technique used within the project plan to identify the shortest duration for the project.
        
        It identifies tasks on the critical path that must go according to plan.
        
        The WBS and budget inform this technique.
        
        Project deliverables and due dates
        
        Product/Work breakdown structure (WBS)
        
        Fundamental to project planning and control
        
        A technique used within the project plan
        
        Breaks work down into manageable components
        
        Project budget:
        
        The WBS and other planning techniques help determine the budget.
        
        Allocates amount and distribution of resources
        Can be established top-down or bottom-up
        
        Evaluation plan:
        
        Lists factors, questions, and methods for evaluating:
        
        Quality of outputs
        
        Success of the project
        
        How success will be measured
        
        Dissemination plan:
        
        Explains how outcomes and learning will be shared with stakeholders
        
        Lists key dissemination activities with:
        
        Purpose
        
        Target audience
        
        Timing
        
        Key message
        
        Exit plan:
        
        Explains what will happen to project outputs at the end, including:
        
        Knowledge
        
        Learning
        
        Focuses on ensuring outputs are taken up by owners
        
        Covers work needed for project close down, such as:
        
        Preservation
        
        Maintenance
        
        Documentation
        
        Sustainability plan:
        
        Lists any outputs with potential to continue after the project ends
        
        Explains why and how they might be taken forward
        
        Identifies issues to make them sustainable long term
        
        Background information:
        
        Summary of the project background and need
        
        Aims and objectives:
        
        The broad aim and specific objectives of the project
        
        Overall approach:
        
        The overall strategy, methodology and work structure
        
        Important issues to address and scope/boundaries
        
        Link to critical success factors
        
        Project outputs:
        
        Tangible deliverables and reports
        
        Intangible outcomes and changes stimulated
        
        Stakeholder analysis:
        
        Key stakeholders mapped using a power-interest matrix
        
        Assessment of their importance
        
        Risk analysis:
        
        Identification and assessment of risks to the project's success
        
        Plans to manage or mitigate risks
        
        Standards:
        
        Standards the project will comply with
        
        Project resources:
        
        Project partners
        
        Project management framework including: organization, reporting, decisions, local committee role
        
        Intellectual property:
        
        Ownership of IP created
        
        Use of third-party IP
        
        Permissions and implications after the project ends
      - The importance of a project plan:
        
        A project plan aims to achieve objectives within constraints of: Quality Cost Time
        
        Helps to communicate, plan, measure and clarify requirements
        Helps determine feasibility of targets
        
        The overall plan that outlines the entire project.
        
        Used as a reference tool for managing the project
        
        The detailed plan for resources, timings and targets for the project
        
        Produced alongside the business case in a PID
        But is updated regularly to reflect changes
      - A Project Initiation Document (PID) is related to the project plan in the following ways:
        
        • Contains the initial project plan and business case at project start
        
        • Is updated regularly as the project plan within it is revised to reflect changes and updates throughout the project life cycle
        
        • Serves as the "living" planning document that evolves along with the project plan over time
    - - Shows resource requirements, usage and availability over time
        Some organizations show resource availability on a separate line/bar
      - A tool used within the project plan
      - It relies on the WBS, budget and network analysis.
- - - - Faults and omissions in the software
      - Order amendment facility omitted
      - Incompatibility with some browsers
      - Lesson: Test across multiple environments and browsers
    - - Faults in the documentation
      - PDF manual was inappropriate
      - Poor distribution of manual electronically
      - Lesson: Inspect and test documentation before release
    - - Training of employees was inadequate
      - No formal training was provided
      - Missed opportunity to identify software issues earlier
      - Lesson: Training helps identify issues and build rapport with users
    - - Software was not properly tested
      - Tested by HomeDeliver employees in a controlled environment
      - Not tested by actual end users
      - Lesson: End users should perform acceptance testing
  - - - Gateways:
        
        Project review points where criteria must be met to pass to the next stage
        Gateways act as checkpoints to verify that progress is sufficient based on the progress report information.
        
        Used at key decision points like awarding contracts or going live
        
        Aim to prevent scope creep by controlling changes to the scope
      - Progress reports:
        
        Show the current status of the project compared to planned status
        
        Should monitor progress towards key milestones
        
        i.e. completion of major deliverables
        
        They provide visibility into how the project is progressing between gateways.
        Progress reports show how far the project has come since the last gateway and how much further it has to go before the next one.
      - Gateways and progress reports work together as part of an overall project control system.
      - expenditure and cost performance
        
        1.Establishing budgets:
        
        Budgets are set at the start to establish cost baselines
        
        Controlling expenditures:
        
        Procurement, design and development decisions are assessed for their budget impact
        
        A robust tender process is needed to control costs
        
        Actual expenditures will be compared to a baseline, and any variances will be reported to management for corrective action
        
        Cost performance metrics:
        
        Budgeted Cost of Work Performed (BCWP): The budgeted cost for work actually completed
        
        Actual Cost of Work Performed (ACWP): The actual cost for work completed
        
        Cost Variance: The difference between BCWP and ACWP
        
        Cost Performance Index:
        
        The ratio of BCWP to ACWP, showing cost efficiency
        
        Early on, metrics are unreliable due to insufficient data
        
        Later, metrics can be used to 'extrapolate the cost to complete' the project
        
        Steps:
        
        Calculate the BCWP/ACWP cost performance index (CPI) at a specific point in the project. Let's say at 30% complete, the CPI is 0.9, meaning costs are overrunning the planned costs.
        
        Monitor the CPI trend over time. Is the CPI getting better or worse? Continuing the example, let's say at 50% complete the CPI has deteriorated to 0.85.
        
        Assume the CPI trend will continue for the remainder of the project. So if at 50% complete the CPI is 0.85, we can assume for the next 50% of work the CPI will also be around 0.85.
        
        Use the CPI trend to calculate an estimated ACWP for the remaining work. Take the budgeted cost for the remaining work (BCWP), and divide it by the projected CPI.
        
        For example:
        
        If BCWP remaining is $1,000,000 and we assume a CPI of 0.85 continues:
        
        $1,000,000 / 0.85 = $1,176,470
        
        So the estimated ACWP (actual cost) to complete the remaining work would be $1,176,470.
        
        Add this estimated ACWP to complete to the actual costs incurred to date to get an estimate for the total cost at completion.
        
        This relies on some key assumptions:
        
        The CPI trend will continue
        
        No major changes or events occur to impact costs
        
        The projection is just an estimate, not an exact science
      - Schedule and time performance
        
        Schedule performance metrics:
        
        Schedule variance measures how much work was achieved vs. what was scheduled
        
        Schedule (time) performance – refers to the timely completion of project deliverables as compared to a baseline schedule defined in the project plan.
        
        Importance of schedule:
        
        Meeting timelines is important to meet the market window and achieve ROI (ROI = (Gain from Investment - Cost of Investment) / Cost of Investment)
        
        Schedule slippage avoided = key objective
        
        Schedule plan:
        
        Identifies all project stages, phases and assigned activities
        
        Maps tasks to a timeline with key milestones
        
        Milestones track work progress
        
        Here are some key milestones that are typically included in a project schedule:
        
        • Project initiation - Officially kick off the project with things like planning meetings, budget approvals, resource allocations, etc.
        
        • Requirements definition - Finalize and approve the product or service specifications and functionality.
        
        • Design completion - Finish the overall design of the product, system, or solution.
        
        • Prototype ready - Have an initial working version or prototype that can be tested and evaluated.
        
        • Development completed - Finish building/developing the product, system or solution according to the design.
        
        • Testing and quality assurance - Conduct testing to verify quality, functionality and performance meet requirements. Fix any issues found.
        
        • Pilot launch - Do a trial or limited launch as a "pilot" before full production release. Allows issues to be identified and fixed before a full launch.
        
        • Commercial/full launch - Officially launch the product, service or system for general use and to customers.
        
        • Post implementation review - Conduct a review after initial launch to identify lessons learned and areas for improvement in future projects.
        
        • Knowledge transfer - Share knowledge gained in the project with the relevant teams and broader organization.
        
        • Project closeout - Officially end the project by completing final administrative tasks, archiving documents, and releasing resources for other projects.
        
        Here are some example key milestones for:
        
        Creating a product:
        
        Product concept finalized
        
        Product design completed
        
        Prototype developed
        
        Production tooling ready
        
        Pilot production run completed
        
        Product launch
        
        Implementing a process change:
        
        Developing a software system:
        
        Requirements gathering completed
        
        Design specifications finalized
        
        Development environment set up
        
        Alpha code version ready
        
        Beta testing completed
        
        Code debugged and finalized
        
        User acceptance testing passed
        
        Training materials developed
        
        Software deployed to production
        
        Post launch issues tracking initiated
        
        For each type of project, the milestones tend to follow a similar pattern:
        
        Definition and design phase milestones
        
        Development phase milestones like prototype/pilot ready
        
        Testing and launch milestones
        
        Post implementation review milestones
        
        But the details differ based on what's being created, changed, or developed.
        
        Definition and design phase milestones
        
        Development phase milestones like prototype/pilot ready
        
        Testing and launch milestones
        
        Post implementation review milestones
        
        Performance indicators:
        
        Recommends a KPI showing percentage of tasks completed
        
        Notes the need to record planned time for each activity
        
        This provides a more accurate measure of progress
      - Quality performance and review
        
        Cost of quality:
        
        Money spent to fix poor quality design, development and work
        Includes labor, materials and other costs of rework
        
        Monitoring quality:
        
        Quality is reviewed and tested through inspections and reviews
        
        Quality review:
        
        Physical inspections are conducted at the end of each renovation stage
        
        Inspections identify satisfactory and unsatisfactory aspects
        
        Rectification costs cover fixing poor quality work
        
        Purpose of review:
        
        Agrees what aspects are satisfactory and what problems remain
        
        Triggers immediate action to solve problems
      - Issue management performance:
        
        The identification and resolution of issues or problems impacting project delivery
        
        Types of issues:
        
        Communications issues: Coordinating subcontractor activities to avoid delays
        Human resource issues: Resolving conflicts between team members to avoid delays
        
        Purpose of issue management:
        
        Ensuring matters requiring resolution, decisions or direction are addressed promptly
        Avoiding negative consequences for project objectives and deliverables
        
        Example:
        During a software development project, a coding issue is discovered that impacts 2 of the scheduled deliverables.
        
        Issue management could include:
        
        The issue is documented in the issue tracking system within 1 day of discovery.
        
        A resolution plan is developed within 2 days, in coordination with the development team.
        
        A workaround is implemented within 4 days to minimize schedule impacts.
        
        The root cause is identified and a permanent fix is deployed within 1 week.
        
        Lessons learned are captured to prevent similar issues in future sprints.
      - Scope measures
        
        Scope measures track how well the project is meeting its scope requirements:
        
        • Product scope refers to the functions, features and characteristics of the end product or service being created.
        
        • Project scope refers to the work and tasks needed to deliver that product or service.
        
        Scope is measured by comparing:
        
        The baseline product or service specifications - the originally defined functions, features and requirements.
        
        The actual project deliverables - the work completed and outputs produced.
        
        Scope v. compliance
        
        Scope is in compliance when the deliverables match the baseline specifications.
        
        Scope is out of compliance when:
        
        Functions or features are missing from deliverables
        
        Extra functions or features are included that were not specified originally
        
        The product or service deviates from the defined characteristics.
        
        Here are some examples of scope measures in projects:
        
        Software development project:
        
        Product scope: The requirements specification defined 20 necessary features for the software.
        
        Project scope: Design and development of the software.
        
        Scope measure: After the initial developers testing, only 17 of the 20 defined features were fully functional. Scope compliance is 85%.
        
        Actions: The project manager works with the development team to prioritize the incomplete features and develop a plan to get the remaining 3 features implemented before the scheduled release date.
        
        Construction project:
        
        Product scope: The client requested a 2-story, 4000 square foot house with 4 bedrooms and 3 bathrooms.
        
        Project scope: Construction of the house to the agreed specifications.
        
        Scope measure: The blueprints, permits and initial construction show the house will be 3850 square feet with 3 bathrooms instead of 4.
        
        Actions: The project manager meets with the client and architect to determine if the smaller/fewer specifications meet the client's needs. The Client agrees and the scope document is updated to reflect the final product scope.
        
        Website redesign:
        
        Product scope: 25 pages, new navigation, updated graphics and photos.
        
        Project scope: Design, develop and deploy new website.
        
        Scope measure: The first full design draft includes 22 pages and partial new navigation.
        
        Actions: The project manager works with the design team to prioritize pages, reviews a revised navigation structure, and develops a plan to deliver the full scope before launch.
      - Functional Quality
        
        How well the end product or service performs its intended functions and meets requirements.
        
        Example:
        A new payroll software is launched. Functional quality measures could include:
        
        Percentage of paychecks correctly calculated and distributed on time
        
        Uptime percentage - the software is available for use as required
        
        Number of bugs reported by end users for features not working as intended
      - Technical Quality
        
        The performance and reliability of the technical infrastructure underlying a product or service.
        
        Example:
        A new company website goes live. Technical quality measures could include:
        
        Uptime percentage - how often the site is available for visitors
        
        Page load times - how quickly pages display
        
        Number of system errors that impact the user experience
      - Client Satisfaction Measures
        
        Metrics that indicate how satisfied the client is with the project, deliverables, and support.
        
        Example:
        After deploying a new CRM system, a client satisfaction survey is sent to end users.
        
        It contains questions like:
        
        How easy is the system to use?
        
        How quickly are issues resolved?
        
        How well does the system meet your needs?
        
        Users respond on a scale from 1 to 5. The results show:
        
        Ease of use: 3.8
        
        Issue resolution time: 3.2
        
        Meeting user needs: 4.1
        
        Actions are then taken to address areas of lower satisfaction, like issue resolution times. Faster response times and status updates are implemented.
  - - - Plan the risk management approach - Determine how much risk the project sponsor can tolerate and set the risk management strategy.
      - Identify and record risks - Identify all potential risks and document them in a risk register.
      - Assess the risks - Assess 2 aspects of each risk:
        
        The likelihood it will occur
        
        The consequences if it does occur
      - Plan risk responses - Choose how to respond to each risk using TARA:
        
        Avoidance
        
        Reduction
        
        Mitigation
        
        Transference
        
        Absorption/Acceptance
      - Implement risk management strategies - Carry out the planned responses.
      - Review risk management approach and actions - Check that the risk management is adequate and make changes if needed.
  - - - Coordinating people and resources
      - Integrating and performing project activities
      - Producing deliverables according to the project management plan
    - - Project teams often:
        
        Include members from different functions and divisions/ People with different skills working together in a coordinated way
        
        Require individuals/team members to have both functional responsibilities and project roles /dual reporting lines = Matrix structures
        
        Project teams that are formed specifically for a project and then disband
      - However, matrix structures are very common for projects that require:
        
        Resources from multiple departments or functions within an organization
        
        Experts from different skill sets to work together on an interdisciplinary team
      - Not every project team has a full matrix structure. Some project teams may be:
        
        Complete standalone teams with members dedicated solely to that project. In this case there are no matrix reporting lines.
        
        Drawn from a single function or department. While members still report to their usual managers, there are not multiple functions represented so it's not a true matrix structure.
      - advantages and disadvantages of matrix project team structures:
        
        Advantages:
        
        Effective coordination - Multi-disciplinary teams can be coordinated well through a project structure, ensuring decisions incorporate all needed perspectives.
        
        Flexibility - Matrix structures allow project teams to be formed and changed easily to respond to changing needs.
        
        Learning and skills development - Employees learn new skills and solve different types of problems outside their functional areas.
        
        Disadvantages:
        
        Employee Impacts
        
        Unclear roles and responsibilities
        Cites survey results showing # of employees confused by conflicting demands
        
        Time taken to resolve issues
        Estimates % of employees' time spent in unnecessary meetings
        
        Management Impacts
        
        Difficulty evaluating employee performance
        
        Reduced authority and influence
      - team member roles
        
        Task roles - Specialist, monitor:
        
        Focus on performing tasks and delivering work for the project.
        
        Specialist
        
        Defines: Brings technical or professional expertise to project tasks
        
        Responsibilities: Provides advice, helps solve technical issues, performs specialized work
        
        Contribution: Ensures project deliverables meet requirements by applying expertise
        
        Monitor
        
        Defines: Tracks progress against the project plan
        
        Responsibilities: Reports task status, compares actual to planned metrics, flags issues
        
        Contribution: Provides timely visibility into project performance so risks can be caught and addressed
        
        Process roles - Representative, change manager, problem solver
        
        Manage processes, communications and changes to help ensure project success.
        
        Representative
        
        Defines: Represents their functional department on the project team
        
        Responsibilities: Explains functional priorities, gathers feedback, socializes project plans and decisions within their function
        
        Contribution: Ensures functional needs are considered and functional stakeholders remain aligned and engaged with the project
        
        Change manager
        
        Defines: Manages changes to project scope, schedule or budget
        
        Responsibilities: Assesses impact of changes, gains approval, implements and communicates changes
        
        Contribution: Ensures changes are managed properly to minimize risks and disruptions to the project
        
        Problem solver
        
        Defines: Resolves issues that arise during the project
        
        Responsibilities: Leverages project team and functional resources, applies problem-solving techniques
        
        Contribution: Finds solutions to problems that allow the project to move forward and achieve its objectives
      - two approaches for assembling project team members:
        
        Using specialist project staff who are seconded to the project
        
        Specialist project staff can lead to an efficient, quickly completed project. But there may be a lack of buy-in from other staff.
        
        Adding the project to existing duties for operational staff
        
        Operational staff completing the project alongside their duties may result in a longer timeline. But there should be improved buy-in and decision makers close to the work.
        
        compares the two approaches across specific aspects:
        
        Project efficiency: Approach 1 with specialist staff is likely to be more efficient
        
        Project timeline: Approach 2 with operational staff may take longer to complete
        
        Staff buy-in: Approach 2 is likely to have more buy-in from operational staff involved
        
        Involvement in decisions: Approach 2 benefits from decision makers being closer to the work
  - - - Project leaders often lack strong management skills. They should undergo proper management training and prove themselves on smaller projects first.
      - Poor time management - Minimize by:
        Setting completion targets, regular reports and meetings
    - - Project leaders fail to use planning tools like network analysis, PERT and Gantt charts. They don't break down activities or estimate time/costs.
    - - Project monitoring is essential to determine if budgets and deadlines will be met. Reporting and review dates should be set in advance.
        Setting milestones, ensuring progress reporting.
    - - Users often pressure for quick completion. Project teams may promise unrealistic timelines.
      - Minimize by: Project managers must critically evaluate deadlines. Identifying critical activities, negotiating with stakeholders
    - - Too few resources are allocated.
        Lower cost solutions are chosen over better ones.
      - Minimize by:
        Focusing compromises on less critical areas, negotiating for more resources. Money must support achievable project outcomes.
    - - Changing requirements add costs and delays. User needs must be thoroughly examined before starting. Prototyping and walkthroughs can help verify requirements.
- - - - Occurs at project end to allow team to move on.
      - Last stage with client sign-off and team disbanding.
      - Focuses on project conduct, not just product.
    - - Closure:
        Disbanding team and wrapping up loose ends.
      - Reflection:
        Performance review and determining lessons learned.
      - Approval:
        Formal closure by steering committee.
    - - Client Acceptance - Ensure outputs successfully transferred to clients.
      - Goal Review- Illustrate outputs met goals and outcomes expected.
      - Team Closure:
        Ensure all activities completed.
        Gradually wind down team.
      - Performance Review:
        in key areas
        
        Technical - Was scope achieved?
        
        Cost - Budget performance
        
        Schedule - Timeline performance
        
        Any delays or changes to the schedule
        
        Planning - Quality of planning
        
        Relationships - Within team, with customer
        
        Which stakeholders were (and were not) involved at each stage
        
        Communication - Effectiveness
        
        Risk - Evaluation and management
        
        Outstanding Issues - Address any open items
        
        Significant issues or complaints that arose after implementation
        
        Areas where established project management practices were not followed properly
        
        Post-project review issues tend to be more process-oriented and focused on:
        
        • Project planning and execution - Were the right resources allocated? Was the scope and schedule realistic?
        
        • Stakeholder management - Were the right stakeholders involved? Were their needs met?
        
        • Project management practices - Were best practices around requirements, risk, change, etc. properly followed?
        
        • Project team performance - Did the team have the right skills and leadership?
        
        The aim is to identify ways to improve future projects based on what happened during the actual project.
      - Lessons Learned:
        
        Related to management, for future projects.
        
        Review past projects for new ones.
      - Steering Committee Closure:
        
        Committee cannot disband until outcomes deemed achieved or unsuccessful.
    - - Post Implementation Review (PIR):
        Evaluates solution after use.
        Benefit Evaluation
        
        Definition:
        
        Part of benefits management process.
        
        Occurs after solution deployed.
        
        Involves:
        
        Fitness for purpose:
        Evaluate Actual Performance: Against Predictions Against User Requirements After Sufficient Use
        
        Objectives - Comparing actual outcomes/performance to objectives/predictions.
        e.g. speeds, errors, costs, downtime.
        
        Costs and Benefits - Evaluating against forecasts.
        
        Feedback: From actual users of the solution. If users' needs have been met.
        
        Timing:
        Not too soon after go-live to distort results.
        
        Evaluating unrealized benefits (4):
        Belongs in a post-implementation review.
        
        Fixes:
        Identifying faults and fixes.
        
        Future:
        Recommendations to improve system's future performance and project management.
        
        Lessons:
        Feeding learnings back into product production processes.
        
        Value:
        Demonstrating investment value.
        
        Post-implementation review issues, on the other hand, tend to be more product-oriented and focused on:
        
        • Product quality - Are there bugs, errors or missing features?
        
        • User experience - Is the product easy to use? Do users encounter difficulties?
        
        • Support needs - What types of user support are needed after rollout?
        
        • Business benefits - Are the expected benefits actually being realized?
        
        The aim is to identify ways to improve the current product and rollout based on actual user experience after implementation.
        
        PIRs can be:
        
        Ongoing - At project gateways.
        
        Single - At a specified time after deployment.
        
        key reasons mentioned for scheduling the post-implementation review after 6 months of the new production line being operational
        
        • Gather staff feedback - Allows manufacturing staff to use the new production line for 6 months and then provide their feedback in the review. No mention is made of obtaining earlier staff input.
        
        • Customer satisfaction - The first production run pleased customers with output quality, but staff satisfaction is not mentioned.
        
        • Identify problems - 6 months is needed to see if there are any issues with maintenance, set up times or other faults with the line's operation.
        
        • Fix identified faults - The review will consider strategies to address any problems identified within the initial 6 month period.
        
        • Avoid future issues - The review will make recommendations for avoiding the identified faults in the future.
        
        • Obtain operations data - There will be more complete data after 6 months of operation on metrics like throughput, uptime, yield, and efficiency.
        
        • Account for seasonal impacts (if applicable) - 6 months spans multiple seasons to capture any seasonal performance variations.
        
        • Allow for staff adaptation - A 6 month period gives employees time to fully adapt to new processes and identify any ongoing issues.
        
        • Stabilize supply chains - Suppliers take months to work out kinks, so 6 months ensures stabilized supply chain performance can be captured.
        
        key points for why the post-implementation review could be useful for TEV's future automation projects
        
        • Identify issues in line design - Any problems caused by the design of the new production line can be corrected in future line designs for other automation projects.
        
        • Issues may not be apparent immediately - It takes weeks or months of operation for some issues to surface, like lack of flexibility, need for more staff or excessive noise.
        
        • Find solutions to problems - For any issues identified, the review should propose and select solutions.
        
        • Apply learnings to future projects - The solutions will then be considered and applied during the planning for future automation projects.
        
        • Avoid repetition of issues - By fixing issues in the post-review, future similar projects can avoid the same problems.
        
        • Noise is mentioned as a potential issue - If excess noise from the new machinery becomes a problem, solutions should be proposed and selected in the post-review.
        
        • Apply noise solutions in future designs - The noise solutions can then be incorporated into the design of future automation projects from the start.
        
        • Key to future projects - The post-implementation review is crucial to learn from this automation project and improve the chances of success for TEV's future automation efforts.
        
        Post-implementation review checklist
        
        Identify software faults and omissions
        
        Review testing procedures
        
        Analyze appropriateness of documentation
        
        Evaluate training provided to users
        
        Gather feedback from end users
        
        Determine lessons learned to improve next project
        
        the steps in the examiner's post-implementation review evaluation:
        
        Identify issues that arose after implementation - The examiner lists 3 key issues:
        
        a) Faults and omissions in the software
        
        b) Faults in the user documentation
        
        c) Lack of formal training for agents
        
        Explain the impact of each issue - The examiner explains how each issue negatively affected agents' ability to use the software properly:
        
        a) Software faults caused compatibility and functionality issues
        
        b) Faulty documentation led to agents not knowing how to use certain features
        
        c) Not providing training missed opportunities to identify issues earlier
        
        Recommend actions to address the issues - For each issue, the examiner recommends:
        
        a) Conducting acceptance testing with real users
        
        b) Inspecting documentation before release and reconsidering distribution
        
        c) Providing formal training to identify issues and build rapport
        
        Summarize lessons learned from each issue - Key lessons are summarized for each issue:
        
        a) Testing across environments and browsers
        
        b) Carefully distributing documentation electronically
        
        c) Training identifies issues early and builds user rapport
        
        Recommend feeding lessons into processes - The examiner again recommends "feeding lessons learned back into the software development process."
        
        The examiner was able to spot these issues from noticing:
        
        •Compatibility and functionality problems agents had
        
        •Agents claiming not to have received the user manual
        
        • Faults and errors in the manual
        
        • Agents' inability to perform certain tasks
        
        • The lack of formal training provided
      - Similarities:
        
        • Both occur after a project/solution is completed.
        
        • Both aim to capture lessons learned to improve future projects/solutions.
        
        • Both identify areas for improvement and further development.
        
        • Both evaluate actual outcomes and benefits against objectives.
      - Differences:
        
        Focus:
        • PPR focuses on the project management process and team performance.
        • PIR focuses on the deployed solution, user experience and realized benefits.
        
        Timing:
        • PPR typically occurs right at project end.
        • PIR usually occurs some time after deployment, allowing time for actual use.
        
        Objectives:
        • PPR seeks to improve internal project management processes and procedures.
        • PIR aims to optimize the benefits and value obtained from the solution.
        
        Outcomes:
        • PPR identifies lessons to apply to the management of future projects.
        • PIR recommends improvements to the solution itself and benefit realization.
    - - • Learning - A post-project review identifies lessons learned that can improve future projects.
      - • Process Improvement - The review identifies weaknesses or gaps in processes, methods and tools to make improvements for next time.
      - • Accountability - The review holds team members accountable for responsibilities and performance to avoid issues recurring.
      - • Avoid Delays and Over budget- The review picks up issues that led to delays and cost overruns to correct for next project.
      - • Justification - The review justifies the project's costs and outcomes to stakeholders and management.
      - • Follow-up Actions - The review identifies follow-up actions needed after the project to ensure full value realization.
      - • Correct Initiation - The review highlights issues with how the project was initiated to ensure next projects are started correctly.
      - • Clear Plans - The lack of clear plans and gateways for the project are identified to put in place for future projects.
      - • Defined Project Team - The review addresses the need for a defined project team and sufficient resources to manage next projects properly.
  - - - Having stakeholders sign an acceptance form to approve the project results
      - Conducting an acceptance testing process where users put the new system/solution through its paces to ensure it meets requirements
      - Getting formal sign-off from executives on project closure, indicating they are satisfied with the overall outcome
    - - Provide a clear conclusion to the execution stage
      - Officially transition the focus from project work to ongoing operations and maintenance
      - Set a baseline for measuring how well the project met its objectives and requirements
      - Without formal acceptance by key stakeholders:
  - - - • They both happen after implementation - They occur once a project or change has been operational for a period of time, typically months to a year.
      - • They assess actual outcomes - They evaluate how the implemented changes are actually performing in reality, not just how they were planned to perform.
      - • They identify issues - They seek to identify any issues, problems, unmet requirements or other shortcomings of the implementation.
      - • They propose improvements - Based on the issues identified, they recommend improvements, changes or fixes to optimize performance.
    - - • Focus - A post-implementation review has a broader focus, assessing the overall project outcomes and performance. A benefits review specifically focuses on whether the intended benefits are actually being achieved.
      - • Benefits - A benefits review emphasizes identifying where intended benefits are falling short and how to close that benefits gap. A post-implementation review may identify benefits not fully realized but has a broader scope.
      - • Timing - A benefits review often happens later, after enough time for intended benefits to materialize. A post-implementation review typically occurs sooner.
      - • Recommendations - A benefits review emphasizes recommendations for how to fully deliver the intended benefits. A post-implementation review covers a range of potential improvements.
    - - • Some of the benefits could be measured at post-implementation stage. - Some benefits, like improved efficiency, can begin to be assessed relatively soon after implementation through a post-implementation review.
      - • For example, improved efficiency seems to be apparent almost immediately, with daily production now being produced in two hours - Faster production times indicate higher efficiency has likely been achieved, and this benefit can be identified in a post-implementation review.
      - • but this will need to be further assessed to determine profitability as the costs of running automated production lines will be very different to the current costs and cannot be measured simply on time. - However, to determine if the higher efficiency actually improves profitability, the full costs of running the automated line must be evaluated. Production time savings alone are not enough to determine profit impact.
      - • There will be electricity and maintenance costs to consider, as well as any reduction in staffing costs. - Factors like increased electricity use, maintenance expenses and potential staff cost savings from automation must be assessed to get an accurate picture of the profit impact.
      - So in summary, while some benefits like efficiency gains may be apparent right after implementation, a full assessment of whether those benefits actually improve profitability requires an analysis of the total costs associated with the automated production line. This full cost-benefit analysis is best done in a later benefits realization review rather than the initial post-implementation review.
      - The "current costs" in this context refer to the costs associated with the previous manual production line before automation. The automated production line will have different types of costs, like:
        
        Higher electricity costs due to use of machinery
        
        Maintenance costs for maintaining the automated machinery
        
        Potentially lower labor costs if fewer workers are needed to operate the line
        
        The "time" refers to the reduced production time (from 8 hours to 2 hours daily production). While the reduced production time indicates higher efficiency, it does not on its own determine the actual impact on profitability.
      - The reason production time savings alone are not enough to determine the profit impact is that other cost factors also impact profit:
        
        Increased electricity and maintenance costs for the automated line may offset some of the savings from higher efficiency. These costs differ from the costs of the previous manual line.
        
        While production time is down, labor costs may also be lower if fewer workers are needed. But the cost savings from reduced labor need to be quantified.
        
        So to determine if the efficiency gains from the automated line actually improve profitability, the full costs associated with running that line (electricity, maintenance, labor) need to be evaluated - not just the reduction in production time. Only through a total cost-benefit analysis can the true profit impact be determined.
  - - - Summarizes project outcomes compared to objectives
      - Compares final cost to budget
      - Compares actual time taken to schedule
    - - Determines how well the project met its objectives and delivered benefits
      - Considers opportunities for further optimizing the solution
      - Identifies lessons to feed back into the process
- - - - But only incremental costs of Staff, materials can be included in project appraisal
      - Incremental costs refer to the additional costs required to run the project, over and above existing costs.
      - If new staff have to be hired specifically for the project, their full salaries would be an incremental cost to include.
      - But if existing staff are transferred from other parts of the business to work on the project, there may be no actual incremental cost. Their salaries would still be paid regardless.
      - The same logic would apply to material costs - only material purchases that are required specifically for the project, over and above existing purchases, would count as incremental costs to include in the project appraisal.
      - Transferring existing resources may have an "opportunity cost", but it does not represent an actual cash outflow.
    - - •Costs of carrying out the changes - training, recruitment, redundancy, refitting buildings
      - Incurred to implement the changes needed to realize the benefits
      - Examples include training staff, restructuring roles, modifying facilities
    - - •Ongoing costs - permanent costs of the new ways of working
      - Recurring costs needed to sustain the new ways of working
      - Examples include ongoing license fees, support contracts, payroll costs
- - - - treating costs as capital costs and depreciating/amortizing them over time can inflate the reported net income and ARR in the early years
      - This can affect decision making in a few ways:
        
        It makes the project or investment look more profitable and attractive in the early years, when in reality cash outflows have already occurred. This could lead to approving a project that may not be economically viable based on actual cash flows.
        
        The higher ARR may exceed the company's hurdle rate or required return, suggesting the project is creating value when in fact it may be destroying value based on real cash flows.
        
        It focuses attention on reported accounting profits rather than cash flows, which can distort the true economics of the investment. This could lead to continuing an unprofitable project for too long.
        
        Comparing ARRs across projects that utilize different levels of capitalized costs can give a misleading picture of relative profitability. Projects with higher capitalized costs may appear more profitable when they are not.
    - - Such accounting treatment has no impact on actual cash outflows in early years under the NPV method
      - This can affect decision making in a few ways:
        
        It means the NPV method provides a more economically accurate view of the project's viability, based on its real cash flows. Expenses are included when costs are actually incurred, not when accounting rules say to recognize them.
        
        The NPV will be a better determinant of whether the project generates positive economic value, since it captures the true timing of cash flows. The ARR, influenced by the accounting treatment, may suggest a different conclusion.
        
        By ignoring the accounting treatment, the NPV focuses management attention on the actual cash flows and economics of the project. This helps ensure resources are allocated to projects that truly create value.
        
        The NPV will be consistent across projects, regardless of their differing levels of capital vs. expensed costs. This allows for a fairer comparison of project economics.
        
        Over time, the NPV will track the true cash performance of the project more accurately. If cash flows deteriorate, the NPV will reflect this, whereas the ARR may still show artificially high returns due to the accounting treatment of capital costs.