The Daily Log is the project manager's journal of events that happen throughout the project. It is the first log that is produced and captures all of the events to provide an audit trail and historic timeline to auditors, as well as an aid to highlight and stage reporting.

Events are recording in reverse chonological order so that the most recent events on a long log are displayed at the top.

Process

1. Gather information about the event e.g. Issue ID/Risk ID, people involved, etc.

2. If all the templated have been filled add a row to the log by inserting a new row below the title row

3. Increment the Event ID

4. Capture the date of the event

5. Select the Process/Stage for the event from the data validation list 

6. Identify who performed/initiated the event within the Person Responsible e.g. a problem/issue was raised during a meeting

7. Provide a brief description and/or the title of the event. This should be aligned with any other artifact produced i.e. a risk raised should have the identical title

8. Identify the target date/commitment given for follow-ups

9. Record any follow up activies or artifacts produced.  Where possilble provide highlight the title with a link (URL) to the artifact

The Lessons Log is a storehouse of lessons learnt during the execution of the project. Lessons sought, recorded and executed during the course of the project are recorded in one place and submitted to the Project Board at the end of the project. 

Lessons recorded may be used in the current project and should be retained as collateral for future projects by the corporate organisation or programme management office (PMO), i.e. form part of future project assurance and support.. 

Process

1. Gather Lessons Report from other projects, current project brief, other reports in PID. 

2. If all the templates have been filled in add a row to the log by inserting a new row below the title row

3. Increment the Lesson ID

4. Capture the date of the lesson logged

5. Summarise the details of the lesson and the lesson type

6. Establish the priority of the lesson

7. Update the revision history information such as date and changes made

8. Identify the person responsible to approve as well as distribute the changes made

9. Provide a brief description and/or the title of the event. This should be aligned with any other artifact produced i.e. a risk raised should have the identical title

10. Ensure that this log is reviewed, maintained and retained after project completion

The Business Case is the “Business Justification” document, that outlines the valid reason for doing the project, its viability and the achievable benefits. This document is created at the start  of the project and is reviewed at each stage boundary; and when material requests for changes or exception reports are raised in order to ensure that the project is still viable and the benefits are achievable and relevant. 

Process

1. Write the Executive Summary

2. State the objectives of the project and the rationale for undertaking it. They should be aligned with the corporate or programme strategy

3. Define the benefits and return on investment of the project - how much will it cost versus how much it will save - and what will qualify as a successful outcome

4. Create the financial assessment, comparing and contrasting all available options

5. Define possible risks and any negative outcomes - exploring what can or could go wrong by consulting the identified stakeholders at the time of writing or review

6. Define the timeline for delivery of the project as well as for the benefits derived 

7. Document how the project will be funded i.e. out of extra expenditure or offset against existing or budgeted costs

The Project Product Description defines the main products to be produced by the project. It includes the customer’s acceptance, quality expectations, methodology and responsibilities for the product development activities carried out under Manage Product Delivery.

Process

1. Define the purpose of the product 

2. Define the scope of the project and how the product(s) to be developed will achieve the required scope 

3. Identify the source from which the product components will be derived/ developed e.g. build, buy, subscription for cloud services

4. Define tolerances at the project level for variances and/or off specifications 

5. Define the acceptance criteria against which the product will be assessed for all stakeholders, along with the acceptance method

6. Establish responsibilities for confirming acceptance of the products described

The Project Brief is written by the Project Board during the Start Project process. As the primary document to achieve consensus and approval of the Executive and Corporate, it provides a firm basis to the Project Board to initiate the project; while minimising cost and effort in case the project is cancelled. 

Once approved the content then moves to Initiating a Project process and becomes a part of Project Initiation Documentation (PID), and so becomes redundant.  The Project Brief should be retained for reference purposes, possible reuse and lessons learned.

Process

1. Define the project approach, considering a range of solutions such as: bespoke or off-the-shelf/cloud solutions, contracted out or in-house team formation designed from scratch or modification of an existing product

2. Define the project objectives ensuring they are Specific, Measurable, Achievable, Realistic and Time-bound (SMART)

3. Create the structure of the Project Management Team and establish the responsibilities of each person engaged on the project (see Glidepath RASCI for guidance), while ensuring that they are suitable for their role and available to work on the project during the planned time frame

