Project Performance Indicator Workbench(PPIW)
剑柄A.T.M.Aerts J.Blijenberg F.J.Heemstra R.J.Kusters L.J.Somers
Eindhoven University of Technology
幼儿园小班说课稿P.O.Box513,5600MB Eindhoven,the Netherlands
wsinlou@win.tue.nl
Abstract
A prototype has been developed of a generic tool t and accompanying methods that enable a customizable ap-proach towards project tracking and benchmarking.The un-derlying data model describes a generic project life cycle. The prototype has been applied to an iterative development life cycle in a number offield tests.
Keywords.Multi-project management,Process asss-ment and improvement,Software process metrics,Software process modeling,Software quality.
1.Introduction
Control of projects in the IT-world is mainly bad on knowledge and experience.Intuition,and political and so-cial skills play an important part in successful project ex-ecution.However,more and more customers refu to ac-cept vague promis and arrangements.More often hard demands are formulated that are aimed at preventing bud-get and lead-time overruns and insufficient product qual-ity.Customers demand insight in the expected and agreed project performance at the start of the project,during project execution and at its end.Most of the time project manage-ment cannot give this insight.This statement holds for the (operational)project management responsible for the execu-tion of IT-projects and for the multi-project management re-sponsible for initiating,planning,asssing and evaluating projects.
Project managers in most software development organi-zations u various methods,tools,and procedures.Exam-ples are Function Point Analysis[2],Project Management Workbench[1]and Work Breakdown Structures[7].De-spite all the existing tools and aids,project asssment in the end relies mainly on experience from the past of the peo-ple involved.This is a highly subjective ground on which to ba decisions.This subjectivity hinders the free exchange of experiences,it riously hampers the collection of mean-ingful project data,and it trivializes the discussions needed to reach a further understanding of the development process. Furthermore it is difficult to convince someone(
manage-ment,customers,..)on the basis of the subjective argu-ments.Finally,in practice the asssments have proven to have limitations,as can be illustrated by the many software development project failures that have been widely reported.
If we look at the current state of affairs with this in mind, we notice that the IT-industry recently has invested much ef-fort in process improvement.There is an incread interest in ISO certification(ISO9000-3)[16].The main focus in ISO is structuring and formalizing the business process by means of the development of manuals,guidelines and proce-dures.Also,the IT-world pays much attention to‘process-asssments’[17],that is to the determination of the matu-rity level of an IT-development process.The Capability Ma-turity Model[10]is the best known example in this area.De-pending on the maturity level specific actions have to be car-ried out in thefield of project control and/or information sys-tem development.
ISO-and CMM-activities try to give customers insight into the performance level of the development organization. However,they do not provide a guide for identifyingthe data that need to be gathered in order to support asssment,eval-uation,and benchmarking of projects.
Apart from ISO and CMM,AMI(Application of Met-ric in Industry)is a successful approach to asss p
rojects on a quantified basis[3].One of the basic AMI assump-tions is that measuring increas management insight in re-sults and problems and employee’s insight in business goals. AMI claims advantages like:improved methods for project planning and project management,improved tuning of the software development process and business goals,improved cost control,and improved communication during project execution.The AMI approach leads to a goal-driven ap-proach of which attribute to measure.This goal-driven ap-proach is bad on the Goal-Question-Metric approach[4], which in turn has much in common with Deming’s quality improvement cycle[8].However,AMI does not provide the
support needed to identify and gather relevant project data either.In particular,AMI is aimed at running projects in de-tail.The problems described above are focud at a higher level of abstraction.
The conclusion can be postulated that literature and IS development practice provide a number of successful ap-proaches for the solution of the problem stated above.How-ever,none of the solutions are immediately applicable to the identified problem area becau they are primarily fo-cud on supporting project management and not on sup-porting multi-project management,sales management and customers.The existing methods moreover fail to indicate which data have to be c
ollected and stored and have to be transformed into control information.
2.Objectives
The Project Performance Indicator Workbench(PPIW) discusd in this paper has been developed for the purpo of supporting multi-project managers,project managers,sales managers,and customers.
They are involved in actions related to(planned)execu-tion of projects such as submitting tenders,tracking and/or intervening in a project in progress,and accepting or reject-ing a tender.The actions are bad on their asssment of the status of the current project and the previous record of the organization in handling projects.The PPIW is to sup-port this asssment:
Asssment for the multi-project manager means an-swering questions such as:how is the project doing;
should I,as multi-project manager,do something?
For the project manager asssment means answering questions such as:how is the project doing related to other similar projects;how is the project doing related to the original expectations/estimates/
planning?
The sales managers is interested in answers on ques-tions like:what can I promi to the customer;how do
I convince the customer?
The customerfinally wants an answer on questions like:how good is this project team;what can I expect from this organization?
Starting point of the PPIW project is,that it is both uful and possible to support the asssment process discusd above by collecting project-related data and by comparing the with historical data.Project-related data are in them-lves a uful commodity.By offering afixed t of data a ‘language’emerges which enables a more effective and ef-ficient communication process with regard to the projects. If in addition to this an explicit link can be made with past
projects,which have been registered in a similar way,the project can be discusd in the light of what was and what was not possible in the past.In this way the PPIW gives a contribution toward making projects more visible.
3.Development
Thefirst step in realising the PPIW objectives is the de-velopment of a so-called conceptual framework[9].This framework shows-on a high level of abstraction-what as-ssment and control of an information system development project means for the target group.It concerns topics like: what does a sales manager control and why,what are the cri-teria for a successful asssment or control,and which data are worth transforming to control information.Bad on the framework methods,techniques,tools,and procedures can be developed.
The framework assumes that software is developed fol-lowing a structured approach or life linear de-velopment;iterative development).Within each type of life cycle a number of objects can be distinguished that are rel-evant for control purpos.The controlled objects will include items such as the project itlf,subprojects,and project phas.Using a critical success factor approach[13] and taking into account relevant cost drivers[6]for each of the controlled objects,one is able to identify a number of performance indicators.The indicators provide sufficient information to rve as a basis for tracking and benchmark-ing purpos.
Bad on the framework methods,techniques,tools and procedures can be developed.A major part o
f the PPIW project is the development of a tool t.In itsfinal form this tool t will support the structured development of a coher-ent t of performance indicators for a specific life cycle that is in u within a software development organization.Addi-tional tools that u the indicators will be provided to track and benchmark development efforts.
The development of the PPIW tool t went through v-eral stages.First,some experiments have been done using
a paper version of the various forms needed to collect the
project information.The advantage of using paper forms is that they are easy to construct and in that way are suitable for early prototyping.
Bad on the experience gained from this paper version a prototype electronic version has been constructed.The ur interface of this version cloly followed the layout of the paper forms,but it was refined to make the life of the project manager,who has to enter the data,as easy as possible by us-ing the facilities offered by modern programming environ-ments,such as sliders and pop-up windows.Some sample input screens are shown infigure1.
The advantage of the electronic version over the paper one is that,once the necessary infrastructure is in place, 2
Figure1.Examples of various input screens of the prototype.In total,the prototype offers over60 different input screens.
3
electronic data can be communicated more easily in a form that is directlyfit for u by other tools,for instance for the purpo of analysis.The disadvantage is that the tools are harder to construct.
The electronic version was designed to handle informa-tion from projects with possibly different life cycle models and development strategies.The underlying data model had to be sufficiently general in order to be able to accommodate this variety.Another requirement was that the tool should be able to access also data from a number of tools for collecting other kinds of project data,such as ESTEEM(the commer-cial successor of the MERMAID estimation tool t[11]), PMW[1]and SQUID[14].The PPIW data model therefore should contain as a specialization the relevant parts of the data models of the tools.This led to the data model dis-played infigure2.
General data model:generic part.The left hand side of figure2reprents the generic description of life cycles and their composition.Life Cycle defines a number of Con-trolled Object s.An example of a Life Cycle is IAD[15, 18],which defines the Controlled Object s(phas)‘Defi-nition Study’,‘Pilot Development’,and‘Pilot Introduction’.
A Controlled Object may contain a number of Mea-surement s.Objects defined by Measurement could be the moments of measurement that are defined by the measure-ment framework.An exampl
e of such an object is the mo-ment of measurement with respect to the feasibility of the Pilot Development pha.
A Performance Indicator is ud to define the measure-ment of a property for a particular Measurement,for ex-ample‘risk’or‘planning’.This definition can be given by means of parate Aspect s and Submetric s.qq安全中心网站
Since Aspect can only measure one-dimensional val-ues,the measurement property has to be split up into one-dimensional parts.To be able to define clusters of related Aspect s,the additional entity type Submetric has been in-troduced.For example,the Performance Indicator for the measurement property‘risk’contains a risk Top10.Since this does not yield a one-dimensional value,it has to be di-vided into10parate parts.In order to make it possible to retrieve the relation between the parts,a Submetric is ud which defines the various values that have to be mea-sured for one risk.The Submetric has a relation with As-pect for all of the values.
A Submetric can again contain new Submetric s.For example,the Submetric for risk contains a Submetric to define that for each risk a group of measures can be deter-mined.This last Submetric then has relations too with As-pect to determine the values that have to be collected for a measure.This clustering is the only function that Submet-ric has.
An Aspect may be given an arbitrary value or a value
from a predefined list.The entity type Ord/nom Value models the fact that such predefined lists of items are avail-able,so that an item can be chon to assign it to an Aspect.
瀑布美For example,this could be a list of possible risks or project characteristics.
General data model:specific part.The right hand side offigure2shows the specific data about an existing project and the entities that are created for it.Every entity type at the right hand side of thefigure reprents the fact that actual values are assigned to the attributes that are defined by the entity types at the left hand side of thefigure for(parts of)a specific Project.
At the right hand side offigure2,some additional con-straints hold.For a particular Project,there can be more than one Project Pha for each Controlled Object that is defined for the Life Cycle according to which the Project is carried out,if the pha can be gone through iteratively.The same holds for the relations between Project Pha and Project Measurement,and between Project and Project Measurement,but here it depends on the iterative charac-ter of Project Measurement.For example,the measure-ment with respect to‘progress’(and an IAD pha)can be repeated a number of times,whereas the measurement with respect to‘feasibility’(and the same pha)can be done only
once.
In the ca of the relation between Project Performance Indicator and Project Submetric,the maximum number of Project Submetric s that can be related to Project Perfor-mance Indicator are given by an attribute of Submetric.
For example,the Submetric of the Performance Indica-tor for the risk Top10defines the aspects that have to be measured for one risk.Furthermore,it determines the max-imum number of risks that can be clustered.This number in its turn determines the maximum number of Project Sub-metric s that can be related to the Project Performance In-dicator.
For the various relations between Project Measure-ment,Project Performance Indicator,Project Submet-ric and Project Aspect there can be as many relations as de-fined by the corresponding relations at the left hand side of the model.For example,the Project Measurement with respect to the‘evaluation’of the Pilot Introduction pha can have relations with three Project Performance Indi-cator s,namely‘Enthusiasm customer’,‘Involvement cus-tomer’,and‘Lead-time’.
All entities that are created for entity types at the right hand side of thefigure have to be related to an existing en-tity that is higher in the hierarchy defined by the model.Fill-ing in data for a Project Perfor
mance Indicator does not make n if there is no Project Measurement to relate it to.For Project Measurement and Project Aspect the same holds,with the difference that the entities can be re-4
Figure2.The ER-diagram[12]of the general data model.
5
lated to more than one higher entity.Becau of the exclu-sion on the relations,they can only be related to exactly one of the other entities.
Prototype data model.The data model of the prototype (called Collest[5])ud in the pilots was a specialization of the general model,suited for IAD-projects.It is the data model infigure3.Collest stands for collection of data for ESTEEM,referring to the fact that this tool is intended for collecting data in a form that can be analyzed by the ESTEEM-tool.dvd版和tv版有什么区别>八年级上册生物知识点
We e that in this data model the following things have changed.Since this model is specific to IAD,the generic component of the former model has been dropped,and only the right hand side offigure2has been kept.Also Project Submetric has been remodeled to a choice of the three sim-ple metrics that a Project Performance Indicator in this ca may consist of:Risk Metric,Standard Metric,and Planning Metric.
The Project Aspect offigure2wefind back in a num-ber of places,where they have been made explicit.
Aspects of the Risk Metric are Risk and Risk Measure with their respective value ts Risk Category and Measure.Aspects of the Planning Metric are the Planned and Realized enti-ties reprenting the planned and realized amounts of work. Aspects relating to the Project as a whole are called Fac-tor and Project Factor,reprenting predefined factors and ur defined,project specific ones respectively.This distinc-tion leaves room for the customization of the factors that in-fluence a project.New developments may give ri to new influences on a project.Another type of aspect,which is not associated with Measurement but reprents information about a Project as a whole,are its Characteristic s.
香蕉人体艺术From the comparison betweenfigures2and3we e that the former is a quite general one with a very open structure. Reporting facilities.The prototype not only offers nu-merous input facilities,but is also able to generate various reports.For example,after lection of a Controlled Ob-ject,a spider graph can be generated for each Measure-ment that contains all Performance Indicator s.For each Performance Indicator a bar graph can be generated show-ing the values of estimations and their confidence level. Some sample report screens are shown infigure4.
4.Experiences
The tool t has been tested,first on paper,and later by means of a prototypein two different environments.One test took place in a large Dutch software hou.The other took place in the EDP-department of the Dutch Central Statis-tics Agency.In each tting a number of IAD-project teams
乔丹英文
participated and ud the measurement system.On the ba-sis of the data gathered and a ries of interviews the mea-surement system was adapted.The main result of thefield tests was,apart from a number of practical suggestions,that participants indicated that the measurement system tallied with their prent working methods.They stated that they already performed similar activities,but not in such a struc-tured way.In other words:they are able and willing to u it.The interest of all the parties involved was raid.They all agreed to participate in a follow-up experiment.
Thefirst prototype was developed specifically for a sin-gle project approach(IAD)within a single environment(the software hou).The tool was ud in another tting(the government agency)and was ud successfully there,but a number of adaptations to local circumstances were needed.
The requested adaptations mainly referred to the layout of the input screens and the possibilities to generate reports.
Work is in progress to expand the tool.As was discusd above,the aim of the project is a generic to
ol that can eas-ily be adapted to different project approaches and to differ-ent environments.The main functionality of the generic tool would be:
The possibility to design a specific t of definitions for
a specific project approach within a specific organiza-
tion.
Maintenance of a locally defined t of definitions.
The u of this t of definitions to:
–estimate new projects:the tool offers possibilities
to look for comparable,but completed projects
(comparable with respect to lected features),so
information for planning and estimating a new
project can be provided.
–For a project in execution,the tool has a possi-
bility to look for relevant data of comparable,but
completed projects(comparable with respect to
lected features),so information to control this
project can be provided.
–Analyzingfinished projects.
Thefinished tool t will provide the generic PPIW this project was aimed at:a generic tool t and accompany-ing methods that enable a local for local approach towards project tracking and benchmarking.
From the experience gained in this project we conclude that the framework propod in[9]provides the right infor-mation for controlling projects.Note that the kind of met-rics needed at the multi-project level is rather different from the more quantitative metrics ud to measure daily progress in a project.Further rearch is needed tofind out whether (part of)the information gathered by the tool t can be made more quantitative.
6
