22 CrossTalk The Journal of Defense Software Engineering July/August 2009

Goals that are measured will beachieved. In almost every area of life,

setting goals and monitoring achievementare the foundations for success. Take arelay team in track or swimming. What dri-ves these athletes to continuouslyimprove? There are always competitors tobeat, a number 1 ranking to achieve, or arecord to break. Many of the same driversapply to the software industry. Softwaredevelopment is a human activity and, assuch, demands that organizations continu-ously improve their performance in orderto stay in business. Software measurementis a primary approach to control and man-age projects and processes and to trackand improve performance.

The way software measurement is usedin an organization determines how muchbusiness value that organization actuallyrealizes. Software measurements are usedto:• Understand and communicate.• Specify and achieve objectives. • Identify and resolve problems.• Decide and improve.

Today, improving a business (and itsunderlying processes) is impossible with-out continuous measurements and con-trol. For some industries and organiza-

tions, this is demanded by laws (such asthe Sarbanes-Oxley Act) and liability regu-lations. For all organizations, it is a simplequestion of accounting and finance con-trol. The measurement process is aninherent part of a business process (seeFigure 1). Therefore, software engineer-ing—as part of the product developmentbusiness process—also needs controllingand measurement. Software measure-ments include performance measurement,project control, and process efficiency andeffectiveness.

Measurements are management tools.Consequently, measurements must begoverned by goals such as reducing pro-ject risks or improving test efficiency, oth-erwise they simply build up into data ceme-teries. Figure 1 shows this objective-drivengeneric measurement process, known asE-4 [1]:1. Establish concrete improvement or

control objectives and the necessarymeasurement activities.

2. Extract measurements for the estab-lished performance control needs.

3. Evaluate this information in view of aspecific background of actual statusand objectives.

4. Execute decisions and actions to

reduce the differences between statusand objectives.The E-4 measurement process is

based on the Deming Cycle (Plan, Do,Check, Act) and extends classic measure-ment paradigms, such as the goal-ques-tion-metric approach, by adding an imme-diate action-focus. It follows the observa-tion that to effectively and continuouslyimprove a process, it is important to firststabilize it, keep it in its specification lim-its, and continuously improve it [2]. Themajor difference is E-4’s clear focus ongoal-oriented measurement and executionof decisions at the end of the four steps.

The E-4 measurement process is gov-erned by ISO/IEC 15939 [3], a standardthat summarizes how to plan and imple-ment a measurement process. It consistsof two parts: The first part establishes themeasurement program and prepares itwithin the project or organization. Thesecond part is about execution: Youextract data, evaluate it, and execute cor-rective actions based on the outcome ofthe measurement analyses. The secondpart—driven by the first part—sets thestandards and defines what to do with themeasurements. It is not enough to simplycollect numbers and report them.Measurements are only effective if theyare embedded as tools to support deci-sion-making and to drive the implementa-tion of decisions. For the fundamentals ofsoftware measurement and practical solu-tions, I refer to the book “SoftwareMeasurement” [1].

Project MeasurementProject measurement is the major applica-tion of software measurement. Softwaremeasurement is an absolutely necessaryprecondition for project success, but onlyone-third of all software engineering com-panies systematically utilize techniques tomeasure and control their product releas-es and development projects [4].

The goal of project measurement is tomaster the project and finish it accordingto commitments. What is needed is a wayto determine if a project is on track or

Software Project and Process Measurement

Software measurement is the discipline that ensures that we stay in control and can replicate successful processes. It applies to

products (e.g., ensuring performance and quality), processes (e.g., improving efficiency), projects (e.g., delivering committed

results), and people (e.g., evolving competence). This article discusses software measurement and provides practical guidance for

project and process measurement.

Dr. Christof EbertVector Consulting Services

Figure 1: A Generic Measurement Process

942134_Text:Aug2004.qxd 6/12/09 3:21 PM Page 22

Software Project and Process Measurement

July/August 2009 www.stsc.hill.af.mil 23

not. Whether it is embedded softwareengineering, the development of a soft-ware application, or the introduction of amanaged IT-service, demand outstrips thecapacity of an organization. As a result,I’ve observed the acceptance of impossi-ble constraints in time, content, and cost;as a direct consequence of acceptancecomes an increase in churn and turmoil—as well as budget overruns, canceled pro-jects, and delays. Still, far too many pro-jects fail to deliver according to initialcommitments simply because of insuffi-cient or no adequate measurement.

