A truism in the software development business is that systems exist to support business goals. Any system design decisions that does not support business goals should not be made, and system design decisions that do support the business goals should be prioritized based on the particular goals.
The assumptions made in the above statement are that the business goals for a system are explicit and agreed upon by all stakeholders. Unfortunately, these assumptions are rarely true. More frequently, different stakeholders have different business goals for a particular system (often conflicting), some business goals are implicit and unstated, and still other business goals are not realizable.
Paul Clements and I have been working on a method called PALM (don’t worry about what the acronym means) attempting to overcome some of these deficiencies. The heart of the method is twofold:
- every goal has attached the object of the goal (whose goal is it)
- the elicitation of the goals is driven by a categorization of standard business goals derived from a survey of the business literature.
This categorization has 10 items. For each item, we also ask about the effect of changing the technical, social, legal, or financial environment. The ten items in the categorization are
- Growth and continuity of the organization
- Meeting financial objectives
- Meeting personal objectives
- Meeting responsibility to employees
- Meeting responsibility to society
- Meeting responsibility to country
- Meeting responsibility to shareholders
- Managing market position
- Improving business processes
- Managing quality and reputation of products
Paul and I have tried PALM out a couple of times and written a technical report on the method and its application. The report is working its way through the SEI editorial process and will appear when all of the editing is complete.
— Len Bass