Work

Trade-Offs and Compromise

Home \ Work \ Trade-offs and compromise

Trade-Offs

All projects try to gain control over these variables:

Cost
People
Quality
Risk
Scope
Time

People and quality can be adjusted to conform to cost (typically people), scope (feature-set) and time. Cost, scope and time, however, are in direct conflict with each other. These three attributes are often shown as a trade off triangle:

In the above example you can only ever optimise one of the three - prioritising a low cost means reducing scope as well as time. If scope is large then both cost and time increase to compensate.

This principle applies in other areas too. Consider a system that must be usable, secure, and cheap. You cannot have all three - usability and security will cost you. A cheap system can be secure but not user friendly. And a user friendly system can be secure or cheap, but not both.

Compromise

Software projects involve many people, from managers, developers, end-users and customers, for example, to testers and operations/support. Many have competing interests as shown here -

Stakeholder interests:

Sponsors	Managers	Developers	End-Users	Support
● Quick schedule ● Low budget	● No overruns ● No surprises ● Successful project	● Interesting design work ● Exploration of new technical areas ● No grunt work ● Home life	● Lots of features ● User-friendly software ● Fast software ● Robust software	● No defects ● Good documentation ● Easily modifiable

Culture, the strategic nature of the project, reliability requirements, as well as complexity, governance and documentation requirements also demand consideration -

Culture	Leading edge	Tried and tested
Functionality	Tactical	Strategic
Reliability	Unessential	Critical
Complexity	Low	High
Governance	Minimal	Critical
Documentation	Unessential	Critical

A discussion of how these attributes might lead to a project management approach is here.

Many of these principles were developed by Barry Boehm and Rony Ross (see "Theory-W Software Project Management: Principles and Examples", IEEE Transactions on Software Engineering, July 1989).

< Back to Work | ^ Back to top