While many organizations claim thatproject work is difficult due to changingcustomer needs and high technologydemands, the simple truth is that they donot understand the basics: estimation,planning, and determining progress dur-ing the project. Consequently, they fullylose control once customer requirementschange.

Project control can help in avoidingthese problems by answering a few simplequestions derived from the followingmanagement activities: • Decision-making. What should I do?• Attention directing. What should I

look at?• Performance evaluation. Are we

doing a good or bad job? • Improvement tracking. Are we

doing better or worse than in the lastperiod?

• Target setting. What can we realisti-cally achieve in a given period?

• Planning. What is the best way toachieve our targets?Project monitoring and control is defined as

a control activity concerned with identify-ing, measuring, accumulating, analyzing,and interpreting project information forstrategy formulation, planning, and track-ing activities, decision-making, and costaccounting. As such, it is the basic methodfor gaining insight into project perfor-mance and is more than just ensuring theoverall technical correctness of a project.The most important elements are the exis-tence of a closed loop between the objectbeing controlled, the actual performancemeasurements, and a comparison of tar-gets against actuals. Figure 2 shows thiscontrol loop. The project with its underly-ing engineering processes delivers results,such as work products. It is influenced andsteered by the project goals. Project con-trol captures the observed measurementsand risks and relates them to the goals. Byanalyzing these differences, specificactions can be taken to get back on trackor to ensure that the project remains ontrack. These actions serve as an additional

input to the project beyond the originalproject targets. Making the actions effec-tive is the role of the project manager.

A client recently asked us for help inimproving engineering efficiency at theirorganically grown embedded softwarebusiness. Software costs initially did notmatter when there were only a few engi-neers. As things progressed, softwaredominated hardware and cost increaseswere out of control. Customers liked thetechnology but increasingly found qualityissues and, when the customers madeaudits, did not really find a decent engi-neering process. Our Q&A with the clientwent like this: Us: “How do you set up a software pro-

ject?” The Client: “Well, we take the require-

ments, build a team of engineers, andfollow our V-shaped master plan.”

Us: “Is the planning typically accurate?” The Client: “No, but we don’t have any

better basis.” Us: “How do you make sure you have the

right quality level?” The Client: “Well, we do a unit test, inte-

gration test, and system test. But, infact, we test too much and too late.”

Us: “Is your cost in line with expectationsor could you do better?”

The Client: “We really don’t know abouthow this all is measured and what tolearn from measurements. That’s whywe invited you.”In terms of software and technology,

this client was way above average.However, it was unclear to managementand engineers how to assess status, miti-gate risks, and improve performance. Theproject managers had no history databaseto decide on release criteria. Requirementswere changing, but without any control. It

is exactly this pattern of exciting technolo-gy and skills—combined with fast growthbut insufficient engineering and manage-ment processes—that eventually hits manycompanies in embedded software develop-ment. Finally, the client’s customers con-cluded that despite all of the technicaladvantages, processes and practices werebelow current professional software engi-neering expectations. A natural first stepon our side was to introduce a lean yeteffective measurement program.

To get started without much overhead,our team recommended a lean set of pro-ject indicators [1, 5, 6]. They simplified theselection by reducing the focus on projecttracking, contractor oversight, and pro-gram management perspective. Here isour short list of absolutely necessary pro-ject measurements:• Requirements status and volatility.

Requirements status is a basic ingredi-ent to tracking progress based onexternally perceived value. Alwaysremember that you are paid for imple-menting requirements, not just gener-ating code.

• Product size and complexity. Sizecan be measured as either functionalsize in function points or code size inlines of code or statements. Be pre-pared to distinguish according to yourmeasurement goals for code sizebetween what is new and what isreused or automatically generatedcode.

• Effort. This is a basic monitoringparameter to assure that you stay with-in budget. Effort is estimated up-frontfor the project and its activities.Afterwards, these effort elements aretracked.

• Schedule and time. The next basic

Figure 2: Measurements Provide a Closed Feedback Loop for Effective Corrective Action

942134_Text:Aug2004.qxd 6/12/09 3:21 PM Page 23

Process Replication

24 CrossTalk The Journal of Defense Software Engineering July/August 2009

