Module Management Presentation

Gerrit Muller
University of South-Eastern Norway-NISE
Hasbergsvei 36 P.O. Box 235, NO-3603 Kongsberg Norway
[email protected]

Abstract
This module addresses the presentation of architectural issues to higher
management teams.

Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve
by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is
published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the
document remains complete and unchanged.

All Gaudí documents are available at:

http://www.gaudisite.nl/

version: 1.1 status: draft March 27, 2021

Contents

1 Simplistic Financial Computations for System Architects. 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Cost and Margin . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Refining investments and income . . . . . . . . . . . . . . . . . . 3
1.4 Adding the time dimension . . . . . . . . . . . . . . . . . . . . . 5
1.5 Financial yardsticks . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 How to present architecture issues to higher management 11

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 The presentation material . . . . . . . . . . . . . . . . . . . . . . 14
2.4 The Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 1

Simplistic Financial
Computations for System
Architects.
e
om
inc
$

es
profit expens

variable
fixed costs

sales volume
break even in units
point
expected
sales volume

1.1 Introduction

Many system architects shy away from the financial considerations of the product
creation. In this document a very much simplified set of models is offered to help
the architect in exploring the financial aspects as well. This will help the architect
to make a ”sharper” design, by understanding earlier the financial aspects.
The architect should always be aware of the many simplifications in the models
presented here. Interaction with real financial experts, such as controllers, will
help to understand shortcomings of these models and the finesses of the highly
virtualized financial world.
In Section 1.2 a very basic cost and margin model is described. Section 1.3
refines the model at the cost side and the income side. In Section 1.4 the time
dimension is added to the model. Section 1.5 provides a number of criteria for
making finacial decisions.
1.2 Cost and Margin
The simplest financial model looks only at the selling price (what does the customer
pay), the cost price (how much does the manufacturing of the product actually
cost). The difference of the selling price and the cost price is the margin. Figure 1.1
shows these simple relations. The figure also adds some annotations, to make the
notions more useful:

• the cost price can be further decomposed in material, labor and other costs

• the margin (”profit per product”) must cover all other company expenses,
such as research and development costs, before a real profit is generated

• most products are sold as one of the elements of a value chain. In this figure
a retailer is added to show that the street price, as paid by the consumer, is
different from the price paid by the retailer[1].

The annotation of the other costs, into transportation, insurance, and royalties per
product, show that the model can be refined more and more. The model without
such a refinement happens to be rather useful already.

retailer margin
and costs

Margin per product.

margin The margin over the sales volume,
street price

must cover the fixed costs, and generate profit

transportation, insurance,
miscellaneous
sales price

royalties per product, ...

labour
cost price

Cost per product,

excluding fixed costs
material
purchase price of components may cover
development cost of supplier

Figure 1.1: The relation between sales price, cost price and margin per product

The translation of margin into profit can be done by plotting income and expenses
in one figure, as shown in Figure 1.2, as function of the sales volume. The slope
of the expenses line is proportional with the costs per product. The slope of the
income line is proportional with the sales price. The vertical offset of the expenses
line are the fixed organizational costs, such as research, development, and overhead
costs. The figure shows immediately that the sales volume must exceed the break
even point to make a profit. The profit is the vertical distance between expenses

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 2
and income for a given sales volume. The figure is very useful to obtain insight in
the robustness of the profit: variations in the sales volume are horizontal shifts in
the figure. If the sales volume is far away from the break even point than the profit
is not so sensitive for the the volume.

e
com
$

in

s es
profit expen

variable
fixed costs

sales volume
break even in units
point
expected
sales volume

Figure 1.2: Profit as function of sales volume

1.3 Refining investments and income

