Project control and process instrumentation

PROJECT CONTROL AND PROCESS
INSTRUMENTATION
• The Seven Core Metrics
 Management Indicators
 Quality Indicators
 Life-Cycle Expectations
 Pragmatic Software Metrics
 Metrics Automation
• Tailoring the Process
 Process Discriminants
 Example: Small-Scale Project Versus Large-scale Project

Project Control and Process Instrumentation
The modern software development process tackle the central management issues of
complex software:
1. Getting the design right by focusing on the architecture first
2. Managing risk through iterative development
3.Reducing the complexity with component based techniques.
4. Making software progress and quality tangible through instrumented change
management.
5. Automating the overhead and bookkeeping activities through the use of
round-trip engineering and integrated environments.
The goals of software metrics are
• An accurate assessment of progress to date
• Insight into the quality of the evolving software product
• A basis for estimating the cost and schedule for completing the product
with increasing accuracy over time

THE SEVEN CORE METRICS
MANAGEMENT INDICATORS
1. Work and progress (work performed over time)
2. Budgeted cost and expenditures (cost incurred over time)
3. Staffing and team dynamics (personnel changes over time)
QUALITY INDICATORS
1. Change traffic and stability (change traffic over time)
2. Breakage and modularity (average breakage per change over time)
3. Rework and adaptability (average rework per change over time)
4. Mean time between failures (MTBF) and maturity (defect rate
over time)

THE SEVEN CORE METRICS
The seven core metrics attributes include the following:
• They are simple, objective, easy to collect, easy to interpret, and hard
to misinterpret.
• Collection can be automated and nonintrusive.
• They provide for consistent assessments throughout the life cycle and
are derived from the evolving product baselines rather than from a
subjective assessment.
• They are useful to both management and engineering personnel for
communicating progress and quality in a consistent format.
• Their fidelity improves across the life cycle.

Seven Core Metrics Overview
METRIC PURPOSE PERSPECTIVES
Work and progress Iteration planning, plan vs. actuals,
management indicator
SLOC, function points, object
points, scenarios, test cases, SCOs
Budget cost and expenditures Financial insight, plan vs. actuals,
management indicator
Cost per month, full-time staff per
month, percentage of budget
expended
Staffing and team dynamics Resource plan vs. actuals, hiring
rate, attrition rate
People per month added, people
per month leaving
Change traffic and stability Iteration planning, management
indicator of schedule convergence
Software changes
Breakage and modularity Convergence, software scrap,
quality indicator
Reworked SLOC per change, by
type, by release/component/
subsystem
Rework and adoptability Convergence, software rework,
quality indicator
Average hours per change, by
type, by
release/component/subsystem
MTBF and maturity Test coverage/adequacy,
robustness for use, quality
indicator
Failure counts, test hours until
failure, by release/component!
subsystem

MANAGEMENT INDICATORS
There are three fundamental sets of management metrics:
technical progress, financial status, and staffing progress.
• By examining these perspectives, management can assess whether a project is on
budget and on schedule.
• Financial status is very well understood. Most managers know their resource
expenditures in terms of costs and schedule.
• Conventional projects whose intermediate products were all paper documents
relied on subjective assessments of technical progress or measured the number of
documents completed.
• While these documents did reflect progress in expending energy, they were not
very indicative of useful work being accomplished.
• The management indicators include standard financial status based on an earned
value system, objective technical progress metrics tailored to the primary
measurement criteria for each major team of the organization, and staffing
metrics that provide insight into team dynamics.

WORK AND PROGRESS - MANAGEMENT INDICATOR
The various activities of an iterative development project can be measured by
defining a planned estimate of the work in an objective measure, then tracking
progress (work completed over time) against that plan.
Each major organizational team should have at least one primary progress
perspective that it is measured against. For the standard teams perspectives of this
metric would be as follows:
• Software architecture team: use cases demonstrated
• Software development team: SLOC under baseline change management, SCOs
closed
• Software assessment team: SCOs opened, test hours executed, evaluation criteria
met
• Software management team: milestones completed