monitoring measurement is ensuringthat you can keep the scheduled deliv-ery time. Similar to effort, time is bro-ken down into increments or phasesthat are tracked based on what is deliv-ered so far. Note that milestone com-pletion must be lined up with definedquality criteria to avoid poor qualitybeing detected too late.

• Project progress. This is the key mea-surement during the entire project exe-cution. Progress has many facets:Simply look to deliverables and howthey contribute to achieving a project’sgoals. Typically, there are milestonesfor the big steps, and earned value andincrements for the day-to-day opera-tional tracking. Earned value tech-niques evaluate how results (such asimplemented and tested requirementsor closed work packages) relate to theeffort spent and elapsed time. Thisthen allows for estimating the cost tocomplete and remaining time to com-plete the project.

• Quality. This is the most difficultmeasurement, as it is hardly possible toaccurately forecast whether the prod-uct has already achieved the right qual-ity level that is expected for opera-tional usage. Quality measurementsneed to predict quality levels and trackhow many defects are found comparedto estimated defects. Reviews, unit test,and test progress and coverage are the

key measurements to indicate quality.Reliability models are established toforecast how many defects still need tobe found. Note that quality attributesare not only functional but also relateto performance, security, safety, andmaintainability.These measurements must be actively

used for the weekly tracking of status,risks, and progress (e.g., increment avail-ability, requirements progress, code deliv-ery, defect detection), while others areused to build up a history database (e.g.,size, effort). Most of these measurements,such as defect tracking, are actually by-products from operational databases. Thisensures sufficient data quality to compareproject status across all projects of a port-folio. External benchmarks (such as pro-vided in [1,6]) help in bootstrapping ameasurement program as they immediate-ly point towards inefficiency and below-average performance.

To ease monitoring and avoid gettinglost in the fog of numbers, projectsshould aggregate the relevant informationin a standardized dashboard. Figure 3shows a simplified dashboard of how wehave utilized it with many clients. Itincludes milestone tracking, cost evolu-tion, a selection of process measurements,work product deliveries, and faults withstatus information. There can be bothdirect measurements (e.g., cost) as well asindirect measurements and predictions

(e.g., cost to complete). Such dashboardsprovide information in a uniform wayacross all projects, thus not overloadingthe user with different representations andsemantics to wade through. All projectswithin the organization must share thesame set of consistent measurements pre-sented in a unique dashboard. A lot oftime is actually wasted by reinventingspreadsheets and reporting formats whenthe project team should be focused oncreating value.

Measurements—such as schedule andbudget adherence, earned value, or quali-ty level—are typical performance indica-tors that serve as traffic lights on the statusof the individual project. Only projects inamber and red status that run out of agreedvariance (which, of course, depends onthe maturity of the organization) wouldbe investigated. The same dashboard isthen allowed to drill down to moredetailed measurements to identify rootcauses of problems. When all projectsfollow a defined process and utilize thesame type of reporting and performancetracking, it is easy to determine status,identify risks, and resolve issues—withoutgetting buried in the details of micro-managing the project.

Process MeasurementSoftware engineering processes determinethe success of organizations as well ashow they are perceived in the marketplace.

Figure 3: Measurement Dashboard Overview

942134_Text:Aug2004.qxd 6/12/09 3:21 PM Page 24

Project and Process Measurement

July/August 2009 www.stsc.hill.af.mil 25

Purchasing organizations worldwide areusing tools such as CMMI to evaluatetheir suppliers, be it in automotive, infor-mation/communication technologies, orgovernmental projects [1, 7]. Markets haverecognized that continuous processimprovement contributes substantially tocost reductions and quality improvement.An increasing number of companies areaware of these challenges and are proac-tively looking at ways to improve theirdevelopment processes [8]. Suppose acompetitor systematically improves pro-ductivity at a relatively modest annual rateof 10 percent (as we can see in many soft-ware and IT companies). After only threeyears, the productivity difference is (1.13)= 1.33, or a 33 percent advantage. Thisdirectly translates into more capacity forinnovation, higher margins, and improvedmarket positioning.

Software measurement is a necessaryprecondition to performance improve-ment. The concept of objective-drivenprocess improvement will focus processeson the objectives they must achieve.Processes are a means to an end and needto be lean, pragmatic, efficient, and effec-tive—or they will ultimately fail, despite allthe push one can imagine. Figure 4 showsthis goal-driven relationship from businessobjectives to concrete annual performanceobjectives (on an operational level) to spe-cific process performance measurements.