The investments as mentioned before may be much more than the research and
development costs only, depending strongly on the business domain. Figure 1.3
shows a decomposition of the investments. The R&D investments are often calcu-
lated in a simple way, by using a standard rate for development personnel that
includes overhead costs such as housing, infrastructure, management and so on.
The investment in R&D is then easily calculated as the product of the amount of
effort in hours times the rate (=standardized cost per hour). The danger of this
type of simplification is that overhead costs become invisible and are not managed
explicitly anymore.
Not all development costs need to be financed as investments. For outsourced
developments an explicit decision has to be made about the financing model:

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 3
 financing

business dependent:
marketing, sales pharmaceutics industry
sales cost >> R&D cost

training sales&service

strategic choice:
NRE: outsourcing, royalties
NRE or per product

including:
staff, training, tools, housing
materials, prototypes
research and development overhead
certification
often a standard staffing rate is used
that covers most costs above:
R&D investment = Effort * rate

Figure 1.3: Investments, more than R&D

• the supplier takes a risk by making the investments, but also benefits from
larger sales volumes

• the company pays the investment, the so called Non Recurring Engineering
(NRE) costs. In this case the supplier takes less risks, but will also benefit
less from larger sales volumes.

If the supplier does the investment than the development costs of the component
are part of the purchasing price and become part of the material price. For the NRE
case the component development costs are a straightforward investment.
Other investments to be made are needed to prepare the company to scale all
customer oriented processes to the expected sales volume, ranging from manufac-
turing and customer support to sales staff. In some business segments the marketing
costs of introducing new products is very significant. For example, the pharmaceu-
tical industry spends 4 times as much money on marketing than on R&D. The
financial costs of making investments, such as interest on the capital being used,
must also be taken into account.
We have started by simplifying the income side to the sales price of the products.
The model can be refined by taking other sources of income into account, as shown
in Figure 1.4. The options and accessories are sold as separate entities, generating
a significant revenue for many products. For many products the base products are

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 4
 other recurring license fees
income pay per movie

content, portal
services incomeservice updates
services maintenance

options,
sales priceoption * volumeoption
accessories
options

products sales priceproduct * volume product

Figure 1.4: Income, more than product sales only

sold with a loss. This loss is later compensated by the profit on options and acces-
sories.
Many companies strive for a business model where a recurring stream of revenues
is created, for instance by providing services (access to updates or content), or by
selling consumables (ink for prink jet printers, lamps for beamers, et cetera).
One step further is to tap the income of other players of the value chain.
Example is the license income for MPEG4 usage by service and content providers.
The chip or box supplier may generate additional income by partnering with the
downstream value chain players.

1.4 Adding the time dimension

All financial parameters are a function of time: income, expenses, cash-flow, profit,
et cetera. The financial future can be estimated over time, for example in table form
as shown in Figure 1.5. This table shows the investments, sales volume, variable
costs, income, and profit (loss) per quarter. At the bottom the accumulated profit is
shown.
The cost price and sales price per unit are assumed to be constant in this
example, respectively 20k$ and 50k$. The formulas for variable costs, income
and profit are very simple:

variable costs = sales volume ∗ cost price

income = sales volume ∗ sales price

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 5
 Y1 Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y2 Q1 Y2 Q2 Y2 Q3
investments 100k$ 400k$ 500k$ 100k$ 100k$ 60k$ 20k$
sales volume (units) - - 2 10 20 30 30
material & labour costs - - 40k$ 200k$ 400k$ 600k$ 600k$
income - - 100k$ 500k$ 1000k$ 1500k$ 1500k$
quarter profit (loss) (100k$) (400k$) (440k$) 200k$ 500k$ 840k$ 880k$
cumulative profit (100k$) (500k$) (940k$) (740k$) (240k$) 600k$ 1480k$
cost price / unit = 20k$ variable cost = sales volume * cost price / unit
income = sales volume * sales price / unit
sales price / unit = 50k$ quarter profit = income - (investments + variable costs)

Figure 1.5: The Time Dimension

prof it = income − (investments + variable costs)

profit

1M$

0.5M$
Y1 Y1 Y1 Y1 Y2 Y2
Q1 Q2 Q3 Q4 Q1 Q3

time
(0.5M$)

(1M$)
loss

