Explorer

• What is Through Life Management?
• Is Through Life Management Mandatory?
• How TLM relates to TLCM?
• What is a Through Life Management Plan?
• Framework for a TLMP
  • Section 1 - Mission and Objectives
  •     Section 1 - Further Advice
  • Section 2 - Stakeholders
  •     Section 2 - Further Advice
  • Section 3 - Strategies
  •     Section 3 - Further Advice
  • Section 4 - Plans and Processes
  •     Section 4 - Further Advice
  • Section 5 - Resources
  •     Section 5 - Further Advice
  • Section 6 - Evaluation of Success
  •     Section 6 - Further Advice
• Producing the TLMP – Process Overview
• Who Should use a TLMP
• The TLMP across an Acquisition Lifecycle
  • The TLMP in the Concept Phase
  • The TLMP in the Assessment Phase
  • The TLMP in the Demonstration and Manufacture Phase
  • The TLMP in the In-Service Phase
  • The TLMP in the Disposal Phase
• The TLMP and Other Acquisition Processes
• Measuring TLM Maturity
• Applying the TLMP Process
  • System and Platform TLMPs
  • TLMPs for In-Service Projects
  • TLMPs in Cluster IPTs
  • TLMPs for Small Projects
    • TLMP Templates for small projects
  • TLM Support Tools
  • Electronic and Web-based TLMPs
• TLM Frequently Asked Questions
  • TLM General
  • Producing a TLMP
  • Stakeholder Issues
  • Costing the TLMP
• TLM Common Terms
• Contacts

Content

TLMP Section 2 Further Advice: More on the Contents of TLMP Section 2

Include an overview of the Project Organisation

The overview should refer to the relevant organisational charts, meeting structures and project contact directories.

Include an IPT Context Diagram or Stakeholder Map

The Context Diagram or Stakeholder Map is a key section of the TLMP - it defines the wider context in which the project must operate and the stakeholders who must have visibility of the TLMP and contribute to it.

To map the stakeholders, consider all the interdependencies that the project has with:

• Customer organisations.
• Users.
• IPTs.
• Support Groups.
• The corporate management chain.
• Contractors.
• Other agencies.

This may require some group brainstorming to identify them all.

An example is shown in the adjacent diagram.

IPT / Stakeholder Context Diagram

The map will be different for each project - these are the broad categories to indicate the types of stakeholders and the nature of the interface with them.

Define Key Stakeholder interfaces – agreement and control

• For each stakeholder, you should define:
• Involvement in the project in terms of roles and responsibilities.
• how any agreement with the stakeholder is formalised and controlled for example a:
  • Customer Supplier Agreement (CSA)
  • Joint Business Agreement (JBA)
  • Service Level Agreement (SLA)
  • Internal Business Agreement (IBA)
  • External Business Agreement (EBA).
• Reference to the relevant agreement and where to find it.
• How the relationship or interface with the Stakeholder is managed - with reference to the relevant project meeting, review or reporting processes.
• Whether there are project dependencies, risks or issues associated with this stakeholder.
• Large projects and those with complex interfaces are likely to have a very extensive stakeholder map. In these cases it may be necessary to divide the stakeholders into the Key Stakeholders - Customers, contractors and suppliers, IPTs with whom there are critical interfaces - and Other Stakeholders those who have a lesser, but still important, involvement in the project.
• Stakeholders should not be omitted from the TLMP just because they have a lesser role. The more complex the stakeholder interfaces, the more important it is that they are comprehensively and systematically mapped in the TLMP - otherwise you may miss important risks or dependencies that need to be managed.

Create a Stakeholder Responsibility Matrix

This is a table which defines the Stakeholder roles, responsibilities and relationships in more detail than the IPT Stakeholder Context Diagram. A typical layout could show each stakeholder, with their responsibilities, the type of business agreement establishing the relationship (with reference to the actual document), and any other useful information (eg key dependencies, risks, issues etc)

Create a Defence Lines of Development (DLoD) Responsibility Matrix

This type of table provides the linkage between the IPT Through Life Management Plan and the management and delivery of the other components of the Military Capability (the DLoDs). A sample DLOD Responsibility Matrix [34KB DOC] is available.

Depending on the extent of an IPTs role in the delivery of non-Equipment DLoDs, it may be appropriate for the TLMP to include specific sub-sections to address them, within Section 3 (Strategies) and/or Section 4 (Plans and Processes).

Alternatively combine the Stakeholder and DLoD Matrices

As an alternative to the separate maps and matrices outlined above you might consider merging the Stakeholder Responsibility Matrix [39KB DOC] and the DLoD Responsibility Matrix [34KB DOC]. Follow the following link for an example stakeholder/DLoD matrix.

This example uses the RACI technique to identify the different types of stakeholder responsibility (ie Responsible, Accountable, Consulted, or Informed).

Include a TLMP Responsibility Matrix for larger teams

In larger projects and larger teams you should decide whether to nominate lead authors or owners for each main section and sub-section. Draw up a ‘TLMP Responsibility Matrix’ – identify the lead desk officer responsible for each sub-section of the TLMP and supporting strategies and plans.

Further information and advice can be sought from the TLM Subject Matter Experts .

Change History

Change History