When the triangle (budget-time-performance) becomes a rectangle with a fourth dimension (safety)
The skills, methods, tools, and certifications needed/available are well known and embraced by project managers, and there are communities and organizations like the Project Management Institute that administer, structure, and present the scope of project management to support a professional level of performance. Some projects are in the scope of project management but have requirements beyond what is commonly known and experienced. As a result, the project manager must understand, incorporate, and manage such additional requirements.
This paper addresses safety requirements as a fourth dimension to the traditional triangle budget-time-quality and identifies what safety is about. It describes a case example of project conditions under safety and discusses some of the incorporation aspects and challenges within safety as part of the project. Furthermore, the paper includes considerations about the differences or similarities of the skills needed in order to run projects with safety in regard to the traditional three dimensions. The paper concludes with a discussion on the ethical aspects facing the project manager.
The Traditional Triangle and the Project Manager’s Responsibilities in Balancing the Three Dimensions
A series of project management competences are required when running a project. The traditional triangle with budget, time, and quality, which is the framework, must be balanced by the project manager. The project manager, the steering committee, the sponsor, and others are involved in assessing how to balance these main objectives within the boundaries of the project. The three dimensions are closely interlinked and tradeoffs between them are among the traditional challenges of the project.
Industries with a Fourth Safety Dimension for Projects
When running projects in some industries (e.g., medicine, nuclear energy, and air traffic management [ATM]), a fourth dimension is added to the project. The fourth dimension is safety.
Defining Safety in Air Traffic Management
Safety in ATM is a concept of defining, operating, and mitigating occurrence and the possibility of hazards to air traffic, whether in the air or on the ground. It aims at making the system safe where the system is defined as people, equipment, and procedures. This paper will discuss the implications of project management adhering to safety standards, thus incorporating the fourth dimension. Based on real project experience, the challenges and responsibilities in dealing with safety are presented.
The Fourth Dimension
Naviair, the Danish Air Traffic Service Management Provider
Naviair (http://www.naviair.dk/) is an air navigation service provider and is a state enterprise under the Danish Ministry of Transport. Included in the air navigation services are area control service in the Danish airspace as well as approach, tower, and ground control services at the Copenhagen Airports (ref. 2) of Kastrup and Roskilde and at a series of other Danish airports. Naviair has a staff of approximately 700 persons, most of whom are air traffic controllers and technical staff. It runs a business of approximately DKK 900m per year. The area control (Danish airspace) operated 545,040 movements in 2007 and the Copenhagen approach and departure control operated 257,591 movements in 2007.
The CASIMO Program
Naviair has gone through a comprehensive system, process, and equipment renewal program called CASIMO. The CASIMO program was initially introduced in 1995 and was rolled out December 31, 2008. The program included building a new air control tower, a new en-route ATM system, a new integrated tower, and ground control system and, furthermore, another approximately 50 projects within the areas voice, radar, IT, and facilities. The CASIMO program had a budget of EUR 180m plus costs of the Naviair work force of up to 80 people for 13 years and additional consultant fees.
The NITOS (Naviair Integrated Tower Operating System) Project
Previously, traffic to and from Copenhagen Airport (http://www.cph.dk/CPH/UK/MAIN/)was controlled from two different towers: an apron tower for controlling local ground traffic located near the terminal buildings and the air traffic control tower located near the runway complex. Taxiing traffic between the gate parking area and the runways was controlled from the apron tower while approaching and departing flights were controlled from the control tower.
The apron tower and the control tower have been integrated into the new control tower so that take-offs, landings, and taxiing traffic will be controlled from a single location. The air traffic controllers have a completely new information processing system to support this work, a system that has been developed in cooperation with the Canadian civil air navigation services provider Nav Canada. The Danish version of the system is called NITOS (Naviair), Naviair Integrated Tower Operating System.
Briefly, NITOS is an electronic system for recording and coordinating traffic movements in and around Copenhagen Airport. The technology behind NITOS is called the Integrated Information Display System/Extended Computer Display System (IIDS/EXCDS).
Earlier, all flights were recorded on a flight progress strip as soon as they flew into Danish airspace. This strip was a little piece of paper on which the air traffic controller noted flight data such as route and airline. As the aircraft moved through Danish airspace and approached for landing, this strip was handed over from controller to controller who kept track of traffic movements.
The new technology does away with the old-fashioned paper strips that have been replaced by advanced technology. In this way, the NITOS system can ensure that the handover of aircrafts from controller to controller takes place as smoothly as possible so that the air traffic is handled in the safest and most efficient way.
The tower and ground ATM system, NITOS, is a new electronic system integrating arrival and departure management with ground control and has 14 interfaces with surrounding systems. The system is operated via two touch screens and can be described as a very advanced bookkeeping system with interaction of the air traffic controller. The air traffic controller in the tower has NITOS as the main system, but operates a series of other systems to control and direct the air traffic.
At Copenhagen Airport on a busy day, there are about 850 take-offs and landings. It is the tower controller’s job to manage take-offs and landings on the runway so they are the ones issuing the permissions: “Cleared to land” and “Cleared for take-off.” The tower controllers are also responsible for safe aircraft taxiing between the gates and the runways.
The tower controller sits in the control tower and can see all aircraft and surface vehicles at the airport as well as the aircraft in the airspace in the immediate vicinity of the airport. The tower controller uses a variety of information in order to maintain the required separation between aircraft as well as between aircraft and surface vehicles at the airport. They receive information visually as well as out of the tower windows and by referring to a radar display.
Prior to departure, the tower controller gives the aircraft clearance to fly in the controller’s airspace section. This clearance contains a certain air route to be followed, an assigned altitude or flight level, and a four-digit transponder code that identifies the aircraft on the radar display.
The Project Conditions
The project schedule for prequalification, tender, negotiation, implementation, test, education, and roll-out was originally five years from the beginning of 2003 to the end of 2007, but the first two years were spent on some preliminary analysis and on February 1, 2005, there were still no requirements written, no allocated budget, a lack of qualified resources, an unmotivated project team, and no approved project scope. Since it would have enormous negative consequences if the CASIMO programwas delayed, NITOS had to go live with the rest of CASIMO on December 28, 2007. This left three years to run a five-year project. Naviair decided to have a professional consultancy take over the project and asked Deloitte Business Consulting (Deloitte) (http://www.deloitte.com/dtt/section_node/0,1042,sid%253D115167,00.html) in Denmark to take over the project management of NITOS on February 1, 2005.
The first challenges were to write the requirements specification, to allocate the resources, to get the budget and scope approved, and to initiate the prequalification process. We had to run a very tight day-to-day progress and result control and completed approximately 1,000 requirements in just over three months, got the approval of the project scope and budget, and had the important missing resources (tower air traffic controllers) allocated. The requirements were written as high-level specifications and had to be further detailed during development in corporation between the supplier and the project subject matter experts.
Safety standards (with regard to ATM systems) define the processes, documentation, and requirements that need to be followed, developed, and verified.
The commonly used standards for ATM software systems are IEC 61508 (IEC), EUROCAE ED-109 (EUROCAE, 2002) and EUROCAE ED-12B (EUROCAE, 1999). Although ED-109 is not formally recognized as a standard, it is a de facto standard. Software safety standards provide guidelines to prevent faults, identify and remove those faults inadvertently introduced, and generate arguments and evidence of guidelines followed. The system is not to be deemed “safe” by these guidelines, but a certain level of reliability is expected, although not guaranteed.
The safety standard (EUROCAE, 2002; EUROCAE, 1999) for NITOS included a process and documentation as illustrated by Exhibit 1.
Exhibit 1: Safety process and documentation
The main elements of Exhibit 1 and their purpose are described in the following in order to understand the context of the safety discussion in this paper.
Functional Hazard Analysis (FHA): How safe does the system need to be to achieve tolerable risks?
Preliminary System Safety Assessment (PSSA): Is the proposed design able to achieve tolerable risks?
System Safety Assessment (SSA): Does the system achieve tolerable risks?
Factory Acceptance Test (FAT): Test at the supplier’s location (factory) using software with simulated interfaces.
Site Acceptance Test (SAT): Test at site of system operations, including HW architecture test with simulated interfaces.
Total Acceptance Test (TAT): Test at site with full set-up and interfaces to surrounding systems.
Safety Case Part 1
- Function description
- Requirements (FHA)
- Preconditions and assumptions
Safety Case Part 2
- System description
- OED (Operational Environmental Description)
- Requirements reference
- Design (PSSA)
- Installation and integration
Safety Case Part 3
- Safety status (SSA)
- Change management
- Operation and maintenance (manuals)
Safety Case Part 4
- Education and procedures
Safety Log: Identification, registration, classification, and mitigation of hazards throughout the project.
The Danish Civil Aviation Administration (CAA-DK)
Safety documentation shall be inspected and some approved (e.g., safety cases) by the regulators. In Denmark, the regulator authority for aviation is CAA-DK (Danish Civil Aviation Administration, www.slv.dk). It is a government enterprise under the Danish Ministry of Transport. The CAA-DK also regulates aviation on the Faeroe Islands and in Greenland, with all civil aviation regulatory functions integrated within a single specialist body:
- Safety regulation,
- Security regulation,
- Airspace regulation, and
- Finance and performance regulation.
CAA-DK contributes to creating a framework that enables air traffic to operate as safely and efficiently as possible for the benefit of air passengers and society alike. The basis for flight safety is created by the CAA-DK in setting standards for the flight safety of civil aviation and in supervising compliance with the standards for commercial and private operators within civil aviation.
Safety Incorporated Into the Project
The safety dimension of the project calls for a safety manager to develop a safety management plan, to manage the development of the other safety documents as well as to ensure that the safety processes are adhered to. This role shall have a clear mandate to manage and approve all aspects of safety-related activities and results. However, the role must report to and be under the management of the project manager, as, ultimately, safety is the project manager’s responsibility.
It must be proved, argued, and verified by experience and calculations that the design, development standards, and functions of the system are safe with regard to tolerable measures of safety classification which is a categorization of severity related to probability. For example, the definition of severity 1 is: sudden inability to provide any degree of air traffic control (including contingency separation measures within one or more airspace sectors for a significant period of time). The probability and severity result in a safety classification from A to D where C and D is tolerable for the NITOS ATM system but A and B must be mitigated. If a hazard that is classified as B is to be accepted, it must be approved by the CEO of the air navigation service provider. That the design and functions of the system are safe must be documented by the supplier (or the development entity) in the safety documentation and be approved by the safety manager and project manager. If, for example, the system design cannot be proven to be safe, it must be changed or amended. This process is likely to include negotiations and trade-off in relation to budget, time, and requirements as the requirements specification and/or contract with the supplier/developer might be in conflict with what needs to be done with regard to safety.
The activities in NITOS included seven human interface (HMI) workshops to define and specify detailed functions and screen layouts. The HMI activities not only address requirements but also the safety requirements derived from the safety process. Thereby, the system definition and development must incorporate the system and safety requirements both in parallel and as a joint activity. Likewise, test activities must include a test of requirements (functionality, performance, etc.) but must also verify and document that no safety issues are emerging with regard to tolerable safety classifications, e.g., that the system does not produce “credible corruption.” Credible corruption is an error in function or display that is not recognized as an error by the air traffic controller, thus potentially leading him to manage the air traffic in a way that increases the likelihood of hazards. An error as freezing of a radar display could take time to be recognized, given a wrong picture of the location of aircrafts.
The safety requirements and documentation significantly add to the administrative burden, resource requirements, schedule, and cost of the project and must be assessed during the planning phases as failure to plan for those constraints will be a showstopper to the project. The testing of the system must be construed with the ability to verify functional requirements and each error must also be safety classified. The correction, requirements change, or mitigation of an error must be safety analyzed an approved before the change can be accepted. Testing in itself is subject to a safety approval to ensure that no test data can corrupt operational network and that no test data can be led to operational systems. There is a formal safety procedure for each test to address system changes and potential effect of testing on operational systems which must be planned for.
For the development of the NITOS system, the supplier of the software was inspected in a critical design review (CDR), which was a gate for the supplier to obtain a CDR certificate. The CDR was conducted at the supplier’s site and was carried out by Deloitte associates within architecture and software development and was a code review and a series of questions about the robustness of code, development standards and documentation and had a parallel questioning about the supplier’s internal safety procedures and training of developers/personnel involved in the NITOS project at the supplier’s side.
During contract negotiations or specification of the project, there is a challenge in agreeing on the responsibility of safety as the supplier will demand mitigation of additional costs if he or she is to take on the responsibility of safety approvals by the regulators. The challenge is that these approvals can be very costly (resources and schedules) as the documentation and safety analysis is done in parallel to the project schedule and because the regulators can request additional documentation, further verification and, ultimately, changes to the system.
A supplier who is working in industries with safety requirements is expected to have all the necessary internal safety procedures in place, and therefore, are more likely to accept the responsibility (and extra costs) of safety approvals. On the one hand, an IT system supplier without these procedures would have to partner up with a specialist within safety and would probably also have to add significant additional costs of safety contingencies.
In order to ensure the focus of safety, all project team members need to be educated in safety processes and requirements. For the NITOS system, each human machine interface (HMI) workshop included a set of safety sessions assessing all specifications within the project team and also within external safety competencies. Considerations about safety in specifying a system is not natural, and therefore, the safety workshop and the frequently incorporated safety sessions during the project increase the safety awareness among project members, culminating in the testing and approval phases where there must be a high degree of safety focus.
The project manager (and safety manager) will constantly be challenged by the budget-time-quality constraints being in opposition to safety and must address the decisions based on an understanding of the severe and additional responsibility that the safety dimension imposes on the project. The project manager must sign the safety documentation and thereby “guarantee” that safety has been dealt with according to the safety standards and, ultimately, that hazards will occur with no more than a specific probability. The challenge is that there cannot be a trade-off strategy specified between safety and the other dimensions because although the tolerance level for safety is clear, it is not obvious when in fact an assessment is satisfactory with regard to prioritizing (e.g., budget over safety). So planning for safety requires a clear picture of the impact of safety elements on each of the project phases and activities.
As part of the requirements specification and contract, safety requirements, documentation, and processes must be specified. Furthermore, training of the project team, planning of safety workshops and approval sessions must be agreed with internal and external approval entities, and it must be assured that the project steering committee and company management agree with/approve the safety scope, resources, and costs of the project. In addition, they have to empower the project manager to manage safety at the highest level of priority.
New or Standard Skills to Deal With the Fourth Dimension
Incorporating safety can be argued as being a standard skill for a project manager in line with, for example, risk management with the argument that, in general, safety management equals risk management and that risk assessment and mitigation is dealing with the same kind of processes and methods. On the other hand, safety must be incorporated into every aspect of project documentation and development which makes the safety discipline different from risk management where risk management can accept a risk or set aside a cost for mitigation and then carry on, which safety cannot.
As safety comes with its own processes and methodology (variations depending on the standard), it has its own role (safety manager), documentation, and approval setup that must not only be incorporated into every aspect of the project, but also has to be dealt with in a separate tread.
Safety also includes a responsibility beyond costs and requirements as it deals with the potential loss of lives. Safety requires operating systems to be developed under a certain process with functions operating and interacting as depicted in the safety standards and hardware to be able to verify, e.g., MTBF (mean time between failure), which, in principle, makes the safety constraints governing even before the project has begun. These are examples of safety being even more comprehensive than the other “normal” dimension skills and experiences expected to manage those.
An experienced project manager deals with different methodologies and project types and would be able to adapt to the safety dimension, given that the role as a safety manager can be staffed by a safety expert or that such an expertise is supporting the safety manager role of the project.
The Ethical Responsibility of the Project Manager
There are two aspects of responsibility that a project manager faces when running projects with the safety dimension, which is balancing dimensions as a calculated and defined activity and the considerations about potential loss of lives due to decisions on a vaguer base. The calculated activity is balancing safety with the other dimensions and how to measure the success of the project when, e.g., a budget overrun has occurred due to safety, as safety implications and consequences will emerge/occur after the project has ended. For example, the NITOS system will theoretically be able to cause a fatal hazard in seven years after being taken into operation.
Companies dealing with safety would normally fully understand the importance and constraints of safety but as the safety assessments and decisions are typically tied to deep or expert understanding of the issues, the project/safety manager almost have a veto against all decisions which is naturally countered by a certain pressure from the management, the client or the user to perform on the other three dimensions. The experienced project manager with high integrity is able to withstand the direct or underlying pressure whereas the inexperienced project manager could be tempted to make hasty decisions to please the management.
To support the top priority of safety, a company like Naviair has two project-independent entities in order to ensure safety: one within the project organization and one within the operational organization. With the regulator as a third safety instance, there is zero tolerance for compromising safety as the foundation for an ANS (air navigation service) provider company is safety.
It is easy to judge a budget overrun but it is not as easy to assess the advantages by prioritizing safety. A decision to accept a safety issue as being addressed satisfactorily, is adding to the total safety level of the system. However, it is not really possible for the project manager to understand fully the likelihood of the system to cause direct or indirect incidents. Overall, all ATM systems together shall only contribute to the occurrence of one fatal incident (e.g., a period of 10,000 years). As this is very difficult to comprehend, the scope of the project/system is to assess fault tolerance and robustness with regard to interfaces and data quality. Nevertheless, when the project manager is to sign the safety documents and hand over the system, he or she is left with a gut feeling and his conscience. The project manager must ask whether he or should would trust their own life to the system when arriving or departing from an airport by airplane.
Safety is seen as an industry-specific area that has different standards but which introduces the same overall constraints on a project. The safety requirements provide specifications and guidelines for processes, people, and equipment and demands documentation of safety.
Safety is a fourth dimension and belongs as an addition to the time-budget-quality connections as an equal and separate element and must, in principle, be considered as part of all project activities.
Introducing safety in project management is imposing a set of challenges that relate to safety responsibilities and competencies of the supplier, change management, safety training, increasing safety awareness, and balancing the triangle time-budget-quality.
The skills required are somewhat similar to the skills required within, risk management, as an example, but they differ in many ways, and therefore, can be stated as a different set of skills compared to those normally contained in the project manager’s toolbox.
A critical challenge for the project manager is to deal with the ethical aspect of safety because the project manager is ultimately responsible for the potential loss of lives and must, despite well-documented safety standards, have serious considerations and decisions about a judgment if the inherent safety resulting from the project delivery is enough and sufficiently balanced and prioritized.
EUROCAE ED-109 (2002) Guidelines for Communication, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance
EUROCAE ED-12B (1999) Software Considerations in Airborne Systems and Equipment Certification.
IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems
© 2009, Leith Noval
Originally published as a part of 2009 PMI Global Congress Proceedings – Amsterdam, Netherlands