Figure 1.6: The “Hockey” Stick

Figure 1.6 shows the cumulative profit from Figure 1.5 as a graph. This graph
is often called a ”hockey” stick: it starts with going down, making a loss, but when
the sales increase it goes up, and the company starts to make a profit. Relevant
questions for such a graph are:

• when is profit expected?

• how much loss can be permitted in the beginning?

• what will the sustainable profit be in later phases?

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 6
 early more expensive
product + follow-on
profit
delay of 3 months
1M$
original model
0.5M$
Y1 Y1 Y1 Y1 Y2 Y2 Y2
Q1 Q2 Q3 Q4 Q1 Q2 Q3

time
(0.5M$)

(1M$)
loss

Figure 1.7: What if ...?

These questions can also be refined by performing a simple sensitivity analysis.

Figure 1.7 shows an example of such an analysis. Two variations of the original
plan are shown:

• a development delay of 3 months

• an intermediate more expensive product in the beginning, followed by a more

cost optimized product later

The delay of 3 months in development causes a much later profitability. The

investment level continues for a longer time, while the income is delayed. Unfortu-
nately development delays occur quite often, so this delayed profitability is rather
common. Reality is sometimes worse, due to loss of market share and sales price
erosion. This example brings two messages:

• a go decision is based on the combination of the profit expectation and the

risk assessment

• development delays are financially very bad

The scenario starting with a more expensive product is based on an initial

product cost price of 30k$. The 20k$ cost price level is reached after 1 year.
The benefit of an early product availability is that market share is build up. In
this example the final market share in the first example is assumed to be 30 units,
while in the latter scenario 35 units is used. The benefits of this scenario are mostly
risk related. The loss in the beginning is somewhat less and the time to profit is
somewhat better, but the most important gain is be in the market early and to reduce

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 7
the risk in that way. An important side effect of being early in the market is that
early market feedback is obtained that will be used in the follow on products.

8
M€

5 cumulative 1

4 cumulative 2
cumulative 3
3 cumulative 4
2 cumulative total

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
-1

-2
quarter

Figure 1.8: Stacking Multiple Developments

In reality, a company does not develop a single product or system. After

developing an initial product, it will develop successors and may be expand into a
product family. Figure reffig:SFCmultipleDevelopments shows how the cumulative
profits are stacked, creating an integral hockey stick for the succession of products.
In this graph the sales of the first product is reduced, while the sales of the second
product is starting. This gradual ramp-up and down is repated for the next products.
The sales volume for the later products is increasing gradually.

1.5 Financial yardsticks

How to assess the outcome of the presented simple financial models? What are
good scenarios from financial point of view? The expectation to be profitable is not
sufficient to start a new product development. One of the problems in answering
these questions is that the financial criteria appear to be rather dynamic themselves.
A management fashion influences the emphasis in these criteria. Figure 1.9 shows
a number of metrics that have been fashionable in the last decade.
The list is not complete, but it shows the many financial considerations that
play a role in decision making.
Return On Investments is a metric from the point of view of the shareholder or
the investor. The decision these stakeholders make is: what investment is the
most attractive.

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 8
 Return On Investments (ROI)

Net Present Value

Return On Net Assets (RONA) leasing reduces assets, improves RONA

turnover / fte outsourcing reduces headcount, improves this ratio

market ranking (share, growth) "only numbers 1, 2 and 3 will be profitable"

R&D investment / sales in high tech segments 10% or more

cash-flow fast growing companies combine profits with negative cash-flow,

risk of bankruptcy

Figure 1.9: Fashionable financial yardsticks

Return On Net Assets (RONA) is basically the same as ROI, but it looks at all
the capital involved, not only the investments. It is a more integral metric
than ROI.

turnover / fte is a metric that measures the efficiency of the human capital. Optimization
of this metric results in a maximum added value per employee. It helps
companies to focus on the core activities, by outsourcing the non-core activ-
ities.

