Handbook

How to determine objectives in 3 easy steps

How to determine objectives in 3 easy steps

Seven sorts of knowledge constitute the foundation of abilities. Abilities usually do not come naturally but need to be developed. This post explains how to determine objectives for developing abilities.

Steps to determine objectives

Suppose that you have identified an ability that you deem relevant for a given purpose. How can you determine an objective to develop this ability? You can do this in three steps.

looks_one

Significance

Define what the ability means for your purpose.

looks_two

Direction

Define a course of action for developing the ability.

looks_3

Priority

Define the importance and urgency of developing the ability.

Significance

You can perform a VRIO analysis to determine the significance of a given ability. This allows you to find out four relevant properties. These properties are:

Valuable

Valuable

Able to exploit opportunities and defend against threats (yes/no).

Rare

Rare

Scarce and difficult to acquire in the market (yes/no).

Inimitable

Inimitable

Hard to copy or substitute (yes/no).

Organized

Organized

Set up to capitalize on resources (yes/no).

Direction

Determine a course of action for developing a given ability as follows:

call_split

Phase out

If it is not valuable (anymore).

play_for_work

Specialize

If it is valuable, but not rare.

call_merge

Integrate

If it is valuable and rare, but not inimitable.

sync

Exploit

If it is valuable, rare, and inimitable, but not organized.

update

Maintain

If it is valuable, rare, inimitable, and organized.

Priority

Determine a priority for developing a given ability as follows:

priority_high

Do

If its development is urgent and requires your personal attention.

watch_later

Plan

If its development is less urgent but requires your personal attention.

send

Delegate

If its development is urgent but does not require your personal attention.

not_interested

Eliminate

If its development is less urgent and does not require your personal attention.

Posted by Pieter van Langen in Handbook
7 sorts of design knowledge to accomplish design work

7 sorts of design knowledge to accomplish design work

Designers continually develop knowledge with customers, commissioners, users, fellow designers, partners, and other stakeholders. They acquire, create, and share knowledge of different sorts. This post explains which sorts of design knowledge exist that a team needs to accomplish design work.

Sorts of design knowledge

A team’s organization consists of the following sorts of design knowledge and their interrelationships (see figure):

  • Strategy: the plan to accomplish design goals.
  • Structure: the way of organizing design work.
  • Systems: processes and procedures of design.
  • Style: the way designers approach design.
  • Specialisms: fields of specialization of designers.
  • Skills: talents and abilities of designers.
  • Shared values: accepted values, norms, and standards for designing.
Sorts of design knowledge
Sorts of design knowledge and their interrelationships

These seven sorts almost entirely correspond with the seven internal factors in the McKinsey 7S Model. Other points of departure are conceivable, but the McKinsey 7S Model applies well in practice. Furthermore, many managers know this model. For a brief introduction to this model, see, for instance, Strategic Management Insight or Investopedia.

In practice, the two sorts Systems and Style may be hard to distinguish. For instance, a design team will likely define style as the processes and procedures the team members have agreed to follow. In such cases, you may conveniently combine the two sorts into one sort, System.

Framework for design knowledge

The seven sorts of design knowledge and their interrelationships form a framework that can be used to:

  • Analyze the strengths, weaknesses, opportunities, and threats of a design team.
  • Search for knowledge that is of interest to design work.
  • Embed design knowledge in a team’s organization.
Posted by Pieter van Langen in Handbook