BUDGETED COST AND EXPENDITURES
- MANAGEMENT INDICATOR
• Plan the near-term activities (less than six months) in detail and leave the far-term
activities as rough estimates to be refined as the current iteration is winding down and
planning for the next iteration becomes crucial.
• Financial performance measurement provides highly detailed cost and schedule insight. Its
major weakness for software projects to assess the technical progress (% complete)
objectively and accurately.
• Modern software processes are amenable to financial performance measurement through
an earned value approach. The basic parameters of an earned value system:
• Expenditure plan: the planned spending profile for a project over its planned schedule.
• Actual progress: technical accomplishment relative to the planned progress underlying
the spending profile. In a healthy project, the actual progress tracks planned progress
closely.
• Actual cost: actual spending profile for a project over its actual schedule. In a healthy
project, this profile tracks the planned profile closely.
• Earned value: the value that represents the planned cost of the actual progress.
• Cost variance: difference between the actual cost and the earned value. Positive values
correspond to over-budget and negative values correspond to under-budget situations.
• Schedule variance: difference between the planned cost and the earned value. Positive
values correspond to behind-schedule situations; negative values correspond to ahead-
of-schedule situations.

BUDGETED COST AND EXPENDITURES
• 0 to 50%: content incomplete
• 50%: draft content; author has completed first draft text and art
• 65%: initial text baseline; initial text editing complete
• 75%: reviewable baseline; text and art editing complete
• 80%: updated baseline; cross-chapter consistency checked
• 90%: reviewed baseline; author has incorporated external reviewer comments
• 100%: final edit; editor has completed a final cleanup pass

STAFFING AND TEAM DYNAMICS
• An iterative development should start with a small team until the risks in the requirements
and architecture have been suitably resolved.
• Depending on the overlap of iterations and other project-specific circumstances, staffing
can vary. For discrete, one of-a-kind development efforts (such as building a corporate
information system), the staffing profile in Figure would be typical.

STAFFING AND TEAM DYNAMICS
It is reasonable to expect the maintenance team to be smaller than the development
team for these sorts of developments.
For a commercial product development, the sizes of the maintenance and
development teams may be the same.
Tracking actual versus planned staffing is a necessary and well-understood
management metric. Increases in staff can slow overall project progress as new
people consume the productive time of existing people in coming up to speed.
Low attrition of good people is a sign of success.
Engineers are highly motivated by making progress in getting something to work;
this is the recurring theme underlying an efficient iterative development process.
If this motivation is not there, good engineers will migrate elsewhere. An increase in
unplanned attrition-namely, people leaving a project prematurely-is one of the most
glaring indicators that a project is destined for trouble.
The causes of such attrition can vary, but they are usually personnel dissatisfaction
with management methods, lack of teamwork, or probability of failure in meeting
the planned objectives.

QUALITY INDICATORS
1. Change traffic and stability (change traffic over time)
2. Breakage and modularity (average breakage per change over time)
3. Rework and adaptability (average rework per change over time)
4. Mean time between failures (MTBF) and maturity (defect rate over time)
1. CHANGE TRAFFIC AND STABILITY:
• It is defined as the number of software change orders opened and closed over the life cycle
in the figure. This metric can be collected by change type, by release, across all releases,
by team, by components, by subsystem, and so forth.

• Coupled with the work and progress metrics, it provides insight into the stability of the
software and its convergence toward stability (or divergence toward instability).
• Stability is defined as the relationship between opened versus closed SCOs.
• The change traffic relative to the release schedule provides insight into schedule
predictability, which is the primary value of this metric and an indicator of how well the
process is performing.
2 BREAKAGE AND MODULARITY
• Breakage is defined as the average extent of change, which is the amount of software
baseline that needs rework (in SLOC, function points, components, subsystems, files, etc.).
• Modularity is the average breakage trend over time. For a healthy project, the trend
expectation is decreasing or stable as in figure.
• This indicator provides insight into the benign or malignant character of software change.
• In a mature iterative development process, earlier changes are expected to result in more
scrap than later changes.
• Breakage trends that are increasing with time clearly indicate that product maintainability is
suspect.

3 REWORK AND ADAPTABILITY:
• Rework is the average cost of change, which is the effort to analyze, resolve, and retest all
changes to software baselines.
• Adaptability is the rework trend over time. For a healthy project, the trend expectation is
decreasing or stable as in figure.
• Not all changes are created equal. Some changes can be made in a staff-hour, while others
take staff-weeks. This metric provides insight into rework measurement.
• In a mature iterative development process, earlier changes (architectural changes, which
affect multiple components and people) are expected to require more rework than later
changes (implementation changes).

