Metrics for Project
Management
An Experience Report from a
Successful e-Government
Software Project
Project: UKSMA Conference Wolverhampton
Document–ID: Metrics
V03 d
Version: V1.0-08
for
Project
Issue of: 25. August 2003
Replaces: W0.3-02
Author: Dr. Thomas Fehlmann
Confidentiality: Publication
Distribution: ISBSG, UKSMA
Carbon Copy: SwiSMA
Member of the
Management
Change Control
The following table documents the actual development stage of this document.
Every change made to this document requires a new issue.
Modification Notice
Author
Version
New document
Dr. Thomas Fehlmann
X0.1
14.5.2003
Added acquisition story
Dr. Thomas Fehlmann
X0.2
21.5.2003
Submitted to UKSMA conference
Dr. Thomas Fehlmann
W0.3
29.5.2003
Reviewed and finalized
Dr. Thomas Fehlmann
V1.0
25.8.2003
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 2 of 15
Date
Abstract
This case study explains the Six Step To Completion – method for progress tracking in
projects. Progress tracking is a project management task, but it has specific effects in
software projects. In this case it was the first time software people had to get used to
metrics and that they draw some benefit out of it.
The critical success factor is to link software quality assurance to progress reporting. A task
is no longer finished when the planned effort had been spent. We want the deliverables
resulting from that task be reviewed and approved. Based on that data we track actual
duration and effort spent in projects and compare with plans.
The effect is surprising: software projects suddenly behave “normal”. Teams stay focused
on the planned tasks and keep to the deadline. Although bad effort estimation cannot be
completely avoided, it is detected in the very early stages of the project. Delivery rates
become apparent from the beginning.
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 3 of 15
Table of Contents
Chapter 1:
1.1
1.2
1.3
The Problem
e-WorkPermits – an e-Government application
The Project
The Dilemma
5
5
5
6
Chapter 2:
2.1
2.2
2.3
2.4
The Approach Taken
The Taskforce
The Six Step To Completion – Metrics
Integrated Quality Assurance
Progress Metrics for Consensus Build-up
7
7
7
8
8
Chapter 3:
3.1
3.2
The Successful Outcome
The Effects of Visualization
Why This Works
9
9
9
Chapter 4:
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Tools And Methods
The Project Database
Visualization using Excel
Data Capture with Personalized Tickets
Data Capture in the War Room
Automated Data Capture using a Project Repository
Relation to Other Software Metrics
Conclusion
10
10
10
12
13
14
14
15
Index of Figures
Figure 1: The Six Step To Completion Model for Measuring Objective Evidence
Figure 2: Sample Project Management Overview
Figure 3: Sample Progress Track with Issue History
Figure 4: Sample Personalized Ticket
Figure 5: Wall Sized Print of the Progress Track as Paper Tool
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 4 of 15
7
11
12
13
14
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
The Problem
e-WorkPermits – an e-Government application
The Department for Labour and Economy of the Swiss canton of Zurich decided
to undertake a bold step towards e-Government in 2002 when starting a project
to ease the issue of work permits.
Especially in the ICT industry, but as well for banking and pharmaceuticals, the
need to exchange international experts is apparent. In many other aspects of
economical life, having the ability to transfer experts from one country to another
is decisive for the attractiveness of a site. Thus setting up a web site that allows
applying for a work permit through the Internet and – if the application is all–
inclusive for the needed documents and the applicant fulfils the law’s requirements – issuing the permits instantly is a major competitive advantage.
The Project
The trouble started at the very beginning. Having no expertise in setting up a
project, the government department hired a consulting company to write an
invitation to tender. This document did not mention project methodology or
project management at all. Thus it was not required, and no details specified,
therefore the government department had no means of discrimination.
A large consulting company won the contract and subcontracted several
specialists for creating software and setting up the service on the Internet. The
same system was to provide workflow support for the civil servants of the
several agencies involved in the review and approval of the applications. Using
the same data for external and internal users, the system should maximize
effectiveness.
However, despite allocating around 30% of the total price for project management, the consulting company was not able to provide a skilled project manager.
The first holder of the position left the project within the first two months, the
second tried to manage the project by hiding the relevant information. There
was no project plan, no project organisation, no roles and responsibilities, and
for sure no quality management or quality plan. All he had was a Gantt chart,
mentioning activities lasting two to three month, by a total planned project
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 5 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
duration of about seven month, and a To-Do list that an impressing tendency to
grow in size.
Thus the project went the way all such projects must go: It hardly made the first
milestone, already with a long list of To-Do’s, and completely missed the second.
The author remembers his first project steering meeting where the project
manager stated that one of these three-month tasks is “98% finished”. The
author remarked that, when this statement had been true the day before the
meeting, this task must have been finished by this very afternoon. Obviously it
was not. In reality not even the hosting was prepared, and the software was
buggy and very late.
The Dilemma
Obviously this was not state–of–the–art project management. The contract did
stipulate, but not substantiate project management. It did neither mention a
professional (PMI) certificate, nor any specific project management method.
When the author joined the project and proposed to use progress metrics to the
supplier, he did not accept the suggestion because it was not foreseen in the
contract.
For the government department, there was no other way than to insist on the
schedule as stated in the contract but they had to let the supplier decide how to
meet its obligations. All they could do, and what they did, was to spend
additional money for a second project manager who should take over after
completion of the contract, and for independent testing, to avoid having to rely
on the supplier’s testing records. We had to endure another three missed
milestones before the supplier finally admitted that the delivery date had passed
and the contract failed.
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 6 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
The Approach Taken
The Taskforce
Thus the government department installed a taskforce to take over and lead the
project to its goal. The primary objective was that the supplier finished the
delivery of the web application as soon as possible; thus it was not an option to
stop the project. So how do you deal with people from whom you depend and
who can listen neither to you nor to common lore nor even simply to good
reason?
The Six Step To Completion – Metrics
The answer was a very simple metrics that was so simple those people from the
supplier did not even understand that it is a metric indeed.
We started with a To-Do list because that was a terminology people could follow.
However, each of the To-Do’s was connected to a distinctive deliverable, as
every project manager does with tasks in his project plan. That deliverable
uniquely identifies the To-Do and gives objective evidence for completion of the
task. Professionals with an auditing background understand the term “objective
evidence”. Instead of arguing if the task or To-Do had been completed or not,
the evident status of the deliverable tells us without asking people’s opinion.
Figure 1: The Six Step To Completion Model for Measuring Objective Evidence
Input
Assignment
Assignment
Template
Template
Idea
Idea
Draft
Draft
Output
10%
Draft
Draft version
version
30%
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Review
Review
Finalization
Finalization
Review
Review report
report
15%
Page 7 of 15
20%
AppApp
Approval
roval
Release
Release
Operations
Operations
Distribution
Distribution
15%
10%
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
Integrated Quality Assurance
All we need is to provide a project repository where to post draft versions, review
reports, released versions, and evidence for operational use such as distribution
lists for documents and build logs for software.
We use the Six Steps to Completion – model to measure progress based on
objective evidence for completion for each of the six steps. The idea stage
accounts for 10% of the total completion metric; the draft stage for another
30%. Then comes the review stage with 15%, the finalization stage with 20%,
approval gives 15% and when put into operational use the last 10%. The last
stage is equivalent for making the deliverable available for developers who have
to rely on it and does not necessarily refer to the end users.
Progress Metrics for Consensus Build-up
Originally these percentages were just a guess. However, in the very first project
where such completion metrics had been used (1999) we discovered that these
percentages correspond quite neatly with the total task duration (not the effort!)
such that we started using the completion percentages for Gantt chart tracking.
The percentage values set forth in Figure 1: The Six Step To Completion Model
for Measuring Objective Evidence seem to fit pretty well for creating documents,
preparing workshops, training, or writing software. Thus, completion rates give
an accurate estimate for the actual task duration. For example, if the
completion rate is 40%, it means that we still need 60% of the total duration,
i.e. 1 ½ times the duration that had already passed. If that was not foreseen by
the project plan then you better update the plan right now to make it consistent
with reality and manage expectations.
Only tasks such as meetings – with the minutes as deliverable – and testing may
have somewhat different percentages.
We have since 1999 a record of around forty projects in a dozen different
organizations that followed the same pattern with a variation below ten percent.
The grading of the steps varies in nine degrees between “just begun” and
“completed”. Thus it is possible to acknowledge work in progress within the Six
Stages To Completion. Also it often happens that review or testing activities and
finalization go in parallel, thus the familiar pattern of two green stages followed
by two yellow ones, see the last line in Figure 3: Sample Progress Track with
Issue History. More questionable it is when deliverables are already in use while
still under finalization, but it happens too, e.g. in object-oriented development.
The benefit of completion metrics based on reviews and approvals is that they
reflect the degree of consensus reached for the deliverables. Reviews and
finalization work still going on, or missing approvals clearly indicate missing
consensus about the delivered results. Thus progress metrics are very
important for management. This worked well in the e-Government project.
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 8 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
The Successful Outcome
The Effects of Visualization
You never forget when the supplier’s project manager first noted that his To-Do,
which he thought having finished by “85%”, counted only for some 30%. The
taskforce met then weekly in a room with the actual Six Steps To Completion
displayed prominently at a wall. There was not a single date missed. And
interestingly: even the taskforce cost remained within budget.
Why This Works
Obviously this was more than just a psychological trick. The reason is very
simple: The Six Steps To Completion represents nothing else than ordinary
quality planning. Every serious Quality Plan must provide exactly that: a
reviewing method and an approval procedure for every single deliverable in the
project.
Often quality planning is done at the beginning of the project (although not in
this instance) but then not executed because of other priorities shovelling up.
The effect of such missing quality assurance is not felt immediately, in contrary.
It might even felt favourably for the moment because the QA resources are now
free to do even more draft development. This seemingly positive experience will
then be iterated again and again until it is too late and the quality problems start
becoming apparent.
Exactly that happened in the early stages of the e-Government project, and was
the reason why the supplier’s people were not able to listen.
The Six Steps To Completion – metrics makes this impossible. It short-circuits
the quality plan to the project plan, or in this case, to the To-Dos. The team
silently agrees on the necessary quality assurance being done at the root,
causing significantly less bad surprises later on.
The web site www.workpermits.zh.ch went on-line 20 February 2003, three
months late with regard to the original schedule, but three weeks earlier than
expected in the revised schedule after the taskforce took over. All To-Dos
including all the quality issues discovered earlier were resolved, the hosting
strategies established, and the site started to receive very excited feedback.
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 9 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
Tools And Methods
The Project Database
Since 1998, Euro Project Office AG developed a tool1 based on MS–Project and
Excel to integrate the Six Steps To Completion – method into project planning. It
was developed and refined during the sequence of projects that the Euro Project
Office supported.
The basic philosophy was usability. This included the need to let the project
manager use his tool without any restriction. This led to the solution to use the
database of MS–Project to store all relevant project data, such as deliverable
specifications, quality planning, quality records, and issues, on top of the data
already present in MS–Project such as planned and actual schedule, planned
and actual effort and cost, resource allocation and usage. All the MS–Project
functionality is thus available but with significant enhancements.
As already explained, the completion rates collected by the tracking process
become in turn available again showing the actual completion percentage of the
planned tasks.
Visualization using Excel
The choice of Excel for visualization makes it possible to easily adapt more
functionality and analyze the project for later improvements. Excel as GUI is
possibly not the best choice, but using VBA and the (loop-free) formula
programmability of Excel allows for fast implementation at a high Function
Points2 (FP) delivery rate. We make more than one FP per hour, or about six
times more than Java or C++. Such a delivery rate outperforms some of the
shortcomings of VBA.
1 The tracking software is Open Source and can be found in the /ch/open project methodology
(www.ch-open.ch, or www.swisma.ch). However, since it is embedded in MS Office, it does not
install without proper support, and is not self-explanatory. At least, you need training, and you
need a project office to run the tool.
2 Unadjusted Function Points according IFPUG 4.1
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 10 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
The available Excel reports include
Management overview of overall progress
Specifications for each deliverable in the project
Progress Track including issues per deliverable
Quality Plan per deliverable
Quality Records and access to deliverables
Pricing per deliverable
Test stories per deliverable
Summary test results
Efforts planned and actual per deliverable and per resource
Summary planned and actual efforts per deliverable
Progress data per project phase
Costs and earned value per project phase
Costs and earned value and expected trend per accounting period
Planned Completion
32%
Ap
pro
v
38%
34%
26%
Schedule Trend
Re
ad
y
41%
10%
Fo
rU
se
15%
al
20%
Fin
ali
za
tio
n
30%
15%
Re
vie
w
Completion Rate
30%
Dr
Management Overview
10%
Ide
a
Weight
25. Januar 2003
aft
Figure 2: Sample Project Management Overview
19%
16%
Overall Progress
Actual Date / Planned Date
Completion Rate
25.11.2003
100%
06.10.2003
90%
17.08.2003
80%
70%
Re
ad
yF
or
Us
e
pr
ov
al
Ap
on
Fin
ali
za
ti
Actual Dates
Re
vie
w
0%
Id
ea
25.11.2003
06.10.2003
10%
17.08.2003
20%
13.07.2002
28.06.2003
30%
01.09.2002
09.05.2003
40%
21.10.2002
20.03.2003
10.12.2002
29.01.2003
50%
10.12.2002
29.01.2003
21.10.2002
60%
01.09.2002
20.03.2003
Dr
aft
09.05.2003
13.07.2002
Planned Dates
28.06.2003
These reports substitute all other project status reports. Because it is based on
object evidence, such reports can be generated by the project office and need
but comments by the project manager. Thus it replaces administrative work by a
service, and saves cost in the project.
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 11 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
Issue Reporting
Due
Date
De
lay
ty
(D
ay
s)
100%
ori
n
Ap
pro
va
l
Re
ad
yF
o
Ide
a
Start
Date
10%
Pri
15%
rU
se
20%
mp
le
Ra tion
te
15%
Resp.
Co
30%
Fi n
ali
za
tio
10%
Re
vie
w
30%
delivered
Result ID Deliverable
Dr
aft
Figure 3: Sample Progress Track with Issue History
History Records
1
Proposal Development
1.1
Opportunity Memo
AM
6-Jan
100%
1
6-Jan
3
1.2
Risk Analysis
PM; RM;
Arch
6-Jan
100%
4
16-Jan
6
1.3
Customer Value Analysis
6-Jan
100%
5
K 13-Jan
4
1.4
Quality Plan
PM; RM;
TPL1; TPL2;
AM
QM
13-Jan
100%
2
27-Jan
13
1.5
Project Plan
PM & Team
17-Jan
100%
3
26-Feb
43
1.6
Statement of Work
PM & Team
13-Jan
93%
4
25-Feb
46
1.7
Project Calculation
PM
6-Mrz
70%
3
14-Mrz
58
17.07.2002: Too many open points.
We conduct a 2nd reviewby 18.3. to get agreement on the open points.
1.8
Business Plan
AM
13-Jan
62%
3
K 14-Jan
-1
1.9
Contractor Qualification
Buyer
25-Feb
100%
5
5-Mrz
44
17.07.2002: Project Calculation complete. Formal approval asap after project calculation is
final.
Get approval immediately after 2nd reviewon 20.3.
1.10
Select Contractor
Buyer
5-Mrz
100%
3
13-Mrz
50
1.11
Proposed Solution & Commercial PM; QM;
Arch; AM
Offer
7-Mrz
100%
3
T 17-Mrz
46
2
Analysis & Design
93%
17.07.2002: Who is responsible for gathering marketing data?
11.06.2002: Marketing department task force to provide available data until 20.1.
17.07.2002: Delay because of resource problems.
Search for available skills. Result due by 20.3. Final Project Organziation must be
communicated to customer.
17.07.2002: Some minor points need clarification by the subcontractor
Subco will provide statement by 18.3. Consolidate with project plan.
70%
2.1
Requirements Engineering
2.1.1
Clickable Prototype
Dev2; Dev3; 24-Mrz
Arch
76%
3
5-Mai
66
2.1.2
Business Process Analysis
Dev1; Arch; 31-Mrz
Exp; TPL1
45%
3
5-Mai
61
2.1.3
Use Case Analysis
Arch; PM;
Customer
5-Mai
52%
3
19-Mai
68
58%
21.07.2002: Missing feature added
12.07.2002: Prototype lacks the priority setting feature
08.04.2003: 2nd reviewplanned for 11.4.2003
In the past project experience, it was possible to integrate with an ERP tool such
as SAP, or with configuration management such as CVS.
The tool is also available as an option to SCODi4P from Triloga1, or as an add-on
to Bugzilla2. Currently we investigate migration to a DBMS to improve the GUI.
Data Capture with Personalized Tickets
The progress-tracking tool is not only integrated with the project repository, but
also with the reporting process of each team member. Every team member gets
his own personalized ticket, either via the Intranet, the project home page or any
other suitable communication tool (including paper).
The tickets integrate all of the reporting needed in a project, including time
reporting.
1 Contact Triloga AG, Lucerne, Switzerland; www.scodi4p.com
2 Contact GMC Software Technology, www.gmc.net
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 12 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
Figure 4: Sample Personalized Ticket
2.1.1
Clickable Prototype
Dev2;
Dev3;
14-Nov-02
01. Nov
10. No v
24.3
30. Okt
76%
15. No v
Due
date
De
lay
Deliverable
10% 30% 15% 20% 15% 10% 100%
Re
vie
w
Fin
ali
za
tio
n
Ap
pro
va
l
Re
ad
yF
or
U
Co se
mp
le
Ra tion
te
Result
ID
Priority
Dr
aft
Requirements Engineering
Ide
a
17.3.
5.5
179
07. Nov
Quality Measurements
Release Identification
Version Under Test
Delivery item identification
Actual Vers Tool
Pilot Functionality
Prototype Solution
Cycle 1
V02
ppt
Improvements
12
45
36
Function Points
8
11
0
130
Quality Assessment
1
Reviews
1
Re-Factoring Runs
Test Case 0
Average Test Success
3.0
Grade 0 - 5
Regression Tests
Average Test Completion
100%
Assessment Result
Usability Test passed.
Found that requirements need to be
refined for various user categories.
Reviewed by
Approved by
Customer
Arch
PM
Date of Approval
Ba
se
lin
e
Bu W o
r
dg
et k
Ac
tua
Pe l Wo
rfo
r
rm k
ed
Pe
rfo
Th rme
is
Pe d
rio
Es
d
tim
Co ate T
mp
o
let
Ex
e
pe
c
Co ted
mp
A
let t
i on
Wo
rk
Ov
e rr
un
Work Reported (in Hours)
Specification
72
82
Working on this task
Arch
Dev2
Dev3
Rapid prototype displaying the
functionality needed.
2
32
48
8
7
97
25
1
5
2
0
7
0
3Hours
44
50
8 h/d
0
5 d/w
0
4 w/m
Data Capture in the War Room
Although electronic communication means are abundant and sometimes
indispensable, we made excellent experience with a more traditional way for
data capture. Instead of distributing and collecting electronic tickets, a wallsized print of the progress track sheet (similar to Figure 3: Sample Progress
Track with Issue History) serves the same purpose. The team members report
progress using colored markers, which they glue to the wallpaper. It requires
more physical presence of the project office that has to input the data captured
on the wallpaper into the Excel sheet but minimizes disruption for the develop-
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 13 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
ers and maximizes their sense of responsiveness and ownership. This effect
could be worth considering as a trade off.
Figure 5: Wall Sized Print of the Progress Track as Paper Tool
Automated Data Capture using a Project Repository
If a project repository is available, data capture is even more automated. The
draft deliverables, quality records and approvals can be tracked in the project
repository and progress track relies less on people’s judgement. Team members
still have to update time and issue reporting on the tickets and may want to set
the draft or the review to some intermediary progress grade (yellow marker).
However they can no longer pretend be in finalization state without at least a
preliminary review report being available in the project repository1.
Relation to Other Software Metrics
Bad effort estimation cannot be completely avoided. Using the Six Steps To
Completion method, errors in estimation are detected in the very early stages of
the project. Delivery rates become apparent from the beginning.
1 For a project repository that integrates well see itp.montana (www.itp-solutions.ch, in German)
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 14 of 15
UKSMA Conference Wolverhampton
Metrics for Project Management
Publication
Dr. Thomas Fehlmann
Version V1.0-13, 23 September, 2003
When the team starts understanding that the progress metrics are not a threat
but a valuable help for them, their reluctance against using metrics vanishes.
The GMC team in Hradec Králové (Czech Republic) integrated the method in the
open source tool Bugzilla. Thus tracking project tasks and bug fixes becomes
the same process. Developers have only one tool that supplies them with new
tasks, with their specifications, test cases, records test results and review
finding, and tracks effort and progress. It provides progress metrics and bug
statistics at once, with no pain.
Clearly we would like to add a software sizing metric to the tool. However this
yields some specific problems. The work breakdown structure of a software
project does not automatically coincide with the software boundaries. Sometimes it is possible to group development tasks such that they fit with logical
boundaries, but it make not always sense.
Nevertheless, such an approach is very promising and deserves further
investigation.
Conclusion
The Six Steps To Completion – metric is easy to use, simple and straightforward.
In the beginning, it is often not even perceived as a metric, it stirs only little
opposition, and almost no fear against being measured.
On the other hand, the effects are tremendous. If planning and estimation was
correct, the schedule will be respected. The metric establishes a short – circuit
between plan and team. The project manager perceives unrealistic assumptions
and estimations within a single reporting period. We most often use one week,
sometimes two weeks as a reporting period. Thus corrective actions can be
taken immediately when needed.
Metrics provide huge benefits for people and organizations. Progress metrics
are the door opener for other metrics dearly needed for today’s complex tasks.
Moreover, many more sophisticated metrics such as software sizing using
Function Points or bug statistics provide higher value when combined with
progress metrics. This is why we us no metrics without progress metrics in our
software projects.
METRICS FOR PROJECT MANAGEMENT V10.DOC
Copyright © 2003 Euro Project Office
Page 15 of 15