The Project Initiation Document (PID) defines the project in detail and acts as a baseline document to assess progress, issues and ongoing viability of the project; and is created towards the end of the Initiation Stage to pull together all of the known information about the project.

Process

1. Define the project details and approach

2. Define the relationships and the lines of authority for all the roles descriptions that have been agreed with their owners

3. Outline the reporting and direction regime, ensuring that they are appropriate to the scale, risk and importance of the project

4. Create the content for the plans - Quality Management, Risk Management, Communication Management, Configuration Management

5. Set up the project controls and dashboards, defining what data will be reported and agree them with the programme/Corporate to ensure they are aligned with any existing standards. Often PMOs will seek to gather standard KPIs across multiple projects so ensure there are mechanisms and owners for producing these so the project manager may easily collate and share them easily and effectively  

6. Define the tolerances for costs, scope, time, quality, benefits and risks to provide the suitable level of flexibility to the project management team 

7. Ensure the PID is reviewed and approved by the end of the Initiate Project stage, signalling the project board’s approval of the project going forward

8. Baseline the approved PID by creating a new version and saving a PDF copy for future use as the departure point for the project; as the PID is likely to change during the project so all of the baselines need to be recorded

9. Share the approved PID with all authorised stakeholders

The goal of this Risk Management Plan is to minimise the effects of uncertainty on the project objectives by anticipating what could go wrong (or right), and ensuring that early warning mechanisms are in place to gather information on potential hazards

Process

1. Draft the Risk Management Procedure including sub-processes and owners for identifying, planning, assessing, implementing risk actions and communicate about the known risks and all their characteristics 

2. Ensure scales, expected values and proximity definitions are clear and unambiguous; and also aligned with the standards and risk appetite for the the organisation

3. Maintain the Risk Register, ensuring the captured information meets the defined quality criteria for the risks records 

4. Define risk reporting and timing of risk management activities e.g. risk review meetings scheduled fortnightly, tactical risk response sessions  

5. Outline and agree the responsibilities clearly for both internal team members and external customers and suppliers

The Risk Register is the record of all the risks identified, along with their history, current status and action plans. 

Process

1. Capture a concise, unambiguous and meaningful risk description.  It may be useful to use the following format for the description: 

Given that <server security patching is scheduled on the first Sunday of every month>

Result or outcome <the system test environment will not be available for testers the following Monday morning India time while we wait for the services to be redeployed and started by DevOps, in California on Monday morning>

Impact  <For every patch 6 X 1 tester days will be lost across the test team that which will need to be made up in extra tester timet> 

2. Increment and capture the new Risk ID to uniquely identify the risk and easily refer to it in other documents 