4 MTBF AND MATURITY
• MTBF is the average usage time between software faults. In rough terms, MTBF is
computed by dividing the test hours by the number of type 0 and type 1 SCOs.
• Maturity is the MTBF trend over time as in figure.
• Early insight into maturity requires that an effective test infrastructure be established.
• Conventional testing approaches for monolithic software programs focused on achieving
complete test coverage of every line of code, every branch.

• Software errors categorized into two types: deterministic and non deterministic.
Physicists characterize these as Bohr-bugs and Heisen-bugs, respectively.
• Bohr-bugs represent a class of errors that always result when the software is
stimulated in a certain way. These errors caused by coding errors, and changes are
typically isolated to a single component.
• Heisen-bugs are software faults that are coincidental with a certain probabilistic
occurrence of a given situation. These errors are design errors and typically are not
repeatable even when the software is stimulated in the same apparent way.
• To provide adequate test coverage and resolve the statistically significant Heisen-
bugs, extensive statistical testing under realistic and randomized usage scenarios is
necessary.
• Modern, distributed systems with numerous interoperating components executing
across a network of processors are vulnerable to Heisen-bugs, which are far more
complicated to detect, analyze, and resolve.
• The best way to mature a software product is to establish an initial test infrastructure
that allows execution of randomized usage scenarios early in the life cycle and
continuously evolves the breadth and depth of usage scenarios to optimize coverage
across the reliability-critical components.

LIFE-CYCLE EXPECTATIONS
• The quality indicators are derived from the evolving product rather than from the
artifacts.
• They provide insight into the waste generated by the process. Scrap and rework
metrics are a standard measurement perspective of most manufacturing
processes.
• They recognize the inherently dynamic nature of an iterative development
process. Rather than focus on the value, they explicitly concentrate on the trends
or changes with respect to time.
• The combination of insight from the current value and the current trend provides
tangible indicators for management action.

Default pattern of life-cycle metrics evolution

PRAGMATIC SOFTWARE METRICS
Basic characteristics of a good metric are
1. It is considered meaningful by the customer, manager, and performer.
If anyone of these stakeholders does not see the metric as meaningful, it will not be used.
"The customer is always right" is a sales motto, not an engineering tenet.
2. It demonstrates quantifiable correlation between process perturbations and business
performance.
The only real organizational goals and objectives are financial: cost reduction, revenue
increase, and margin increase.
3. It is objective and unambiguously defined.
Objectivity should translate into some form of numeric representation (such as numbers,
percentages, ratios) as opposed to textual representations (such as excellent, good, fair,
poor).
Ambiguity is minimized through well-understood units of measurement (such as staff-
month, SLOe, change, function point, class, scenario, requirement), which are surprisingly
hard to define precisely in the software engineering world.
4. It displays trends. This is an important characteristic.
Understanding the change in a metric's value with respect to time, subsequent projects,
subsequent releases, and so forth is an extremely important perspective, especially for
today's iterative development models. It is very rare that a given metric drives the
appropriate action directly.

PRAGMATIC SOFTWARE METRICS
5. It is a natural by-product of the process.
The metric does not introduce new artifacts or overhead activities; it is derived
directly from the main stream engineering and management workflows.
6. It is supported by automation.
Experience has demonstrated that the most successful metrics are those that are
collected and reported by automated tools, in part because software tools require
rigorous definitions of the data they process.

METRICS AUTOMATION
• This automation improves management insight into progress and quality trends.
• Software project control panel (SPCP) maintains an on-line version of the status of
evolving artifacts.
• Provide a display panel (Dashboard) that integrates data from multiple sources to show the
current status of some aspect of the project.
• The panel can support standard features such as warning lights, thresholds, variable scales,
digital formats, and analog formats to present an overview of the current status.
SPCP defines and develops the following:
• Metrics primitives: indicators, trends, comparisons, and progressions
• A graphical user interface: GUI support for a software project manager role and
flexibility to support other roles
• Metrics collection agents: data extraction from the environment tools that maintain the
engineering notations for the various artifact sets
• Metrics data management server: data management support for populating the metric
displays of the GUI and storing the data extracted by the agents
• Metrics definitions: actual metrics presentations for requirements progress , design
progress, implementation progress, assessment progress and other progress dimensions.
• Actors: typically, the monitor and the administrator

