Designing an Indicator System for Project Management Using the OSM Model

Indicators are a way to understand the world quickly and effectively; in project management they provide quantitative data that is more persuasive than qualitative descriptions. As Peter Drucker said, "no data, no management," highlighting the crucial role of metrics in project oversight.

The fundamental purpose of metrics is to advance project management. Without metrics, project processes lack visibility, making management impossible. Visible items can be assigned appropriate indicators, enabling judgment, evaluation, and decision‑making that lay a solid foundation for project progress.

Designing metrics involves defining data, collecting it, continuously analyzing it, and monitoring processes. Because projects are complex and long‑term, a single metric is insufficient; a coordinated set of metrics must be integrated into an overall indicator system that serves project management, acting as a common language, a directional compass, and a risk‑warning mechanism.

Various models exist for building indicator systems, such as OSM, AARRR, and MECE. The OSM model—Object (goal), Strategy (approach), Measure (metric)—is widely used for its clarity and implementability. This article applies the OSM model to design an indicator system for a government‑enterprise procurement cloud platform project.

An indicator system must empower the business it serves; otherwise data loses value. Therefore, before designing metrics, the business objective (the O in OSM) must be clearly understood, as it directs the entire metric design.

Based on the business goal, the next step is to formulate the Strategy (the S in OSM). Strategies can be broken down by product lifecycle or regional segments, allowing analysis of improvement points throughout the value chain.

The Measure (the M in OSM) stage defines concrete metrics. Each metric should include six elements: name, measurement method, unit, value, time scope, and spatial scope. These elements ensure the metric is precise, understandable, and actionable.

The six elements are:

1. Metric name – a unique descriptive title.

2. Measurement method – qualitative or quantitative logic and definition.

3. Measurement unit – the unit used for the metric.

4. Measurement value – the specific numeric value.

5. Time scope – the period, point, or frequency of measurement.

6. Spatial scope – the geographic or domain scope of the metric.

Indicator system design varies across project phases; appropriate measurement methods are selected, adjusted, and periodically output to reflect overall metric status. Each iteration yields improvement items, whose effects are observed, leading to continuous enhancement of the system.

The goal is to design a metric system that fully captures the technical and business status of the procurement cloud platform, supporting feature iteration and ensuring stability. The system is decomposed into domains: business data, product demand, R&D process quality, service & resources, big‑data monitoring, and security.

Examples of domain metrics:

• Business data domain – transaction GMV, user count, etc.

• Product demand domain – total product requirements, released requirements, etc.

• R&D process quality domain – development health, delivery quality, etc.

• Service & resources domain – cloud resource utilization, alarm count, service quality, etc.

• Big‑data monitoring domain – data storage volume, extraction, monitoring, etc.

• Security domain – host protection coverage, emergency vulnerability response, etc.

After defining the Object and Strategy, the Measure step creates concrete metrics with the six elements for each domain. Metrics must have practical significance and measurability; otherwise they are unnecessary. Once individual metrics are defined, their relationships are mapped to form a network, which is then integrated into a comprehensive indicator system.

For the R&D process quality domain, metrics include code volume, comment volume, unit‑test coverage, number of code‑review comments raised and resolved, etc. In testing, metrics focus on defect severity, automation value, and test case coverage, forming a feedback loop that guides development.

Metrics are aggregated per domain, then across domains to create a full‑scale indicator system. Continuous observation and timely adjustments keep the system effective throughout the project lifecycle, adapting to shifting focus areas such as demand during early development or stability during maintenance.

Using an indicator system wisely is essential; it should provide insight into current status, root causes, and future forecasts. Misuse—such as focusing on a single number or treating data as the sole decision factor—can be detrimental. Instead, trends, distribution, and multi‑dimensional analysis should guide improvements.

Indicators are tools, not ends. They must be interpreted in context, considering underlying reasons for anomalies. Over‑reliance on raw numbers without qualitative analysis can lead to biased decisions and harm project health.

The indicator system is not a one‑time deliverable; it requires ongoing refinement and iteration as the project evolves, ensuring cost reduction, efficiency gains, and overall project success.

In summary, a well‑designed indicator system, grounded in design theory and aligned with business goals, links isolated metrics into a cohesive network, enabling holistic visibility, collaborative design, continuous feedback, and sustained value throughout the project lifecycle.