The Scheduling Maturity Model

Association for Project Management (APM)

• Publisher: Association for Project Management (APM)
• Year: 2014
• Print ISBN: 9781903494479
• eBook ISBN: 9781903494455
• Topic: Business
• Subtopic: Project Management
• Index: Business

The Scheduling Maturity Model is intended to provide a defined means of establishing and improving scheduling capability as part of an organisation's project, programme or enterprise control processes. Moreover, it is intended to support project and programme teams and organisations by improving an important part of their overall project controls capability.

Annex A – Scheduling Maturity Model Questions

table class="source-table" cellspacing="0">

ATTRIBUTE MATURITY LEVEL

 

1

2

3

4

5

As Is

To Be

 

1. Use of Scheduling Process & compliance to contractual requirements

 

 

The scheduling process is ad-hoc and not coordinated. There are no documented scheduling guidelines or standards. The schedule
complies with most,
if not all, applicable contractual requirements for schedules.

The scheduling process is ad-hoc and not fully coordinated. Some local scheduling guidance in place. The schedule complies with all applicable contractual requirements for schedules.

The scheduling process is structured and focused. It utilises a set of standard, documented, and controlled processes for the preparation and publication of schedules. Reviews/audits are periodically conducted to ensure documented processes are being followed and contractual requirements are being met.

The scheduling process is followed by the whole team. It utilises metrics to monitor the health of the scheduling processes and performs scheduled self-assessments, as documented, to ensure processes are being followed.

All projects and contracts within the programme adhere to a consistent documented scheduling process. All project teams follow the same process. Poor process performance is isolated, and corrective action plans are implemented. Root cause analysis is performed and corrective actions are implemented when scheduling process issues are identified. Process improvements are identified and fed into the Project Management Function.

 

 

 

2. Scheduling tools are suited to enterprise needs

 

 

Process and toolset

Schedules are generated by hand or PC graphics software.

Master and team schedules are developed manually using one or more databases. Integration between team schedules is managed separately from the scheduling toolset.

Project management software (networking and resource loading capability) is used for non-recurring schedules or other appropriate schedules. Management-recognised standard software tools are used. All schedules are integrated in a ‘singlesource’ database with manual links to other systems. Schedules are manually linked to other systems as part of performance management.

All schedules are integrated by automation into a ‘single-source’ database. There is automated linkage between the ‘singlesource’ schedule database and other systems containing schedule data. Schedule performance metrics exist in the MIS. Appropriate scheduling tools are utilised based on the size and complexity of programme.

Colour-coded (or other differentiator) schedule metrics with drill-down capability are generated from the scheduling database for the MIS. Presentation graphics are generated from the scheduling database. Major supplier detailed schedule data is transmitted via electronic data interchange (or other automated technology) and is electronically integrated into the programme schedule. Scheduled/network templates are used for standard sequences of activities.

 

 

 

3. Schedule analysis products are current and used throughout the enterprise

 

 

Schedule update is ad-hoc. Clearly defined ownership of schedule elements is not always appropriate.

Schedules are updated and statused on a regular published update cycle per project management and contractual requirements. (Estimated/forecast dates are projected for milestones and activities which are past due or with negative float.)

Schedule performance metrics are prepared and reviewed with/by Team Leaders on a regular (or other documented) basis. (Examples include: Current schedule vs. actual milestones, deficient item listings, supplier status and impact of late items.)

The following types of metrics are also reviewed regularly. Examples include: an overall schedule performance summary/variance analysis; network and Critical Path Analysis.
The project utilises float as an indicator of schedule health.

Predictive analysis is reported in regular meetings and is utilised in the decision-making process by the project management team.

 

 

ATTRIBUTE MATURITY LEVEL
	1	2	3	4	5	As Is	To Be
	4. Defined organisation/roles and responsibilities
	No consideration of an Organisation Breakdown Structure (OBS). Roles and responsibilities are not documented.	Roles are defined but responsibilities are not. No OBS is identified in the schedule.	All activities are assigned to an element of the OBS. A documented correlation exists between the WBS and OBS, utilising the RAM.	Organisational issues are subject to change control. OBS and RAM are maintained within the scheduling tool to reflect the current standard.	The project OBS includes cross-references to other OBS at the enterprise level.
	5. Capturing project and customer requirements
Schedule structure and hierarchy	There are no formal methods for capturing customer requirements – e.g. WBS or only an outline WBS or PBS.	Scope is documented, defined and decomposed into meaningful, manageable elements. A recognised WBS is established.	All authorised work elements are defined for the project. A WBS is used in this process and captures the full scope of work.	A systematic process decomposes project requirements and identifies the scope of work necessary to deliver these requirements. The scope of work is under configuration control. The link between customer requirements and WBS elements is clearly defined.	All customer requirements have been decomposed into the WBS and associated work scope. This mapping is transparent and under configuration control. Changes to the technical baseline or requirements are properly managed through a documented, integrated change control process.
	6. Basis of Estimate
	Project estimates are produced without Project Team consultation and without documented procedures.	There is a record of estimates but formal estimating techniques and processes have not been applied. Estimating assumptions are not fully documented.	A formal structured estimate has been generated following standard estimating procedures. All estimating assumptions are fully documented.	Estimates are based on previous project norms, historical data, or parametric estimating. All estimating assumptions are fully documented.	The estimate has been reviewed by an independent authority. Upon completion of projects the actual performance data is used to inform future estimates/update project norms. Full ownership and authorisation of the estimate is shared by all relevant ...

Table of contents

• Cover
• Copyright
• Table of contents
• Preface
• Foreword
• Acknowledgements
• Applicability
• Introduction
• Fundamental Concepts
• How is the Maturity Model used for Assessment?
• What are the Benefits?
• Assessment – The General Process
• Implementation Roadmap – Maturity Levels and Stages
• Scheduling Compass Guidance Information
• Process and Toolset
• Schedule Structure and Hierarchy
• Schedule Integration
• Schedule/Resource/Cost Integration
• Schedule Risk
• Schedule Update and Maintenance
• Environment
• Annex A – Scheduling Maturity Model questions
• Annex B – Glossary
• Annex C – Abbreviations and Acronyms
• Annex D – Related Documents
• Annex E – Figures and Tables
• Back Cover