METRICS AUTOMATION
Monitor: defines panel layouts from existing mechanisms, graphical objects, and linkages to
project data; queries data to be displayed at different levels of abstraction
Administrator: installs the system; defines new mechanisms, graphical objects, and linkages;
handles archiving functions; defines composition and decomposition structures for displaying
multiple levels of abstraction
Indicators may display data in formats that are binary (such as black and white), tertiary
(such as red, yellow, and green), digital (integer or float), or some other enumerated type
(such as sun ..sat, jan ..dec).
A trend graph presents values over time and permits upper and lower thresholds. A
progression graph presents elements of progress between states and an earned value is
associated with each state.

METRICS AUTOMATION
Example: SPCP for a project. software project manager role has defined a top-level display
with four graphical objects.
1. Project activity status. The graphical object in the upper left provides an overview of the
status of the top-level WBS elements. The seven elements are coded as red, yellow, and green
to reflect the current earned value status. Green represents ahead of plan, yellow indicates
within 10% of plan, and red identifies elements that have a greater than 10% cost or schedule
variance. This graphical object provides several examples of indicators: tertiary colors, the
actual percentage, and the current first derivative.

METRICS AUTOMATION
2. Technical artifact status. The graphical object in the upper right provides an overview of
the status of the evolving technical artifacts. The Req light would display an assessment of the
current state of the use case models and requirements specifications. The Des light would do
the same for the design models, the Imp light for the source code baseline, and the Dep light
for the test program.
3. Milestone progress. The graphical object in the lower left provides a progress assessment
of the achievement of milestones against plan and provides indicators of the current values.
4. Action item progress. The graphical object in the lower right provides a different
perspective of progress, showing the current number of open and closed issues.
Basic operational concept for an SPCP to monitor the control panel:
1. The SPCP starts and shows the most current information .
2. The user selects from a list of previously defined default panel preferences.
3. The user selects whether the metric should be displayed for a given point in time or in a graph, as a
trend. The default for trends is monthly.
4. The user points to a graphical object and requests that the control values for that metric and point in
time be displayed.
5. Points to a graphical object displaying a point in time and drills down to view the trend for the metric.
6. Points to a graphical object displaying a trend and drills down to view the values for the metric.
7. The user points to a graphical object displaying a point in time and drills down to view the next level
of information.
8. The user points to a graphical object displaying an indicator and drills down to view the breakdown
of the next level of indicators.

Tailoring the Process
• Process Discriminants
• Example: Small-Scale Project Versus Large-scale Project

Process Discriminants
• Two primary dimensions of process variability: technical complexity and
management complexity
• The formality of reviews, the quality control of artifacts, the priorities of
concerns, and numerous other process instantiation parameters are
governed by the point a project occupies in these two dimensions.
• A process framework is must be injected, and the methods, techniques,
culture, formality, and organization must be tailored to the specific
domain to achieve a success.
The project processes is organized around six process parameters:
1. Scale,
2. Stakeholder Cohesion,
3. Process flexibility,
4. Process Maturity,
5. Architectural Risk,
6. Domain experience

Higher technical complexity
• Embedded, real-time, distributed,
fault-tolerant
• High-performance, portable
• Unprecedented, architecture re-
engineering
Average software project
• 5 to 10 people
• 10 to 12 months
• 3 to 5 external interfaces
• Some unknowns, risks
Process Discriminants
Figure shows Two primary dimensions of process variability: technical complexity and
management complexity
Lower technical complexity
• Straightforward automation, single thread
• Interactive performance, single platform
• Many precedent systems, application re-engineering
Higher
management
complexity
• Large scale
• Contractual
• Many
stakeholders
• “Projects”
Lower management
complexity
• Smaller scale
• Informal
• Few stakeholders
• “Products”

Higher technical complexity
• More domain experience required
• Longer inception and elaboration phases
• More iterations for risk management
• Less-predictable costs and schedules
Priorities for tailoring the process framework
Lower technical complexity
• More emphasis on existing assets
• Shorter inception and elaboration phases
• Fewer iterations
• More-predictable costs and schedules
Higher
management
complexity
• More emphasis
on risk
management
• More process
formality
• More emphasis
on teamwork
• Longer inception
and elaboration
phases
Lower management
complexity
• Less emphasis on risk
management
• Less process formality
• More emphasis on
individual skills
• Longer production and
transition phases