What follows are eight integral soft-ware measurement steps, showing howobjective-driven process improvement istranslated into concrete actions, and howsoftware measurements are used toimprove processes. Each step includes anexample—all taken from the same medi-um-sized company that Vector recentlyconsulted—showing how we put each stepinto action.

Step 1: Identify the organization’simprovement needs from its businessgoalsThese business goals provide the guidancefor setting concrete engineering perfor-mance improvement objectives on ashort-term basis. Example: The businessgoal with our client was to improve rev-enues and cash flows and to reduce cost ofnon-performance from schedule delays.

Step 2: Define and agree on theorganization’s key performanceindicators (KPIs) Such KPIs are standardized across theorganization and ensure visibility, account-ability, and comparability. Naturally, KPIsmust relate to the business goals.Measurements should drive informed

decision-making. They must be used foreffectively communicating status andprogress against the objectives set for thebusiness, process, or project. Measure-ments, both direct and indirect, should beperiodically evaluated in conjunction withthe driving objectives and to identifyproblems or derive decisions. Example:The selected performance indicator wasschedule predictability, measured as thenormalized delays compared to the origi-nally agreed deadline. Schedule changes(after a project had started) were not con-sidered in this measurement. This avoidedthe argument that a specific delay was jus-tified due to changing requirements. Oncesuch an excuse is accepted, delays typical-ly increase—as do costs (due to thechanges). In this case, we found almostunanimous agreement from product man-agers and business owners who found thatthe lack of schedule changes helped avoidthe downward spiral of requirementschanges, delays, and cost overruns.

Step 3: Identify the organization’shot spots, such as areas where theyare feeling the most pain internallyor from customersTypical techniques include root causeanalysis of defects and customer surveys.Example: Average schedules in the com-pany were 45 percent behind initial com-mitments. A root cause analysis of delayswas performed: 40 percent of delays camefrom insufficient project management; 30percent from changing requirements; 20percent from supplier delays; and 10 per-cent from other causes. Looking to thehighest-ranking root causes, we foundinsufficient planning and control withinthe project. Often, requirements were

added or changed following a customerquestion—rather than including the cus-tomer in the trade-off and impact analysis.When speaking to client-customers, thisbecame even more evident: Customersperceived such ad-hoc changes as a weak-ness and missed clear guidance and leader-ship on feature content.

Step 4: Commit to concreteimprovement objectivesThese improvement objectives shoulddirectly address the mentioned weaknessesand simultaneously support the overarch-ing business objective. We use the acronymSMART to outline good objectives:• Specific (precise).• Measurable (tangible).• Accountable (in-line with individual

responsibilities).• Realistic (achievable).• Timely (suitable for current needs).

These objectives are reviewed andapproved by upper-level managers beforeproceeding further. This ensures that pri-orities are appropriate and that nothingrelevant has been overlooked or misun-derstood. Example: Two improvementobjectives, improving estimations andimproving requirements development,were agreed upon. The respective perfor-mance targets were agreed to in a manage-ment seminar to achieve buy-in. Each pro-ject was required to have two estimateswhere the first was allowed to deviate by20 percent and the second to deviate by 10percent. After the project started, therequirements change rate was required tobe under 20 percent—except that cus-tomers would, after a clear decision-mak-ing process, agree on trade-offs and payfor the changes. Time-boxing and incre-

Figure 4: Applying the E-4 Measurement Process to Achieve Improvements

942134_Text:Aug2004.qxd 6/12/09 3:21 PM Page 25

Process Replication

26 CrossTalk The Journal of Defense Software Engineering July/August 2009

mental development with prioritizedrequirements was then introduced toachieve improvement objectives. Require-ments priorities were agreed upon acrossimpacted stakeholders from productmanagement, engineering, and market-ing/sales before each new project started.

Step 5: Identify specific levers1 tostart improvements and connectthem to ROI planningThis is typically best done when using aprocess improvement framework such asCMMI [6]. This framework provides thenecessary guidance regarding which bestpractices to apply and how processesrelate to each other. Without the rightlevers, chances are high that objectiveswill not be reached. Example: Focus wason requirements development, require-ments management, technical solutions,project planning, and project monitoringand control. Project managers were edu-cated in project management techniquesand negotiation skills.

