IWSED-95: International Workshop on Software Engineering Data
Project management
Reported by Reidar Conradi
and Jyrki Kontio
Participants:
E.M. Cooke, SRA, co-chair
Mary Zajac, AT&T, co-chair
- Reidar Conradi, University
of Trondheim
- Takeshi Hayama, NTT Data Communications Systems
- Hubert Kempter, Daimler-Benz
- Walcelio Melo, University of Maryland
- Yoshihiro Takada, Nara Intitute
- Günther Ruhe, Univerity of Kaiserslautern
<Note: this is an unfinished, draft report>
Working Group Goal and issues addressed
The project management and risk management working groups started
their work in a joint session, for which we have written a separate
report (joint session in project and risk management).
The joint session concluded in initial definitions for project
management and risk management.
Project management was defined as an organizational function
that plans and executes projects. Project management (as
an organizational function) contains several activities, such
as planning, monitoring, controlling, resource allocation, estimating,
and task assignment. These different activities may employ different
technologies, such as cost and schedule estimation, use of PERT
charts, metrics databases - and risk management.
While we defined project management as an organizational function,
we defined risk management as a technology, i.e.,
a set of methods, techniques and tools that can be used for managing
risks. Risk was defined as "any action that occurs
and has a major impact on performance, cost and/or schedule".
The initial, and somewhat confusing, overlap of the terms projects
management and risk management was thus easier to resolve.
The initial agenda for the working group had been defined by a
set of issues that had been proposed before the workshop:
- What data is necessary for project management: is cost and
defect data enough
- How to support the project manager in interpreting the data,
do they need/want support ?
- How to integrate project management and estimation tools with
software engineering data
- Project manager's dilemma: when to focus on project specific
improvements and when to spend time on general process improvement
The session started with a more detailed definition of project
management. It consists of the following functions:
1. Planning:
- Task network creation (break-down and scheduling of technical
and administrative activities), done incrementally.
- Preventive: anticipated exceptions.
- Reactive: replanning and (re)allocation of resources, e.g.
staffing, budget, time.
2. Control
- Monitoring,
- proactive: possible adjustments/feedbacks, reporting, port-mortems
analysis/learning.
3. Co-ordination:
- People-people, people-tools, different roles, contact with
upper management.
(4. Execution of single activities,)
Couple phases, models and goals:
The following table was synthesized to characterize differences
between
| Process model requirements:
| Goals: |
| 1. Planning | Customization of models to goals
| New X at T, price P, quality Q |
| 2. Control | Context-sensitive cause and effect
| Cost/effort data, defect data |
| 2.1 Monitor | Unobstrusive data gathering, what data for what
| |
| 3. Co-ordinate | Workflow, new transaction models
| |
| (4. Execute) | |
|
| (5. Packaging) | Understanding too much data.
| |
Problems and issues:
- Abstract, ill-defined role.
- Technology/method shifts make existing models out-of-date
or ad-hoc.
- Ex. central towards distributed.
- Constant change of real-world requirements.
State-of-Practice
State-of-practice in project management was characterized as follows:
- Data not available right away: untimely, unreliable, not retrievable;
i.e. managers have no complete and consistent view of the project.
- Data is informal: different interpretations.
- Data is inconsistent: from different people, aggregated data,
made up later, biased towards expected.
- Data is formal, but cannot be compared: different definitions
and contents.
- Data range is broad: across projects.
- Managers have different expertise/knowledge/points-of-view.
- How to define "start" of certain activities?
- Pre-development phase or customer contract negotiation: very
informal, by sales persons, pre-sell is done by non-technical
persons, risky with unreasonable expectations.
- Checklists are non-quantifiable data short improve chance
of success.
- Data responsible must be defined: need uniform and reusable
project data, common data collection tools, data management resources.
- Heterogeneous project management tools, data, data models
and formalism.
- Knowledge on technology transfer gap: need to justify effectiveness
of new technologies, re-education in software engineering.
State-of-Art
State-of-art in project management was characterized as follows:
- Better support (metrics) for existing ("as-in")
process.
- New ("to-be") processes: new paradigms for programming:
scripts, reuse, integrative.
Conclusions
The most important needs for better project management were listed:
- Context and methods for applying state-of-the-art, with (metrified?)
examples and experiences, make CMM and QIP usable for small companies?
- Characterize projects to select/customize proper technologies,
e.g. depending on quality priorities.
- (Meta)metrics to assess good project management practices?
- Assessing project qualities beyond defects, e.g. maintainability.
- "What-if" modeling: perform good choices on-the-fly.
- New methodologies: universities are studying toy problems,
i.e. controllable and small.
- More exchange of people between academia and industry!
Recommended project research:
- Improved software experimentation. Ex. new 4-year project
at Kaiserslautern.
- Classification of contexts, research on context importance.
- Decision-point guidelines: given metrics, then what to do?
E.g. what is feasible, recommendable etc.?
Go to IWSED-95 home page
Updated 06-Mar-96 by Jyrki Kontio
Web Accessibility