market ranking (share, growth) has been used heavily by the former CEO of
General Electric, Jack Welch. Only business units in rank 1, 2 or 3 were
allowed. Too small business units were expanded aggressively if sufficient
potential was available. Otherwise the business units were closed or sold.
The growth figure is related to the shareholder value: only growing companies
create more shareholder value.

R&D investment / sales is a metric at company macro level. For high-tech companies
10% is commonly used. Low investments carry the risk of insufficient product
innovation. Higher investments may not be affordable.

cashflow is a metric of the actual liquid assets that are available. The profit of a
company is defined by the growth of all assets of a company. In fast growing
companies a lot of working capital can be unavailable in stocks or other non
salable assets. Fast growing, profit making, companies can go bankrupt by a

Gerrit Muller USN-SE

Simplistic Financial Computations for System Architects.
March 27, 2021 version: 1.3
page: 9
 negative cash-flow. The crisis of Philips in 1992 was caused by this effect:
years of profit combined with a negative cash-flow.

1.6 Acknowledgements
William van der Sterren provided feedback and references. Hans Barella, former
CEO of Philips medical Systems, always stressed the importance of Figure 1.2,
and especially the importance of a robust profit. Ad van den Langenberg pointed
out a number of spelling errors.

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 10
Chapter 2

How to present architecture

issues to higher management

mention the red information only

Market drivers Options Typical performance Power budget
A B
transfer/sec

MPEG4
cost B
A B
integration MP3
ttm multiple suppliers color display infra 7 8
wow
nifty features
fashionable design
ePen A sensor 6 8
GPS sensor
DRM Hollywood pact GSM
display 20 17
standards UTMS power 3 4
BT total 36 37
802.11b
load

Bill of material Schedule fte's profit-investment

A B
A B 302304 310 318 326 A B
salesprice 10 10
infra 7 8 A infra 2 8 cost/p 3 4
sensor 6 8 control 6 4 units 1M 1M
display 20 17 302304 308 322 326330 display 6 8 sales 10M 10M
power 3 4 appl 3 3 costs 3M 4M
total 36 37 B total 17 23 investment 2M 3M
profit 5M 3M

recommendation Operating principle worst-case Power details

A B A B
recommendation: performance infra 7 8 infra 7 8
select A sensor 6 8 sensor 6 8
transfer/sec

display 20 17 display 20 17
B
backup material
power 3 4 power 3 4
total 36 37 total 36 37
follow up: A A B
infra 7 8
allocate Jan, Piet, Klaas sensor 6 8
per 1/11 display 20 17
power 3 4
go/nogo 1/1/03 load total 36 37

2.1 Introduction
The architect bridges the technology world with the other business related worlds,
by understanding these other worlds and by having ample know-how of technologies.
Management teams are responsible for the overall business performance, which in
the end is expressed in financial results.
Many architects and management teams are captured in a vicious circle:

• architects complain about management decisions and lack of know-how of

managers

• managers complain about lack of input data and invisible architects

One way to break this vicious circle is to improve the managerial communi-
cation skills of architects. We address a frequently needed skill: presenting an
architecture issue to a management team.
The architect should contribute to the managerial decision process by commu-
nicating technology options and consequences of technological decisions. Figure 2.1
 management

financial

market organizational logistics

issues !
technology

Figure 2.1: Architectural issues related to managerial viewpoints

shows a number of the relevant, somewhat overlapping, viewpoints. The figure

indicates what links architects should communicate to management teams.

common characteristics highly variable characteristics

+ action-oriented
? technology knowledge
+ solution rather than problem from extensive to shallow
+ impatient, busy ? style from power play to
+ want facts not beliefs inspirational leadership

+ operate in a political context

+ bottom-line oriented:
profit, return on investment,
market share, etc.

Figure 2.2: Characteristics of managers in higher management teams

