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 recorded in reverse chronological 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 templates 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 activities or artifacts produced. Where possible, 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. forming part of future project assurance and support.

Process

1. Gather Lessons Report from other projects, the 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, aligned with any other artifact (e.g. 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, to ensure the project remains viable with achievable benefits.

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 it will 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 identified stakeholders
6. Define the timeline for delivery of the project as well as for the benefits derived
7. Document how the project will be funded (extra expenditure or offset against existing/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 or 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 the Initiating a Project process and becomes a part of the Project Initiation Documentation (PID), after which it is retained for reference and lessons learned.

Process

1. Define the project approach, considering solutions such as bespoke/off-the-shelf/cloud, or in-house vs. contracted teams
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 (see Glidepath RASCI), ensuring they are suitable and available during the planned timeframe

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

Process

1. Define the project details and approach
2. Define the relationships and lines of authority for all role descriptions agreed with their owners
3. Outline the reporting and direction regime, ensuring appropriateness for the project’s scale, risk, and importance
4. Create the content for the plans (Quality, Risk, Communication, Configuration Management)
5. Set up project controls/dashboards, defining reported data and aligning with programme/corporate standards
6. Define tolerances for costs, scope, time, quality, benefits, and risks, giving flexibility to the project team
7. Ensure the PID is reviewed/approved by the end of Initiate Project stage, signalling approval to proceed
8. Baseline the approved PID by creating a new version and saving a PDF copy for future reference
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.

Process

1. Draft the Risk Management Procedure including sub-processes and owners for identifying, planning, assessing, implementing risk actions, and communicating the known risks
2. Ensure scales, expected values, and proximity definitions are clear, unambiguous, and aligned with the organisation’s standards and risk appetite
3. Maintain the Risk Register, ensuring the captured information meets defined quality criteria
4. Define risk reporting and timing (e.g. fortnightly risk reviews, tactical response sessions)
5. Outline and agree responsibilities for both internal team members and external customers/suppliers

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

Process

1. Capture a concise, unambiguous, meaningful risk description (e.g., “Given that… Result or outcome… Impact…”)
2. Increment and capture a new Risk ID for unique reference
3. Choose the risk type from the drop-down menu (configurable in the Control worksheet)
4. Define proximity (when the risk may happen)
5. Define the risk’s probability (pre/post-response) from the drop-down
6. Define the estimated financial impact per incident
7. Calculate expected monetary value (probability × financial impact)
8. Establish a risk response category from the drop-down
9. Record the date and person who raised the risk
10. Define the risk owner (not the PM), responsible for responding to the threat
11. Define next steps and the person responsible
12. Update risk status and capture the last updated date

The Change Control Plan is used as a guideline to identify how baselines and products developed during the project are controlled. Change requests should bring benefits (e.g. new capabilities, products, cost savings) or address material issues and risks arising 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 capture details of each project product. The level of detail depends on complexity but should not be overcomplicated unless required. If a Configuration Management Database (CMDB) is available, the project may import CI records directly into it.

Process

1. Define the item type from the drop-down menu
2. Update status and item attributes as per the Configuration Management Plan (guided by Product Descriptions)
3. Update product state as defined by the Product Description
4. Establish the responsible person and allocate dates
5. Identify dependencies/relationships with other CIs
6. Mention a unique reference number for item and product identifiers
7. Define the stage of CI development
8. Store details of the Item Identifier (SKU), current version, stage completed/approved, and date of last status change
9. Capture names/departments responsible for maintenance (Owner, Location, Copyholder, Users)

An Issue Register is the input document for the Issue Report, logging all formal issues raised during the project, including change requests.

Process

1. Define the 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. Recognise the person creating the report
6. Establish impact, urgency, and priority
7. Update the current stage
8. Capture the close date

The Quality Management Plan includes procedures, processes, tools, and standards describing how the project’s quality is built in from the start (not an afterthought). Quality applies to both project products and project management products (logs, registers, plans, etc.).

Process

1. Define how the customer’s quality expectations will be met
2. Establish a quality management procedure (quality planning, control, standards, assurance, audits)
3. Capture tools and techniques for quality management, including assessment process and timings
4. Capture all quality-related events/products in the Daily Log and the Quality Register
5. Establish timing for quality management activities and roles/responsibilities for reporting progress

A Quality Register logs all quality activities and their status over the course of the project.

Process

1. Increment the quality identifier ID
2. Name the product being evaluated
3. Establish responsibilities for quality management activities (dates/owners)
4. Capture details of how/where quality records (e.g. test results) are retained
5. Capture the unique product identifier for the quality activity
6. Select the quality evaluation method (extendable in the Control sheet)
7. Capture the result of the quality activity and the dates/outcomes
8. Report on quality plan progress (end stage, 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, under formal change control, for the entire project
2. Document the tools and techniques for communications
3. Describe how and where communication records are maintained
4. Describe how communication activities, acknowledgements, and responses will be tracked/reported
5. Establish the timings for formal communications, acknowledgements, and response expectations
6. Establish the stakeholders and persons responsible for communication at each stage

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 (planning, identification, control, status accounting, verification/audit)
2. Establish an issue/change control procedure
3. Define composition of Issue Register and Configuration Items Records
4. Define the timeframe for implementing the plan and submitting reports
5. Establish roles/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 sources from which it will be derived
3. State the resources and skills required to create the product
4. Define standard checklists and acceptance criteria
5. Define tolerances for product variances
6. Define roles/responsibilities for quality checks (producers, reviewers, testers, 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 (version, stage, or entire project plan)
2. Define the product status
3. Include product identifier and title
4. Record the current version
5. Record the current status and any changes/development
6. Define the product owner, producer, and user
7. Compare actual vs. planned timeline for delivery
8. List any 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 tolerances
5. Capture the product descriptions, schedule, and team delivering 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 of lessons learnt (e.g. from a project stage). Summarise all content below
2. Define the scope of the report (entire project, a specific stage, or an event)
3. Review the project with the management team (methods used, approaches, strategies, controls, issues, changes, unexpected events, recommendations)
4. Conduct a measurements review (effort, costs, estimate comparisons, plan effectiveness, issue/risk statistics)
5. Document significant lessons, improvements, recommendations, hazards, threats/opportunities, and early warning signs

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 reason for deviation
2. Specify the consequences of the deviation
3. Define options to address the deviation, plus a recommended 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 and its criticality
3. State the options to resolve it and recommend the best approach
4. Specify the action plan
5. Assess the implemented solution or actions taken 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 – which benefits it covers
2. Specify how and when the benefits will be measured
3. Specify how the product performance will be reviewed
4. Define who is accountable for achieving these benefits and the resources required for reviews

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 this and the next reporting period, plus tolerances
3. Review issues and/or change requests raised
4. Summarise any insights and lessons learnt
5. If required, include a summary of 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. Summarise the rationale for continuing the project, or not, if fundamentals have changed
3. Assess performance of products vs. project/stage objectives
4. Summarise team performance
5. Review all material issues (including change requests) raised
6. Describe any lessons learnt
7. Describe any anticipated risks
8. Summarise financials and effort to date
9. Provide a forecast for the next stage and total project costs (e.g. Budget at Completion)

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 in detail, referencing higher-level solution designs or proposals
2. Describe roles and name the team members delivering the package
3. Specify techniques, processes, and tools (e.g. Scrum, Kanban, SAFe)
4. Define communication flow between team manager and project manager
5. Define the quality criteria and 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 developed in the current reporting period, completed products, and quality management activities carried out
2. Define the products planned for the next reporting period, plus planned quality activities
3. Agree the timeframe for completing the current Work Package
4. Specify tolerances and note any issues or risks

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 authorise closure of the project based on this report.

Process

1. Describe the project performance
2. Summarise the Business Case rationale (benefits achieved/expected, deviations from plan)
3. Review objectives achieved within tolerances
4. Review team performance
5. Review the Issues Register
6. Review the Register (e.g. changes, logs)
7. Review the products delivered
8. Review the project plan
9. Review the schedule/budget, highlighting deltas vs. original agreement
10. Review any lessons learnt

This template is available as part of GLP000 Glidepath Pack. The Use Case document provides a storyline on how a system and its actors will be utilised to achieve a pre-defined objective.

Process

1. Provide a short name for 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 and postcondition for Use Case execution
5. Describe the sequential flow of activities
6. Describe any alternate flow separate from the main flow
7. Define any exceptions
8. Define any special requirements
9. Define associated test cases
10. Define user stories for the Use Case

This template is available as part of GLP000 Glidepath Pack in the templates folder. Manager Work Schedule defines the key repeating activities 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 additional 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 populate 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 executives, team members, and the project manager (per the Communications Plan)
2. Set up formal communication meetings, agreeing on schedules/responsibilities for workloads
3. Issue meeting invitations for agreed dates/times in accordance with the Communications Plan and Manager Work Schedules
4. Track and communicate any schedule changes or exceptions arising in Change Requests or exception reports

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 (stage, team, products)
2. Capture prerequisites for starting the stage
3. Outline upstream/downstream external dependencies
4. Capture assumptions, especially scope limitations or exclusions
5. Summarise lessons incorporated in the plan and how they are applied
6. Define project controls and tolerances for the stage
7. Define resources required to deliver products
8. Describe the products in detail
9. Provide a schedule (key milestones, projected activities)

This template is 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 stakeholder’s role (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 ways each sponsor can help the Project Manager
5. Identify potential problems caused by stakeholder actions
6. Define the Project Manager’s personal action plan for each 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 accounting system or function, which can be used to reconcile the actual costs on an agreed cadence.  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 available as part of GLP000 Glidepath Pack. 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 stories) to deliver the work package. The use cases and/or deliverables are estimated, prioritised and assigned based on their readiness. The Tracker columns are auto filtered 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 available as part of GLP000 Glidepath Pack for a fee. 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 organise 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 testing 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 descending 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 aligned 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 displayed 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 Backlog 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.