1. Scale
Most important factor in tailoring a software process framework is the total scale of the
software application. Many ways to measure scale, including number of source lines of code,
number of function points, number of use cases, and number of dollars.
From a process tailoring perspective, the primary measure of scale is the size of the team. As
the headcount increases, the importance of consistent interpersonal communications becomes
paramount.
Five people is an optimal size for an engineering team. Many studies indicate that most people
can best manage four to seven things at a time.
Different management approaches needed to manage a team of 1 (trivial), a team of 5 (small),
a team of 25 (moderate), a team of 125 (large), a team of 625 (huge), and so on.
As team size grows, a new level of personnel management is introduced at roughly each
factor of 5.
Trivial-sized projects require almost no management overhead (planning, communication,
coordination, progress assessment, review, administration). There is little need to document
the intermediate artifacts. Workflow is single-threaded. Performance is highly dependent on
personnel skills.
Small projects (5 people) require very little management overhead, but team leadership
toward a common objective is crucial. Communication is needed among team members.
Project milestones are easily planned, informally conducted, and easily changed. There is a
small number of individual workflows. Performance depends primarily on personnel skills.
Process maturity is relatively unimportant. Individual tools can have a considerable impact on
performance.

Moderate-sized projects (25 people) require moderate management overhead, including a
dedicated software project manager to synchronize team workflows and balance resources.
Overhead workflows across all team leads are necessary for review, coordination, and
assessment.
• There is a definite need to communicate the intermediate artifacts among teams.
• Project milestones are formally planned and conducted, and the impacts of changes are
typically benign. There is a small number of concurrent team workflows, each with
multiple individual workflows.
• Performance is highly dependent on the skills of key personnel, especially team leads.
Process maturity is valuable. An environment can have a considerable impact on
performance, but success can be achieved with certain key tools in place.
Large projects (125 people) require substantial management overhead, including a dedicated
software project manager and several subproject managers to synchronize project-level and
subproject-level workflows and to balance resources.
• There is significant expenditure in overhead workflows across all team leads for
dissemination, review, coordination, and assessment. Intermediate artifacts are explicitly
emphasized to communicate engineering results across many diverse teams.
• Project milestones are formally planned and conducted, and changes to milestone plans are
expensive. Large numbers of concurrent team workflows are necessary, each with multiple
individual workflows.
• Performance is highly dependent on the skills of key personnel, especially subproject
managers and team leads.

Project performance is dependent on average people, for two reasons:
1. There are numerous mundane jobs in any large project, especially in the overhead
workflows.
2. The probability of recruiting, maintaining, and retaining a large number of exceptional
people is small.
Huge projects (625 people) require substantial management overhead, including multiple
software project managers and many subproject managers to synchronize project-level and
subproject-level workflows and to balance resources.
• There is significant expenditure in overhead workflows across all team leads for
dissemination, review, coordination, and assessment. Intermediate artifacts are explicitly
emphasized to communicate engineering results across many diverse teams.
• Project milestones are very formally planned and conducted, and changes to milestone
plans typically cause malignant re-planning. There are very large numbers of concurrent
team workflows, each with multiple individual workflows. Performance is highly
dependent on the
• skills of key personnel, especially subproject managers and team leads.
• Software process maturity and domain experience are mandatory to avoid risks and ensure
synchronization of expectations across numerous stakeholders.
• A mature, highly integrated, common environment across the development teams is
necessary to manage change, automate artifact production, maintain consistency among the
evolving artifacts, and improve the return on investment of common processes, common
tools, common notations, and common metrics.

Table: Process discriminators that result from differences in project size

2. STAKEHOLDER COHESION OR CONTENTION
• The degree of cooperation and coordination among stakeholders (buyers, developers,
users, subcontractors, and maintainers, among others) can significantly drive the specifics
of how a process is defined.
• Cohesive teams have common goals, complementary skills, and close communications.
Adversarial teams have conflicting goals, competing or incomplete skills, and less-than-
open communications.
• A product that is funded, developed, marketed, and sold by the same organization can be
set up with a common goal (for example, profitability). A small, collocated organization
can be established that has a cohesive skill base and excellent day-to-day communications
among team members.
• It is much more difficult to set up a large contractual effort without some contention across
teams. A development contractor rarely has all the necessary software or domain expertise
and frequently must team with multiple subcontractors, who have competing profit goals.
• Funding authorities and users want to minimize cost, maximize the feature set, and
accelerate time to market, while development contractors want to maximize profitability.
• Large teams are almost impossible to collocate, and synchronizing stakeholder
expectations is challenging. All these factors tend to degrade team cohesion and must be
managed continuously.

Table: Process discriminators that result from differences in stakeholder cohesion