3. Choose the risk type from the drop down menu (alternative risk types can be configured in the Control worksheet

4. Define proximity or the expectation of when the risk may happen

5. Define the probability of the risk happening from the drop down menu, based on the pre and post response. 

6. Define the estimated financial impact per incident 

7. Calculate the expected monetary value exposure as the product of the probability and estimated financial impact

8. Establish risk response category from the drop down menu

9. Record the date and the person who raised the risk

10. Define the risk owner, which shouldn’t be the project manager - who manages the risk -but instead the person responsible for ensuring the risk is covered adequately in terms of responding to the threat and dealing with the hazard

11. Define the next step and the person responsible for implementing it

12. Update risk status and capture the last updated date

The Change Control Plan is used as a guideline to identify how the baselines and products developed during the project will be controlled. Change requests should bring benefits such as new capabilities, products or cost savings, or address material issues and risks that emerge during the project.   

Process

Within the Change Control Plan, describe the step by step procedure for putting forth a change request - 

1. Identifying a change. A material change should be concisely and consistently captured and its benefits, scope, time cost, quality and risk defined in succinct detail

2. Proposing a change within the scope of context of a live project taking into account the environment and resources that are available, or could be made available

3. Assessing the impact of the proposed change

4. Evaluating the Project Manager’s recommendations

5. Making decisions on the change, this may involve meetings between Project Manager and Project Board to consider the recommendations made by the former, especially where they breach any agreed tolerances 

6. Defining the decision options available to the Project Board

7. Defining the change made

8. Updating the change request and issue register, as well as capturing all other content and deliverables produced by the change 

9. Usage of any templates defined for logging change requests

10. Updating the Issue Register and Daily Log

11. Rating the change on the scale of urgency and impact

12. Defining the timescale and the prioritisation for issue management

13. Defining the reports to be submitted

14. Defining the responsibilities of the people managing the issue

Configuration Item Records register is used to capture the details of each project product.  The project may simply be one entire system but typically is made up of a number of discrete and separately managed components.  The level of detail to be captured depends on the complexity of the project product suite, but should not be over complicated unless the requirements dictate a highly detailed record keeping.  A good way to reduce the complexity is to think of the project products as individual components that are assembled to deliver the solution.  Determine how these components will be maintained and assign a CI record for each changeable element, where an element can be easily removed and replaced under the ongoing maintenance regime.  Where a Configuration Management Database (CMDB) is made available the project may instead enter/import the CI records directly into that system.

Process

1. Define the item type from the drop down menu

2. Update status and item attribute as per the Configuration Management Plan defined during Project Initiation stage, guided by the Project Product Description(s)

3. Update product state as defined by the Product Description

4. Establish the responsibility of the person

5. Allocate a date to the person

6. Identify any dependencies/relationships with other CIs

7. Mention a unique reference no. for item identifier and product identifier

8. Define the stage of development of the CI

9. Store details of the Item Identifier (or stock keeping unit, SKU), current Version, stage of the project it was completed/approved,  date of Last Status Change

10. Capture the names/departments with responsibility for maintaining the product and the related data and their roles: Owner, Location, Copyholder and Users

An Issue Register is the input document for the Issue Report and is the journal of all the formal issues raised during the course of the project, including all registered change requests. 

Process

1. Define item type from the drop down menu

2. Describe the issue

3. Define the issue type from the drop down menu

4. Establish the date and the person responsible for raising it

5. Recognize the person creating the report 

6. Establish impact, urgency and priority

7. Update the current stage

8. Capture close date

The Quality Management Plan includes procedures, processes, tools, and standards to describe how quality of the project will be “baked in” from the start, and not an afterthought.  A powerful PRINCE2 theme, Quality clearly represents the expectations for both the project products and the project management products (logs, registers, plans, etc.).  

Process

1. Define how customer’s quality expectations will be met

2. Establish quality management procedure by defining quality planning, quality control, quality standards, assurance and audits

3. Capture the tools and techniques used for quality management, especially the assessment process and timings

4. Capture all quality-related events and products produced as they arise in the Daily Log and the Quality Register

5. Establish the timing for quality management activities and the roles and responsibilities for reporting on the progress of performing them and the outcomes achieved

A Quality Register is a log of all quality activities as well as the status of all quality activities performed over the course of the project.  

Process

1. Increment the quality identifier ID 

2. Name the product being evaluated  

3. Establish responsibilities of people for quality management activities and the dates and owners of the planned activities

4. Capture the details of how or where the any quality records (e.g. test results) are retained 

5. Capture the unique product identifier for the quality activity 

6. Select the quality evaluation method from the list provided, which may be changed/extended in the Control sheet

7. Capture the result of the quality activity and details/dates of the outcomes

8. Report on the quality plan progress, i.e. during end stage reporting and exception reporting

One of the most common causes of issues on projects are due to breakdown or confusing communications, and/or delayed or absent responses. A comprehensive Communication Management Plan reduces accidental or deliberate misinformation (spin) and messaging delays for key decision makers; and established accountability for responding to communications and the agreed response times. It defines the communication flow between key stakeholders and the project manager at all stages of the project, and eliminates confusion arising from misaligned communiques entering and exiting the project. This plan should include any corporate or programme metrics and reporting requirements, and their deadlines.   

Process

1. Define the communication procedure to be followed, under formal change control, for the entire duration of the project

2. Document the tools and techniques used for communications

3. Describe how and where the communication records will be maintained

4. Describe how communications activities, receipt acknowledgement and responses will be tracked and reported

5. Establish the timings for formal communications, the acknowledgements and the response expectations. 

6. Establish the stakeholders and the persons responsible for communication at various stages of the project

During the project the project products will either supply, produce or change existing configuration items (CIs), which will bee  to be carefully tracked and handed over the operations and/or support organisations.  The Configuration Management Plan provides the Project Manager with all the information and systems required and how they are to be controlled, managed and handed over during or at the end of the project.. 

Process

1. Define the configuration management procedure covering planning, identification, control, status accounting and verification audit

2. Establish an issue and change control procedure

3. Define composition of Issue Register and Configuration Items Records

4. Define the time period of implementing the plan along with reports submission

5. Establish roles and responsibilities for each step

A Product Description defines each product to be created in detail. Product Descriptions are usually created and updated in the Manage Stage Boundary process. 

Process

1. Create a unique identifier for each product as well as the title

2. Define the main features of the product and the sources from which the product will be  derived

3. State the resources and skills required to create the product

4. Define the standard checklists and acceptance criteria for the product

5. Define the tolerances for the produce variances

6. Define the roles and responsibilities for quality checks, including producers, reviewers, testers and approvers

A Product Status Account defines the state of the product, and is most useful when different versions of the product are being created. 

Process

1. Define the scope of the report clearly indicating whether it covers a version of the product, a stage or the entire project plan

   • Define the product status  

   • Product identifier and title

   • The current version of the product

   • The current status and status of the changes/development

   • Define the product owner, producer and user

   • Actual vs. planned timeline for delivery of the product

   • List of related configuration items 

The Project Plan is a formal document that is used for both project execution as well as project control.  Following project initiation, it takes over from the PID and drives the project forward, under formal change control as defined by the Change Control Plan.

Process

1. Define what the plan encompasses 

2. State any external dependencies that may affect the plan

3. Define the assumptions on which the plan is based

4. Define the budget and the tolerances

5. Capture the project product descriptions included in the plan and the schedule and team to deliver them 

6. Define how the plan will be monitored and controlled

The Lessons Report documents the lessons learnt during the course of the project, that could also be useful in the future and so should be institutionalised by the programme and/or Corporate. It can include tips and techniques, advice on approaches, preferred products, solutions and/or vendors - practically anything that could make a material difference to the project and in future projects.

Process

1. Draft the executive summary with the lessons learnt through the project or a stage in the project.  This section should call summarise all of the content below and be easily transferred and communicated in a single presentation slide

2. Define the scope of the report, if it covers the entire project, a specific stage or an event

3. In collaboration with the project management team, conduct a review of the project covering the project management methods applied (i.e. Glidepath), approaches followed, strategies, plans, controls used, issues, changes, unexpected events and recommendations for corporate or programme management consideration.

4. Conduct a measurements review of available data e.g., the amount of effort and costs incurred required to create the products compared with estimates and budgets, effectiveness and variations of plans created and statistics on issues and risks

5. Document the significant lessons learned, opportunities for improvements based on factual data from the project records and notes of important events, their impacts, any hazards, threats/opportunities, as well as recommendations and early indicators or warning signs to be aware of in future

An Exception Report is created when a stage or project breaches any project tolerances, or even threatens to breach them. It is submitted to the Project Board by the Project Manager highlighting the reason for the deviation and recommendations for the way forward. 

Process

1. Draft the exception title and the reason for deviation

2. Specify the consequences of the deviation

3. Define options available to address the deviation and the recommendation for the best way forward

4. Define the risks involved 

5. Define the timescale for delivering the benefits

6. Note any lessons learnt

The Issue/Change Request Report is created to formally raise issues or change requests faced during the course of a stage to the project board. It is created by the project manager during the Controlling a Stage process and should be followed for any material issues or change requests that have been raised, either internally with or externally to the project team. For highly critical and urgent issues the Issue Report may sometimes follow rapid responses/actions taken by the project, in order to document them for later reporting and review, e.g. learned lessons, financial analysis, etc.

Process

1. Identify the issue in detail 

2. Assess the impact of the issue as well as the criticality

3. State the options to resolve the issue along with the recommendation for the best way forward 

4. Specify the action plan

5. Assess the implemented solution or action steps and their effectiveness

A Benefit Review Plan defines how and when the benefits derived from the project will be measured. Benefits may be derived during the project and/or after the project has completed; therefore the responsibilities for tracking the benefits will fall to the senior user of the project products.

Process

1. Define the scope of the plan - the benefits it should cover

2. Specify how and when the benefits will be measured

3. Specify how the product performance will be reviewed

4. Define the persons accountable to achieve these benefits and the resources required for the review

A Highlight Report is a health check report that a Project Manager prepares to confirm that a stage is being completed within tolerances, or not; and assess whether the project is on track or there are any or foreseeable issues arising from risks.

Process

1. Summarise the status of the stage

2. Define the work packages covered in the current reporting period as well as the next reporting period along with the tolerances

3. Review issues and/or change requests raised

4. Summarise any insights and lessons learnt

5. If required, include a summary of the project budget progress and expenditure 

An End Stage Report is created at the end of the stage and is a comparative analysis of the performance of the stage vs. the original stage plan. It also includes a review of the Business Case and whether it is feasible to continue the project or not, and a summary of the project budget and sunk costs and effort.

Process

1. Review the stage performance

2. Summarize the rationale for continuing the project, or not where the project progress or issues logged have fundamentally changed the basis for the project 

3. Assess and describe the performance of the project products against the project as well as stage objectives

4. Summarize the team performance

5. Review all material issues (including change requests) raised by the project

6. Describe any lessons learnt

7. Describe any anticipated risks 

8. Summarise the financials and effort to date

9. Provide a forecast report with details about the next stage and the projected costs (e.g. Budget at Completion) for the entire project

A Work Package provides information on work activities related to one or more products, assigned to a team. It guides the delivery team members in Controlling a Stage process and outlines the approach, tooling and ways of working to achieve the project products.  

Process

1. Describe the work to be done in detail, drawing on high-level solution designs and/or proposal from vendors

2. Describe role roles and name the team members who would be responsible for delivering the work package(s)

3. Specify the techniques, processes and tools that will be used during execution of the Work Package (e.g. Scrum, Kanban, SAFe)

4. Specify the communication flow and agreement between a team manager and a project manager

5. Define the quality criteria and the tolerances for the work package

The Checkpoint Report helps the project manager to control the project. It contains the progress of the project compared to the baselined plan. The frequency of submission of this report is agreed upon in the Work Package and is accordingly submitted by the team manager to the project manager.  In the event of a material change request, issue or risk being raised the project manager may call for a supporting checkpoint report to be produced in order to underpin these.

Process

1. Define the products to be developed in the current reporting period, the products completed and the quality management activities carried out 

2. Define the products that will be developed in the next reporting period, the products that will be completed and the quality management activities planned

3. Agree the timeframe for completion of the current Work Package 

4. Specify the tolerances and if any issues or risks are there

An End Project Report is a formal document submitted by the Project Manager to the Project Board, confirming the delivery of the project products to the users (often a the customer). The Project Board evaluates whether to authorize closure of the project based on this report. 

Process

1. Describe the project performance

2. Summarise the rationality of the project’s Business Case including the benefits achieved, the benefits expected and any deviation from the original plan

3. Review the objectives achieved within tolerances

4. Review the team performance

5. Review the Issues Register

6. Review the Register

7. Review the products delivered

8. Review the project plan 

9. Review the project schedule and budget, describing the deltas between what was original agreed and the actual outcomes were

10. Review and any lessons learnt

This template is made available as part of GLP000 Glidepath Pack in the templates folder. The Use Case document provides a storyline on how a system and its actors will be utilized to achieve a pre-defined objective. The document will have a step-by-step process on how the system will be used. 

Process

1. Provide a short name of the Use Case as an identifier

2. Describe the reason for the Use Case and the expected outcomes

3. Define the actors

4. Define the precondition as well as the postcondition for execution of Use Case

5. Describe the sequential flow of activities

6. Describe any alternate flow which is separate from the main flow 

7. Define any exceptions

8. Define any special requirements

9. Define the associated the test cases for the use case 

10. Define the user stories for the use case

This template is made available as part of GLP000 Glidepath Pack in the templates folder. Manager Work Schedule defines the key repeating activties and ownership for the managers on the project. It provides a basis to ensure these stakeholders understand their level of workload and timings of tasks and meetings, which will require addtional time for preparation.  Using the Manager Word Schedule the project manager formalise these expectations in advance with the individual managers.  The project manager may then popolate their diaries with meetings for the duration of the project, confident in the commitments made by the manager to the project. 

Process

1. Define the daily, fortnightly, monthly, quarterly and annual tasks for each executive, team member, and project manager as defined in the Communications Plan

2. Set up formal communication meetings with the affected personnel and agree their schedules and responsibilities to meet their responsibilities and their estimated workloads

3. Issue meeting invitations for the agreed dates and times with the managers according to the Commucations Plan and and the agreed Manager Work Schedules

4. Track and communicate any changes or exceptions to the schedules arising in Change Requests or exception reporting

A Stage Plan covers the day-to-day activities for a Project Manager using the resources specified in the plan to deliver the project products. The controls to monitor and deliver the products are also mentioned in the Stage Plan.

Process

1. Describe what the Stage Plan covers including the stage, the team and the products to be delivered

2. Capture the prerequisites for starting the stage

3. Outline any upstream and downstream external dependencies 

4. Capture any assumptions for the stage, especially in terms of scope and what will not be included in the project products and the project management products to underpin these

5. Summarise the lessons incorporated in the plan and how they will be applied during the stage

6. Define the project controls and the tolerances for the stage

7. Define the resources required to deliver the project products

8. Describe the project products in detail

9. Provide the schedule for execution of the work, at minimum the list of key milestones and projected schedule of key activities

This template is made available as part of GLP000 Glidepath Pack in the templates folder. The Stakeholder Relationship Organiser is a Project Manager’s organiser to define and understand the stakeholders in the project. 

Process

1. Define the role of the stakeholder in the project. It can be - sponsor, customer, resource provider, team member, approver, reviewer, end user, etc

2. Specify if the project team is internal or external

3. Define success criteria for the project

4. Define the ways each sponsor can help the Project Manager to manage the project

5. Identify potential problems on the project created by stakeholders' actions

6. Define Project Manager’s personal action plan for the stakeholder

The project budget and schedule tracker helps a project manager and the stakeholders to estimate the costs, track expenses, and plan for any financial contingencies over the course of the project.  It employs:

•  A simple Gantt chart for waterfall projects but can also be used to capture an Agile sprint plan as a sequence of cascading sprints.  It is seldom necessary to capture a detailed task list, but if required, the tasks can be further broken down into subtasks and grouped using to hide the complexity and so retain the readability of the sheet.

• A blended rate for resources. It is often not necessary to maintain 100% accurate time and accuracy at all times as the project costs will often fall under a wider financial management system or function.  If greater accuracy and detail is required, or If daily rates vary significantly, then the Schedule worksheet may expanded to cater for the additional detail.

Process

This template is made available as part of GLP000 Glidepath Pack in the templates folder. The project budget and schedule tracker is best used by configuring and adding content to the sheet in the following order:

Control

1. Configure the start and the end dates of the weeks from project initiation

2. Capture the blended daily rate in order to simplify project tracking

3. Capture any alternate daily rates or costs for for external/special resources

Schedule

1. Identify the number of planned weeks, starting from project initiation

2. From the work breakdown structure and/or content provided by the project delivery teams/vendors, determine the critical path using a project network diagram. This is best done during a workshop with the project delivery team using post-it notes and a white board

3. Lay out the critical path for the project by subdividing it into different tasks following the examples provided

4. Create floating tasks around the critical paths to ensure the latter is maintained

5. Cascade the tasks and link them using cell border formatting to show the cascaded sequence of dependencies

6. Enter the budgeted hours for each task across all resources performing the work

7. Enter the actual hours logged per week the Time Recording on a weekly basis. Mondays are best as time recording is typically done late on Fridays by the team members:

• The budgeted weekly cost is calculated along with the budget variance 

• The actual cost of work performed is calculated

• The sheet auto calculates the weekly variance in the actual cost vs. the budgeted cost

• The weekly change in the budget based on the actual cost is calculated

Time recording

1. Identify weeks of the year starting from project initiation

2. Allocate the resources required per week. This will include both internal and external resources

3. The spreadsheet auto calculates the total labour hours required per week. 

This worksheet can be copied to one or more separate spreadsheet(s) in the event that the project financials need to be kept private or secure.

Expenses

Expenses should be agreed and documented as part of the project team briefings and onboarding.  Subcontracted work costs should be identified and approved when the project plan is baselined during the Project Initiation stage. 

To record expenses:

1. Identify the source of the expense or voucher a unique ID such as an invoice number, or a receipt number.

2. Identify the expense type or the reason why it was incurred

3. Enter the details of the expense - date, amount, detail, the task for which it was incurred and the name of the person submitting it

4. Identify the person who has the authority to approve it

5. Update the status to approved or rejected

6. Capture and upload the source document (receipt, invoice, etc.) to the Expenses folder

7. Link the expense ID to the uploaded source document for easier identification and approval

8. Obtain approval from the relevant stakeholder for the expense

The team manager and project manager define the list of deliverables (use cases/user strories) to deliver the work package. The use cases and/or deliverables are estimated, prioritised and assigned based on their readiness.  The Tracker colums are autofiltered to allow easy slicing and dicing of the data during review workshops.  The Kanban visualises the workflow and automatically reflects the stage of each deliverable.

The team manager and experts on the team will assemble a list of deliverables to be produced from preparatory work for the project, which typically include but are not limited to:

• Business case

• Benefits Register

• Technical and business requirements

• Use and Test cases

• Solution designs

• Vendor proposals

• Risks and Issues Logs

• External dependencies and the wider project ecosystem

• Workshop content

This template is made available as part of GLP000 Glidepath Pack in the templates folder. Create a Work Package Tracker and Kanban for each project team and assign responsibility for completing and managing it to the project team lead.  The project team lead owns this tracker and uses it on a daily basis to control the work as defined in the assigned Work Package.

Control sheet

1. Capture the programme and project information.

2. Assign the team lead and record their name.

3. Records - Review the records guidance to be captured and agree with the team on how best to capture them in the tracker.  Regularly review the tracker usage with the team and make improvements to suit the work package delivery.

4. Status - review the default options for the tracker and align them with the team workflow.  It is best to keep this simple but it may be worthwhile adding something like Testing as an additional status.  Update the Tracker and Kanban columns to reflect any additions/removals.

5. Asignee - capture the names of the team members what will be to which the work will be assigned.  Inserting any new names before the last line will ensure that they appear in the Tracker dropdowns which having to update the dropdown range.

6. Loop (sprint) and Goal - define the expected number of loop of work to be carried out to deliver the work package.  Each loop (sprint) should have a clearly defined goal.  While the tracker and Kanban are designed to be used across multiple loops (sprints), the team lead may elect to may a new copy of the tracker for each loop.  These copies should be distinctively named, versioned and stored in the project folder.

Tracker and Kanban sheets

1. The Team Lead should capture all of the deliverables in the Tracker worksheet and assign them to the Backlog.  The team lead will engage the help of the team and the project manager to ensure the Work Package scope is fully understood and captured correctly.  Recommendation:  Keep the Tracker worksheed clean and simple by only capturing deliverables and not detailed tasks.  Where deliverables need to be broken down and tasks assigned, this should be done on a seperate dedicated worksheet, assinged an ID, descriptively named, and cross-linked to the Tracker. 

2. Conduct backlog review sessions with the team to orgnise and prioritise the backlog.  This is best done in consultation and collaboration with the team to maximise buy-in. Agree the scope, points and value of the deliverable, allowing the team to input their view across business, technical and testining to arrive at consensus for each item.  See this Glidepath guide on prioritisation by cost of delay. 

3. Once a priority factor has been defined for each item, sort the list in decending order to identify the items to be worked on earliest versus items that should be tackled later, or remain on the Backlog.  

4. Conduct loop (sprint) planning sessions:

   • Review the backlog, sizings, value and prioritisation.  Where deliverables form part of a depenency chain, ensure their priorities are algined to sequence them correctly

   • Allow the team members to "pull" their own assignments by offering to take on the deliverables and assigning themselves

   • Solicit commitment from the team members to specific completion dates for items with external dependencies so these can be tracked and reported on by the team lead, project manager the the project office 

5. During the loop (sprint) print and subsequent reviews:

   • The team lead should update the tracker as each item travels through the workflow.  The Kanban should be dispayed on a daily basis for the the team members to review, share any blockers, ask for help and suggest changes.  The Tracker columns can be filtered to improve focus on the work-in-progress and the Backlog column on the Kanban should be hidden during the sprint to reduce screen clutter; and the temptation to discuss the Baklog items. 

   • At the sprint review the Tracker should be backed up and archived to capture a shanpshot, which will be useful for reporting and auditing by the team lead and project manager.