Step 6: Perform a brief gap analysisof the selected process areas toidentify strengths and weaknessesThis systematic look at weaknesses helpsto focus limited engineering resourceswhere it matters most. Example:Requirements were collected rather thandeveloped; requirements managementsatisfied the basic need for change man-agement; engineering was too technolo-gy-driven and was extended to capturebusiness reasoning; project planningshowed severe weaknesses in estimationand feasibility analysis; and project moni-toring and control showed weaknesses ingetting stakeholder agreement onchanges.

Step 7: Develop a concrete actionplan for the identified weaknessesAvoid trying to change all weaknesses atthe same time. Use increments to subdi-vide bigger changes. Consider availableresources and skills and get external sup-port if you lack competencies, such aschange management. Example: The mosturgent need was project planning. A ded-icated one-month initiative was launchedright away to install a suitable estimationmethod and to train people on it. A toolfor feasibility analysis was introduced inparallel because not much of the organi-zation’s own historical data was available.A historical database was installed for aset of key project measurements. In asecond phase, earned value analysis wasintroduced. After three months, require-ments development was launched under

the leadership of product management.

Step 8: Implement improvementsand deliver tangible resultsImplement the agreed-upon changes tooperational projects and measureprogress against the committed improve-ment objectives. Example: Performancemeasurements were collected from allongoing projects. There weren’t repri-mands for insufficient performance, butit was carefully analyzed. We found withthis client that too many requirementschanges lacked a clear specification,analysis, and commitment by the productmanager. Consequently, a strong focuswas given towards change managementand change review boards2. A weekly pro-ject review was introduced after a fewweeks, enhanced with daily Scrum meet-ings of development teams. Require-ments changes passing the change reviewboard had to have their proper businesscase or were not accepted. Although theresults proved valid, marketing and saleswere unhappy because they wanted flexi-bility and no accountability for thechanges. This improvement reducedrequirements changes (within the firstthree months) substantially. The first fewprojects had 20 percent schedule overrun(compared to the previous average of 45percent) and two of them were evenclose to 10 percent. These two were fur-ther evaluated to identify best practices.

As it turned out, the project managersdemanded requirements reviews by prod-uct managers and testers before accept-ing requirements to change reviewboards. The quality of requirements sub-stantially improved. This change wasimmediately pushed forward by seniormanagement for all projects. As it turnsout, testers were unhappy because theydidn’t have the time scheduled for doingthe reviews. Rather than demanding over-time, senior management asked for fivepercent slots (two hours) each week; thisproved to be sufficient time to reviewone to three requirements with the neces-sary depth.

Getting More From YourMeasurementsMeasurement programs mostly failbecause they are disconnected from actu-al business. Too often, things are mea-sured that do not matter at all and thereis usually no clear improvement objectivebehind what is measured. Often the col-lected measurements and resultingreports are useless, only creating addi-tional overhead. In the worst cases, they

hide useful and necessary information.We have seen reports on software pro-grams with more than 50 pages full ofgraphs, tables, and numbers. When askedabout topics such as cost to complete,expected cost of non-quality after han-dover, or time-to-profit, the organizationdid not have a single number. Sometimesnumbers are even created to hide realityand attract attention to what looks good.Be aware that measurements are some-times abused to obscure and confusereality.

The primary question with softwaremeasurement is not “What measure-ments should I use?” but rather “Whatdo I need to improve?” It is not abouthaving many numbers but rather abouthaving access to the exact informationneeded to understand, manage, andimprove your business. This holds truefor both project and process measure-ment.

As a professional in today’s fast-pacedand ever-changing business environment,you need to understand how to manageprojects on the basis of measurementsand forecasts. You need to know whichmeasurements are important and how touse them effectively. Here are some suc-cess factors to pragmatically use measure-ments:• Estimate project time and effort and

realistically set deadlines.• Check feasibility on the basis of given

requirements, needs, and past projectperformance (productivity, quality,schedule, and so on). Do not routine-ly overcommit.

• Manage your requirements and keeptrack of changes. Measure require-ments changes and set thresholds ofwhat is allowed.

• Know what value means to your clientor customer. Track the earned valueof your project.

• Understand what is causing delaysand defects. Do not let delays accu-mulate. Remove the root causes anddo not simply treat the symptoms.

