Scalable project requirements management

Transcription

1 Scalable project requirements management Ir. V.(Vincent) van der Meijden CEO PACER Working with TopTeam 7.39 at Dutch Centre for Public Works (appr 160mio project)

2 Contents Short intro on Dutch government contracting Explanation on constructing specifications Upscaling in complexity Review on information management tooling

3 Dutch Public Works Sector Asset management of complex systems such as: Storm Surge barriers Waterways Locks Docking systems Roads (Movable) Bridges Tunnels Pipes Cable ducts Monitoring Traffic Management Systems Environmental projects Noise absorption measures and barriers Camera systems Etc. Etc. Etc

4 Dutch government entities position towards contracting Dutch government entities have taken an approach towards more involvement of the Dutch Contractors as a system developers and system integrators This leads to more responsibilities for the Contractors and their Suppliers Contractors are obliged to verify and validate that they are in conformity with the system requirements and user needs The standard framework is therefore needed: systems engineering Systems engineering puts focus on project information management such as system design, requirements and scope management

5 Development of the Guideline on Systems Engineering 2005 UAVgC Contracting Guidelines for integrated (multi-phase & multi-disciplinary) contracting Rijkswaterstaat started a Handbook for Technical Management (TM) Joined by: - Dutch Construction and Infrastructure Federation - ProRail - Dutch association of consulting engineers Goal: achieving a common vision on TM Guideline SE rev. 1.0 (Dutch) [april 2007] Guideline SE rev. 1.0 (English) [april 2008] Systems engineering Roadmap [sept 2009] Guideline SE rev. 2.0 (Dutch) [nov. 2009] Guideline SE rev. 3.0 (Dutch) [nov ]

6 Managing complex systems require a Shared state of awareness Project management: Each Rijkswaterstaat project is organised according to the Integral Project Management (IPM) model to achieve a shared state of awareness of the project. The goal is: Every team member needs to understand the project requirements and must know their contribution for the project

7 Managing complex systems require a Shared state of awareness Lack of shared awareness? If any one of the team members has poor understanding of the project, it can lead to critical errors in performance that can undermine the success of the project. System Integration

8 Systems Engineering Processes Requirement Engineering Life-Cycle Engineering Risk Management System Integration Interface Management Integrated Technical Planning Trade Studies Verification & Validation Architectural Design Configuration Management Speciality Engineering Traceability Based on ISO

9 Need for information management Requirement Engineering Life-Cycle Engineering Risk Management System Integration Interface Management Integrated Technical Planning Trade Studies Verification & Validation Architectural Design Configuration Management Speciality Engineering Traceability Based on ISO

10 Here, the information management really begins when creating things such as: System Breakdown Structure (SBS) [examp. Terminal] Functional Breakdown Structures (FBS) [examp. Terminal] mapping functions onto systems [examp. car] Combining the SBS and FBS for reporting Requirements traceability Scope management System design phasing (baselines) System Configuration System Verification and Validation Issues management Risk assessment Etc.. Information (at the start) Project manager

11 In simple projects, at a minimum, we must: 1. Create the Scope, System Breakdown and requirements

12 In simple projects, at a minimum, we must: 2. Define Functional Breakdown + additional requirements

13 In simple projects, at a minimum, we must: 3. Map requirements and functions onto systems SYSTEM SPECIFICATION / CONTRACT

14 Goal in contracting : Gather the Scope + SBS + FBS + additional information into a contract. System Breakdown Structure Table of contents of the Design and construct Contract Contract Functional Breakdown Structure Fills chapters with the Functional Requirements

15 Scale and complexity The previous aproach will work for simpler projects (local projects, e.g. small inner city development and straight forward engineering) >> MS Excell works well for some With growing complexity: - Engineering: staged/phases - Analysis: leads to more requirements - Focus: system integration - Information: managed >> MS Excell will kill you Space for fence 1/2 track distance 2750 Pressure danger zone 3000 B.S. Level Interface level BS-660 PVR PVR- -GC GC track centre line Settlement free plate 3000 mm Fig 1. Cross Profile Free Track Cable space 600x (HSL 611 viaduct) BS x Units mm Mounting surface for catenary masts Mounting surface for noise screens or handrail 550 Scope IP Scope Civils Space for cable pit 1000x1200 x1000 times 2000 Soil level BS-360 Handrail

16 Medium project need to ad: Functional Analysis Requirements Project doc.s Project info System schematic List of derived Requirements

17 Medium project need to: Performing the functional analysis further System Breakdown Structure x Functional Breakdown Structure Oops! In a spreadsheet the flow of information is only one-way Requirements Mandatory Documents listing It s almost impossible to get information aligned

18 Large and complex projects need to also add: System Configuration for complex systems loops VIC-net INMAN Detector Processor Interface INROS Local systems Processor Interface INDET Multisign Power supply INRIN Control loops service

19 Large and complex projects need to also add: System Verification Source Requirements Domain Dynamical domain Tracing original requirements to dynamic behaviour Verification by V&V Domain Behaviour is allocated to Physical components Architectural Domain Verification by Verification by Tracing original requirements to physical components

20 Specification Development Process Principle SPECIFICATION PROCES Evaluation QA Contract Partly contractual Customer / system definition CRS Analysis / decisions System requirements SRS Trade off / Analysis Requirements allocation Contract subspecs Annex Verification Contract

21 Managing complex contract development Use systems engineering approach Usage of system development tooling Client-side (government) Requirements development and management Verification of customer requirements Determining the contract structure Project Baselining Determining System Performance Contractor-side Adapting the project information Deriving new requirements from contract requirements Verification and validation cycle

22 Databases within the Systems engineering Framework Requirements management Risk management Contract management Change management and tracking Document management Issues management Integrates other databases Commonly used brands in the Netherlands: Local or Web-based Highly Scalable to Project Needs (Local) Support Able to evolve with the project Project planning goes before buying a specific database! (a fool with a tool is still a fool)

23 Systems Engineering Tips Start as early as possible to determine the workflow Project Management should agree to adopt the tooling Make use of selected and proven tooling for each project phase Just do it, get experienced (Do not lecture theory) Ensure organisational embedding Make teams responsible, not one person only! Proclaim successes Bottom line for Small or Complex projects: you must have an information management plan and implement it

24 Thank you for your attention! So what is on your mind? Some questions maybe?

25