Architects must have a good understanding of their target audience. Figure 2.2
characterizes the managers in management teams. Their main job is to run a
healthy business, which explains many of these characterizations: action oriented,
solution rather than problem, impatient, busy, bottom-line oriented: profit, return
on investment, market share, et cetera, and want facts not believes. These managers
operate with many people all with their own personal interests. This means that
managers operate in a political context (something which architects like to ignore).
Some characteristics of management teams depend on the company culture.
For example, the amount of technology know-how can vary from extensive to
shallow. Or, for example, the management style can vary from power play to inspi-
rational leadership.

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 12
2.2 Preparation
Presentations to higher management teams must always be prepared with multiple
people: a small preparation team. The combined insights of the preparation team
enlarge the coverage of important issues, both technical as well as business. the
combined understanding of the target audience is also quite valuable. Figure 2.3
shows how to prepare the content of the presentation as well as how to prepare for
the audience.

Always prepare with small team!

content mutual interaction understand audience
70% 30%
of effort of effort
+ gather facts
+ gather audience background
+ perform analysis
+ analysis audience interests
+ identify goal and message
+ identify expected responses
+ make presentation
+ simulate audience,
+ polish presentation form exercise presentation

Figure 2.3: How to prepare

The content of the presentation must be clear, address the main issues, and
convey the message, see also 2.3. The message must have substance for managers,
which means that it should be fact based. The first steps are gathering facts and
performing analysis. Based on these facts the goal and message of the presen-
tation must be articulated. All this information must be combined in a presen-
tation. When the presentation content is satisfactory the form must be polished
(templates, colors, readability, et cetera). Although this has been described as a
sequential process, the normal incremental spiral approach should be followed,
going through these steps in 2-3 passes.
The members of management teams operate normally in a highly political
context, mutually as well as with people in their context. This politics interferes
significantly with the decision making. The political situation should be mapped by
the preparation team, the political forces must be identified and understood. This
is done by analyzing the audience, their background and their interests. The prepa-
ration team can gain a lot of insight by discussing the expected responses of the
management team. At some moment the preparation team can simulate (role-play)
the management team in a proof-run of the presentation. The understanding of the

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 13
audience must be used to select and structure the content part of the presentation.
This activity should be time-multiplexed with the content preparation; 70% of the
time working on content, 30% of the time for reflection and understanding of the
audience.

2.3 The presentation material

+ clear problem statement (what, why)

supported by
+ solution exploration (how) facts and figures

+ options, recommendations

+ expected actions or decisions

Figure 2.4: Recommended content

Figure 2.4 provides guidelines for the contents of the presentation. A clear
problem statement and an exploration of solution(s) should address the technical
issues as well as the translation to the business consequences. Normally a range of
options are provided The options are compared and recommendations are provided.
Note that options that are unfavorable from architectural point of view are never-
theless options. It is the challenge for the architect to articulate why these options
are bad and should not be chosen. Architect enable and streamline the decision
making by providing clear recommendations and by indicating what actions or
decisions are required.
All content of the presentation should be to the point, factual and quantified.
Quantified does not mean certain, often quite the opposite, future numbers are
estimates based on many assumptions. The reliability of the information should be
evident in the presentation. Many facts can be derived from the past. Figures from
the past are useful to “calibrate” future options. Deviations from trends in the past
are suspect and should be explained.
The presentation material should cover more than is actually being presented
during the presentation itself. Some supporting data should be present on the
sheets, without mentioning the data explicitly during the presentation. This allows
the audience to assess the validity of the presented numbers, without the need to
zoom in on all the details.
It is also useful to have additional backup material available with more in depth
supporting data. This can be used to answer questions or to focus the discussion:
speculation can be prevented by providing actual data.
The use of demonstrators and the show of artifacts (components, mock-ups)

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 14
 mention the red information only
Market drivers Options Typical performance Power budget
A B

transfer/sec
MPEG4
cost B
A B
integration MP3
ttm multiple suppliers color display infra 7 8
wow
nifty features
fashionable design
ePen A sensor 6 8
GPS sensor
DRM Hollywood pact GSM
display 20 17
standards UTMS power 3 4
BT total 36 37
802.11b
load