• Be decisive and communicate with afact-based approach. Avoid disputeswith management, clients, and users.

• Deliver what matters. Use measure-ments to keep commitments.

• Continuously improve by analyzingyour measurements and then imple-menting respective objective-drivenchanges. Follow through until resultsare delivered.Practitioners should help manage-

ment so that they make decisions on thebasis of measurements. This will givemanagement the necessary information

942134_Text:Aug2004.qxd 6/12/09 3:21 PM Page 26

July/August 2009 www.stsc.hill.af.mil 27

before and after the decision so that theycan follow the effects and compare themto the goals. Managers should ensure thatdecisions are made based on facts andanalyses. They should always considernumber 4 in the E-4 process (executingdecisions and actions), and make surethat decisions move the organizationtowards agreed-upon objectives.

Accountability means setting realisticand measurable objectives. Objectivessuch as reduce errors or improve quality by 50percent are not useful. The objectiveshould be clear and tangible: Reduce thenumber of late projects by 50 percent for thisyear compared to the previous year. Theseobjectives must end up in a manager’s keyperformance indicators. Projects usingunclear oral, memo, or slide reports willmost certainly fail to deliver according tocommitments. Projects using a standardspreadsheet-based progress reporting—related to requirements, test cases, anddefects versus plans—will immediatelyreceive the necessary attention if theydeviate. With this attention, correctiveaction will follow, and the project has agood chance to recuperate because ofsufficiently early timing.

Goals that are measured will beachieved. The reason is very simple:Once you set a SMART objective and fol-low it up, you make a commitment toboth yourself and your team or manage-ment group. As humans—and specifical-ly as engineers—we want to deliverresults. Measurement provides the stimu-lus and direction to reach our goals.�

References1. Ebert, Christof, and Reiner Dumke.

Software Measurement. New York/Heidelberg: Springer-Verlag, 2007.

2. Juran, Joseph M., and A. BlantonGodfrey. Juran’s Quality Handbook.New York: McGraw-Hill Professional,2000.

3. ISO/IEC. ISO/IEC 15939:2002. Soft-ware Engineering – Software Measure-ment Process. 2002.

4. Kraft, Theresa A. “Systematic andHolistic IT Project Management Ap-proach for Commercial Software WithCase Studies.” Information SystemEducation Journal 63.6: 1-15. 23 Dec.2008 <http://isedj.org/6/63/>.

5. Carleton, Anita D., et al. “SoftwareMeasurement for DoD Systems:Recommendations for Initial CoreMeasures.” Technical Report CMU/SEI-92-TR-19. Sept. 1992 <www.sei.cmu.edu/pub/documents/92.reports/pdf/tr19.92.pdf>.

6. Ebert, Christof, and Capers Jones.

“Embedded Software: Facts, Figuresand Future.” IEEE Computer 42.4:42-52, Apr. 2009.

7. Chrissis, Mary Beth, Mike Konrad, andSandy Shrum. CMMI: Guidelines forProcess Integration and ProductImprovement. 2nd ed. Boston:Addison-Wesley Professional, 2006.

8. Gibson, Diane L., Dennis R. Gold-enson, and Keith Kost. “PerformanceResults of CMMI-Based ProcessImprovement.” Technical ReportCMU/SEI-2006-TR-004. Aug. 2006<www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr004.pdf>.

Notes1. “Levers” in this case mean to set up

the improvement project in a way thatthe different changes follow someorder, won’t come ad-hoc and isolated,and would thus meet objectives.

2. Change review boards are staffed withengineering and product managers andensure that both technical and busi-ness rationale and impacts of changesare considered. They then makeinformed and firm decisions.

About the Author

Christof Ebert, Ph.D.,

is managing director andpartner at Vector Con-sulting Services. He ishelping clients worldwideto improve technical

product development and to manageorganizational changes. Prior to workingat Vector, he held engineering and man-agement positions for more than adecade in telecommunication, IT, aero-space, and transportation. A measure-ment practitioner who has worked forFortune 500 companies, Ebert authored“Software Measurement,” published bySpringer, now in its third fully revisededition.

Vector Consulting ServicesIngersheimer Straße 24D-70499 StuttgartGermanyPhone: +49-711-80670-0E-mail: christof.ebert@

vector-consulting.de

Project and Process Measurement

942134_Text:Aug2004.qxd 6/12/09 3:21 PM Page 27