3. PROCESS FLEXIBILITY OR RIGOR
• The degree of rigor, formality, and change freedom inherent in a specific project's
"contract" (vision document, business case, and development plan) will have a substantial
impact on the implementation of the project's process.
• For very loose contracts such as building a commercial product within a business unit of a
software company, management complexity is less. In this, processes, features, time to
market, budget, quality can freely traded off and changed with little overhead.
• For example, if a company wanted to eliminate a few features in a product under
development to capture market share from the competition by accelerating the product
release, it would be feasible to make this decision in less than a week. The entire
coordination effort might involve only the development manager, marketing manager, and
business unit manager coordinating some key commitments.
• For a very rigorous contract, it could take many months to authorize a change in a release
schedule.
• For example, to avoid a large custom development effort, it might be desirable to
incorporate a new commercial product into the overall design of a next-generation air
traffic control system. This require coordination among the development contractor,
funding agency, users, certification agencies, associate contractors for interfacing systems.
• Large-scale, catastrophic cost-of-failure systems have extensive contractual rigor and
require significantly different management approaches.

Table: Process discriminators that result from differences in process flexibility

4. PROCESS MATURITY
• The process maturity level of the development organization, as defined by the
Software Engineering Institute's Capability Maturity Model is another key
driver of management complexity.
• Managing a mature process (level 3 or higher) is far simpler than managing an
immature process (levels 1 and 2).
• Organizations with a mature process typically have a high level of precedent
experience in developing software and a high level of existing process collateral
that enables predictable planning and execution of the process.
• This sort of collateral includes well defined methods, process automation tools,
trained personnel, planning metrics, artifact templates, and workflow templates.
• Tailoring a mature organization‘s process for a specific project is generally a
straightforward

Table: Process discriminators that result from differences in process maturity

5. ARCHITECTURAL RISK
• Some of the most important and recurring sources are system performance
(resource utilization, response time, throughput, accuracy), robustness to change
(addition of new features, incorporation of new technology, adaptation to
dynamic operational conditions), and system reliability (predictable behavior,
fault tolerance).
• The degree to which these risks can be eliminated before construction begins can
have dramatic ramifications in the process tailoring.

6. DOMAIN EXPERIENCE
• Domain experience governs its ability to converge on an acceptable architecture
in a minimum number of iterations. An organization that has built five
generations of radar control switches may be able to converge on an adequate
baseline architecture for a new radar application in two or three prototype release
iterations.
• A skilled software organization building its first radar application may require
four or five prototype releases before converging on an adequate baseline.

Example: Small-Scale Project vs. Large-Scale Project
• some of the dimensions of flexibility, priority, fidelity that can change when a
process framework is applied to different (small / large)applications, projects, and
domains.
• Table illustrates the differences in schedule distribution for large and small projects
across the life-cycle phases.
• A small commercial project (for example, a 50,000 source-line Visual Basic
Windows application, built by a team of five) may require only 1 month of
inception, 2 months of elaboration, 5 months of construction, and 2 months of
transition.
• A large, complex project (for example, a 300,000 source-line embedded avionics
program, built by a team of 40) could require 8 months of inception, 14 months of
elaboration, 20 months of construction, and 8 months of transition.

• The success or failure of the project reflects the importance of staffing or the
level of associated risk management.
Differences in workflow priorities between small and large projects
Rank Small Commercial Project Large Complex Project
1 Design Management
2 Implementation Design
3 Deployment Requirements
4 Requirements Assessment
5 Assessments Environment
6 Management Implementation
7 Environment Deployment

The following list elaborates some of the key differences in
discriminators of success.
• Design is key in both domains. Good design of a commercial product is a key
differentiator in the marketplace and is the foundation for efficient new product
releases. Good design of a large, complex project is the foundation for predictable,
cost-efficient construction.
• Management is paramount in large projects, where the consequences of planning
errors, resource allocation errors, inconsistent stakeholder expectations, and other
out-of-balance factors can have catastrophic consequences for the overall team
dynamics. Management is far less important in a small team, where opportunities
for miscommunications are fewer and their consequences less significant.
• Deployment plays a far greater role for a small commercial product because there
is a broad user base of diverse individuals and environments.

Differences in artifacts between small and large projects

Reference
• Software Project Management - A Unified Framework
Walker Royce

Project control and process instrumentation

More Related Content

What's hot (20)

Similar to Project control and process instrumentation (20)

More from Kuppusamy P (20)

Recently uploaded (20)

Project control and process instrumentation