Bill of material Schedule fte's profit-investment

A B
A B 302304 310 318 326 A B
salesprice 10 10
infra 7 8 A infra 2 8 cost/p 3 4
sensor 6 8 control 6 4 units 1M 1M
display 20 17 302304 308 322 326330 display 6 8 sales 10M 10M
power 3 4 appl 3 3 costs 3M 4M
total 36 37 B total 17 23 investment 2M 3M
profit 5M 3M

recommendation Operating principle worst-case Power details

A B A B
recommendation: performance infra 7 8 infra 7 8
select A transfer/sec
sensor
display
6
20 17
8 sensor
display
6
20
8
17
B
backup material
power 3 4 power 3 4
total 36 37 total 36 37
follow up: A A B
infra 7 8
allocate Jan, Piet, Klaas sensor 6 8
per 1/11 display 20 17
power 3 4
go/nogo 1/1/03 load total 36 37

Figure 2.5: Mentioned info, shown info and backup info

makes the presentation more lively. The demonstrations should be short and attractive
(from customer point of view), while illustrating the value and technological possi-
bilities and issues.

poor form can easily distract from purpose and content

presentation material presenter's appearance

+ professional + well dressed

+ moderate use of + self confident but open

color and animations

+ readable

+ use demos and show artifacts but stay yourself,

stay authentic

Figure 2.6: Form is important

Architects prefer to focus on the content, form is supportive to transfer the

content. However architects should be aware that managers can be distracted by
the form of a presentation, potentially spoiling the entire meeting by small issues.
Figure 2.6 gives a number of recommendations with respect to the form of the
presentation and the appearance of the presenter.
The presentation material (slides, demonstrators, video, drawings, et cetera)

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 15
has to look professional. Slides will use color and other presentation features.
However, moderation in the use of colors, animations and other presentation features
is recommended; an overload of these colors and features does not look profes-
sional and will distract the audience from the actual content. Information on the
slides has to be readable: use large enough fonts and use sufficient contrast with
the background. Pay special attention to quality and readability, when copy-pasting
information from other sources. Sometimes it is better to recreate a high quality
table or graph than to save effort by copy-pasting an unreadable table or graph.
The appearance of the presenter can also make or break the presentation. The
presenter should give sufficient attention to clothes and overall appearance. Don’t
exaggerate this, you should stay yourself and still be authentic. Other people
immediately sense it when the appearance is too exaggerated, which is also damaging
for your image.

2.4 The Presentation

do not do
- preach beliefs + quantify, show figures
and facts
- underestimate technology + create faith in your knowledge
knowledge of managers
- tell them what they did wrong + focus on objectives
- oversell + manage expectations

Figure 2.7: Don’t force your opinion, understand the audience

Figures 2.7 and 2.8 show in the don’t column a number of pitfalls for an
architect when presenting to higher management teams. The preferred interaction
pattern is given in the do column.
The pitfalls in Figure 2.7, preaching believes, underestimating know-how of
managers, and telling managers what they did wrong, are caused by insufficient
understanding of the target audience. In these cases the opinion of the architect
is too dominant, opinions work counterproductive. Overselling creates a problem
for the future: expectations are created that can not be met. The consequence of
overselling is loss of credibility and potentially lack of support in tougher times.
Architects must manage the expectations of the audience.
When presenting the architect tries to achieve multiple objectives:

• Create awareness of the problem and potential solutions by quantification

and by showing figures and facts.

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 16
 • Show architecting competence in these areas, with the message being: “you,
the manager, can delegate the technical responsibility to me”. This creates
faith in the architect’s know-how.

• Facilitate decision making by translating the problem and solution(s) in business

consequences, with the focus on objectives.

This means that sufficient technological content need to be shown, at least to create
faith in the architect’s competence. Underestimation of the managerial know-
how is arrogant, but mostly very dangerous. Some managers have a significant
historic know-how, which enable them to assess strengths and weaknesses quickly.
Providing sufficient depth to this type of manager is rewarding. The less informed
manager does not need to fully understand the technical part, but at least should
get the feeling that he or she understands the issues.

do not do
- let one of the managers hijack + maintain the lead
the meeting
- build up tensions by withholding + be to the point and direct
facts or solutions
- be lost or panic at unexpected + acknowledge input, indicate
inputs or alternatives consequences (facts based)

Figure 2.8: How to cope with managerial dominance

The impatience and action orientation of managers makes them very dominant,
with the risk that they take over the meeting or presentation. Figure 2.8 shows a
number of these risks and the possible counter measures:

Managers hijacking the meeting can be prevented by maintaining the lead as

presenter.

Build up tensions by withholding facts or solutions, but be to the point and direct.
For example, it can be wise to start with a summary of the main facts and
conclusions, so that the audience know where the presentation is heading.

Be lost or panic at unexpected inputs or alternatives. Most managers are fast and
have a broad perspective that helps them to come with unforeseen options.
Acknowledge inputs and indicate the consequences of alternatives as far as
you can see them (fact based!).

An example of an unexpected input might be to outsource a proposed development

to a low-cost country. The outsourcing of developments of core components might

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 17
require lots of communication and traveling, creating costs. Such consequence has
to be put on the table, but refrain from concluding that it is (im)possible.

2.5 Exercise
The SARCH course [2] on System Architecting contains an exercise, where the
participants can apply then lessons learned by giving a presentation to a (simulated)
management team. The presenter gives his presentation for the participants and the
teacher, who play the role of this higher management team.

+ Bring a clear architecture message to

+ a Management team at least 2 hierarchical levels higher

+ with 10 minutes for presentation including discussion

(no limitation on number of slides)

* architecture message =
technology options in relation with market/product

* address the concerns of the management stakeholders:

translation required from technology issues into
business consequences (months, fte's, turnover, profit, investments)

Figure 2.9: Exercise presentation to higher management

Figure 2.9 shows the description of this exercise. The group of participants is
divided in 4 teams of about 4 people, preferably from the same domain. These
teams have somewhat less than 2 hours for the preparation of the presentation. The
exercise is explained to them several days before and the teams are also formed
days before. This enables the team to determine a subject and message in a background
process, during lunch and in the breaks. Determining the subject and message
requires quite some elapsed time. It is highly recommended to take a subject from
real-life: ”What you always wanted to tell topmanagement”.
Figure 2.10 shows the schedule of the exercise. Every presentation is 10 minutes
sharp, including the interaction with the management team. Directly after the
presentation feedback is given by the participants as well as by the teacher. This
feedback should follow the normal feedback guidelines: mentioning the strong
points, before discussing the options for improvement. The teacher must ensure
that sufficient feedback is given, the material in this exercise can be used as guideline.
The limited preparation time implies that the result will also be limited. The
form will be limited (handwritten flipovers) and most of the historical data will be
made up.
The teacher should stimulate the complete group to really participate in the role

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 18
 present and
discuss feedback

prepare in team of 4 1 1 2 2 3 3 4 4

13:30 14:00 15:00 16:00 17:00

Figure 2.10: Schedule of the presentation exercise

play, it can also be a lot of fun.

Gerrit Muller USN-SE

How to present architecture issues to higher management
March 27, 2021 version: 0.1
page: 19
Bibliography

[1] Mark Abraham. Define and price for your market starting at end
market values! http://www.sticky-marketing.net/articles/
pricing-for-channels.htm, 2001.

[2] Gerrit Muller. CTT course SARCH. http://www.gaudisite.nl/

SARCHcoursePaper.pdf, 1999.

[3] Gerrit Muller. The system architecture homepage. http://www.

gaudisite.nl/index.html, 1999.

History
Version: 1.1, date: January 18, 2015 changed by: Gerrit Muller
• added summary
Version: 1.0, date: May 19, 2004 changed by: Gerrit Muller
• created this module