committed

The Committed R&D Organization
Jan Rydén, Magnus Höglund
TietoEnator Technical Consultants
164 87 Kista, Sweden
jan.ryden@tietoenator.com
magnus.hoglund@tietoenator.com
ABSTRACT
Everyone is focusing on time-to-market, but still the
all-important question “When will you be done?” is
left unanswered in many R&D organizations. And if
answered, the answer given is not credible since it
has been “90% ready” for quite a while. The
delivery date is slipping as time pass by and this
symptom can be observed on many levels within
R&D organizations, ranging from small one-person
tasks to large multi-site R&D projects.
This article is about how to create a culture of
commitments – an environment where this question
is not left unanswered. We argue that being more
predictable has a lot to do with attitude and values.
If I have promised, I shall live up to it! In order to
do that we need to agree on what should be
achieved and we need to reflect on what this means
to our situation and ourselves. We need to manage
uncertainty and risk in a professional way and since
we are continuously monitoring how we are doing
we can take early corrective actions when problems
occur. Mistakes are not something that we are afraid
of, but are seen as lessons learned and opportunities
for improvement.
1. Introduction
“Hi Joe! How are you doing? You are delivering
your class to integration on Thursday, aren’t you?”
Ben, the project manager is asking Joe, a
programmer on his team who has kept telling Ben
“Next Thursday” for three weeks now. At least Ben
thinks this is the case.
”I’ve told you I’ll be ready soon,” Joe answers
without taking his eyes off the screen, “but I don’t
know about Thursday. I mean, now the customer
figured out that he needs an interface to Bluetooth as
well…”
”Bluetooth?” Ben is confused.
“Well, I don’t know – you are the one meeting with
the customer, aren’t you?” Joe replies while still
typing on his keyboard.
”I need to check up on this,” Ben responded, “but
you will deliver on Thursday as you told me last
week, won’t you?” Ben tries to regain control of the
situation.
“You’re the one who said Thursday! I said maybe
and I told you that there are many depending factors
and now, looking back, I guess I’m the one who was
right from the beginning” Joe is now looking at Ben
to ensure that he realizes that he is not the guy to
blame.
“Ok, ok… but you will for sure be ready the
Thursday after that, won’t you?” Ben asks. He needs
a date to write in his project report.
“We’ll see…” Joe’s attention is now on his code
again.
Ben is leaving the room rather frustrated. “How is
one supposed to run a project with people that don´t
keep their promises? He doesn’t seem to care about
the fact that there is a customer who is paying to get
something on time”
Joe is also quite upset. “How is one supposed to
deliver in time when this guy bothers you all the
time nagging about the time plan? What about doing
some work instead?”
Dialogues like this one take place every day in R&D
projects all over the world. Joe is afraid of giving
Ben a clear estimate of when he will deliver. Why?
Well, probably he is afraid of being blamed if
something goes wrong. He is afraid of taking on this
task as a commitment, because increased

responsibility will only lead to increased risk of
being blamed.
Ben, on the other hand, does not give Joe a fair
chance to take on a commitment in a good way. He
is very much focused on his own situation and his
project report instead of focusing on Joe and the
work that Joe is doing.
2. A Commitment Attitude
Making a commitment is to take responsibility for a
result. It is about attitude – I am not afraid to take
responsibility and I will deliver! To take
responsibility means:
• guaranteeing the agreed result at a given time
and cost
• speaking up if/when you cannot guarantee this
• always making use of opportunities for
improvement and learning from mistakes
In our working environment we allow errors,
discover errors, and take corrective actions.
Something may happen that affects my task or
maybe I made a misjudgement about it. Daring to
take a chance and possibly make a mistake means
that we are forced to leave our “safety zone”. Being
outside our safety zone can be uncomfortable. It can
lead to undesirable circumstances, both
professionally and personally. However, always
staying on solid ground means never improving,
never developing. As professionals, we must
constantly strive for improvement.
To summarize – I need to take responsibility for a
result even when I am uncertain. I am allowed to
fail. However, I am not allowed to fail in realizing in
time if I cannot live up to my commitment.
3. Commitments in the R&D
Organization
The practical experiences that constitute the
foundation for this article come from years of
experience in software and hardware design, test
management, project management, process
improvement, and line management in a number of
R&D organizations. The types of products being
developed by these organizations are embedded
real-time systems, i.e. products that are controlled by
microprocessors and the related software, which are
embedded into the product itself.
The typical R&D organization that we will refer to
in this article is shown in Figure 1. The R&D
organization is hosted within a corporation and its
responsibility is to develop new products based on
requirements that are somehow gathered from the
market. The R&D organization is organized with
subunits according to, for example, work task. We
call this organization the line organization. The line
organization is where people are employed.
However, the actual R&D work is performed in
R&D projects. An R&D project is a temporary
organization with a clear goal of developing a
product with certain characteristics within a certain
time period and at a given cost. In an R&D
department there are normally several R&D projects
running in parallel. The line organization is
supplying and developing people, equipment,
processes and working methods for these projects.
This is a kind of matrix organization due to the fact
that people report in two directions, to the line
organization and to the projects.
In the R&D organization, commitments are made at
different levels and by different degrees of
P roduct X .1 P roduct X .2
S ystem S oftware Hardware I& V Q A
R& D Developm ent Dept. P roduct Managem ent M arket
P roduct X .3
B usiness A rea X B usiness A rea Y B usiness A rea Z
Corporate M anagem ent
R&D Project X.3.A
R&D Project X.3.B
R&D Project X.3.C
P roduct X .1 P roduct X .2
S ystem S oftware Hardware I& V Q A
R& D Developm ent Dept. P roduct Managem ent M arket
P roduct X .3
B usiness A rea X B usiness A rea Y B usiness A rea Z
Corporate M anagem ent
R&D Project X.3.A
R&D Project X.3.B
R&D Project X.3.C
Figure 1. A typical R&D Organization

formalism. A commitment could be to execute a
large complex R&D project consisting of 300 people
in 5 different countries according to the written
project definition, that has been agreed upon
between the project and its orderer in the line
organization. On the other hand, it could be coding,
testing and delivering a module as agreed by the
developer and her team leader. In both cases you
need to take responsibility and you need to live up to
it!
4. The Good Circle
A common view and mutual respect for the
commitment are preconditions for a successful task.
As pointed out in the previous section, commitments
are made at different levels in an R&D project. The
project itself is a commitment that an orderer in the
line organization delegates to a project manager.
The project manager in turn delegates work tasks,
each constituting a commitment, to the members of
the project. It is thus important that we have a shared
view about delegation. To delegate is to:
• guarantee the entire result while obtaining
support for partial results
• pass along authority, i.e. to give up the control
and use of agreed resources
It is of vital importance that everyone realizes that
you do not give up responsibility for a task when
you delegate it to somebody. When you delegate
you have secured a partial result as the assignee
takes on a commitment, but you are still responsible
for the whole.
Also, equally important, is to realize that when you
delegate you turn over the rights to use certain
resources. You cannot control them in detail; it is
your staff that decides how to achieve the defined
results. In other words, you need to give up control
in order to give the assignee of the commitment the
possibility to take responsibility. People want to and
can take responsibility for their actions and you need
to have faith in order to receive faith. In order to
succeed with a highly demanding R&D project we
need to create an environment where everyone
contributes to the result, an environment where
everyone has the possibility to succeed. We will
then enter the good circle displayed in Figure 2.
5. A Mutual Agreement
As illustrated by the examples of commitments in
the previous sections, commitments are always two-
way; two parties mutually agree beforehand on what
is to be accomplished and what prerequisites are
needed to achieve this.
5.1 Define the Agreement
It is of vital importance that both parties, the
assignor and the assignee, have the same view about
the results to be achieved. These need to be
described in measurable terms:
• What should be delivered?
• When should it be delivered?
• How should it be delivered?
Of course, the assignor is the one that needs to
demand a result. She is after all the one that has a
need. However, the assignee should also contribute
to the process of defining the agreement. She is
often the one that has the detailed knowledge about
what should be done and hence can ask the right
questions to clarify the commitment and request the
authority and resources needed.
Also, it is equally important to agree on the
prerequisites needed to meet the commitment:
• What is the idea and purpose – in what context
will the requested commitment be viewed?
• How should the job be done?
• What resources are needed for the task?
• What support is needed?
• What are my powers of authority?
Commitments are formulated on all levels in the
organization, with different levels of formality. If
the commitment applies to an entire project, the
Management
has faith in staff
Delegates authority
and influence
Increased productivity,
development of staff
Personal commitment
and dedication
Increased enjoyment
and interest in work
Management
has faith in staff
Delegates authority
and influence
Increased productivity,
development of staff
Personal commitment
and dedication
Increased enjoyment
and interest in work
Figure 2. The Good Circle.

agreement must be formalized in signed documents.
If the commitment is between a programmer and her
team leader, the agreement can be oral and
documented in the team’s schedule.
5.2 Reflection – What does it mean to me?
Before taking on a commitment the assignee really
needs to reflect upon how the task will affect her
(professional and private) situation and whether she
thinks it is possible for her to fulfil the commitment.
The following questions are useful to ask yourself:
• Do I have the time to take on this commitment
or are there other tasks that are in conflict with
this one?
• Do I have the right competence for doing this or
can I get it somewhere else?
• Do I understand what the other party expects
from me or is there any risk for a
misunderstanding?
• Does the other party understand my point of
view and how I feel about the task?
Just taking on something without reflecting if it is
possible or not, does not lead us anywhere! Still this
is very common in our daily life. Sure, there must be
a balance between time for reflections and getting
into action, but we can definitely afford to take two
minutes of reflection before we purge on.
The time needed for reflection also depends on the
size of the commitment. Before a project manager
for a 200 man-year project commits to fulfil the time
schedule, it would probably be necessary to perform
a one-month pre-study in order to reflect upon this
task!
It is vital that the assignee gets the possibility to
reflect in order to get a strong commitment. A lack
of reflection time will probably have the effect of
“Ok, I will do my best and we’ll see what comes
out…”
The “brave” project manager that commits to a two-
week cut in the delivery date two seconds after
receiving the question from a steering committee
member, is an equally bad example as the project
manager requesting four weeks of investigation
before answering. A steering committee that tries to
push through a commitment for a two week shorter
delivery plan, without helping out by giving the
project some new prerequisites, is an even worse
example of how to ruin a culture of commitments.
5.3 Live with Uncertainty and Agree on Risk
The only true knowledge we have of the future is
that we know nothing of the future. Everything from
an incorrectly estimated design activity to late
delivered hardware and changes in the market can
affect our opportunities to fulfil the commitment.
Everyone that has been involved in R&D work
knows how hard it is to estimate how much time a
task such as designing a subsystem will require. All
people in R&D business recognize the following
statements:
• How am I supposed to know how much time it
takes? I have never done exactly this before?
• I am an engineer and thus I am not good at
estimations. This needs to be the work of the
project management. I mean, if not, why should
we have a project manager at all?
• It is impossible to say! I mean, it is dependent
on at least 10 factors that I cannot control!!!
In all these cases, there must be a dialogue in order
to sort things out. R&D work is by definition doing
things that have not been done before. Despite this
fact, we need to commit to an estimate; because if
we do not we will loose focus and the R&D work
cannot be managed. There will always be
uncertainty when you make an estimate and if you
as the designer cannot tell how much time your
design will take – who can? We have to be able to
make a commitment based on our best assumption
and to take responsibility for it.
As the assignor you should be careful about
questioning estimates. Saying “Three weeks – that is
too much for the design of this small subsystem!” is
not a very good way of expressing your trust in the
one who is going to perform the work. It is of course
much smarter to try to find out the reason for that
estimation. Maybe some prerequisites could be
changed in order to save time or maybe it is a
misunderstanding about what is to be delivered?
It goes back to the good circle of Figure 2, where we
really must trust everyone’s ability and interest in
doing a good job.
Risks are certain events that if they occur will
negatively affect the results of the commitment.
Examples of risks are lack of processor capacity and
illness. They are both possible threats and thus they
need to be identified and handled.

Both the assignor and the assignee should participate
in defining the risk situation for the commitment.
External parties could also be of help. Take, for
example a risk analysis workshop for a project. If
both the steering committee and the project team
participate this will help us in identifying the entire
risk situation and to gain support for it both inside
the project and in the line organization.
For each risk we need to assess both the probability
that the event will occur and the effect if it does.
Then we need to decide upon a strategy for each of
them. There are basically two ways of handling
risks:
1. We take action to reduce the probability and/or
the effect of the risk. It could be, for example,
building a prototype. The actions agreed upon
should be incorporated in the commitment and
planned for.
2. We agree on an alternative plan for what to do
if the risk becomes reality. Any additional time
and resources needed if the risk becomes due
should be controlled by the assignor of the
commitment until this is the case.
When doing risk analysis, for example in a project,
it is important to focus on actions to prevent threats
to the project instead of nagging about problems
inside and outside the project. Problems are not risks
– they are reality! Of course problems should be
taken care of, but the risk analysis is not the forum
for it.
We also believe that many organizations and
projects today focus too much on the risks outside
their scope of influence instead of focusing on
actions and a strategy that make them less
vulnerable to these risks. A typical example is the
software subproject constantly reporting about the
risk that the hardware is delayed while the hardware
subproject is reporting the risk that the software
people are changing the requirements all the time.
Maybe the software and hardware people should
meet and try to be proactive about these
apprehensions instead of using them as “easy
escapes” from their commitments. When risks are
used as excuses why things go wrong they definitely
indicate an absence of commitment culture.
5.4 Accept or Say No
Now it is time to make up your mind. Will you take
on this commitment or do you think it is not possible
to commit?
Here comes another fundamental thing about
creating a culture of commitments, the right to say
no. If this is not an option, the commitments, we say
we make, will be very weak.
Also here there is a delicate balance that has to be
kept. You could express your culture of
commitments in two ways:
• You should always fulfil what you have
promised.
• You should never promise more than you can
keep.
Actually we think that both statements are needed
and that the risk of being too defensive as a result of
the last one is compensated by the fundamental
belief that everyone wants to produce good results
and succeed. Maybe the following sentence is the
best way of expressing what we are after:
• Never promise to fulfil a commitment that you
know will be impossible to fulfil.
It is quite obvious that this is a pretty stupid thing to
do, but still we are sure that you have done it
yourself several times just to tell someone what he
or she would like to hear. Who is fooling whom the
most is very hard to decide.
When saying no it is though very important to be
constructive. It is probably possible to change some
prerequisites in order to make it possible to take on
the commitment. It is this dialogue where both
parties actively ask, suggest, and negotiate to ensure
a mutual view of the commitment that we are aiming
at. Then the parties come to an agreement.
6. Monitor and Take Action
Now, having agreed on the commitment, we have to
fulfil what we have promised. We work hard and
smart, but that is not enough. We have to monitor
where we are along the way and also predict
whether we will be able to fulfil our commitment as
agreed.
6.1 Monitor where you are
Monitoring means regularly checking that the work
adheres to the schedule and that we can still fulfil
the commitment. We need to ask ourselves the
following questions along the way:
• Is the quality of the work done so far in line
with the agreed quality?

• Is the work done so far in line with the idea and
the purpose of the commitment?
• How much work is done?
• How much work is left to do?
• Will this amount of work be possible to
complete before the agreed delivery date?
• Are there any opportunities for improvement?
In quality? In time or cost?
• What about the risk situation?
• Is there is a problem to deliver as agreed? If so,
what actions could be taken to deliver as
promised?
These questions apply for all levels in an
organization or project. It is your responsibility as
the assignor of the commitment to continuously ask
these questions and it is your responsibility as the
assignee of the commitment to answer these
questions.
In order to answer these questions you need to
visualize the status of the commitment. Incremental
development, quality assurance activities, and
tracking the commitment using metrics such as
effort and defects are examples of complementary
techniques for doing this. Ref. [1] provides
inspiration for how to visualize commitments on
different levels in an organization by using effort
metrics.
Regarding the risk situation we monitor the actions
that we have decided to take in order to reduce risk.
These activities are part of the commitment and are
thus included in plans and estimates and can be
monitored just as any other activity.
We also perform risk analysis repeatedly in order to
identify new threats to the commitment. Any new
risk that cannot be handled within the scope of the
commitment should be discussed with the assignor
of the commitment. We need a decision on how to
handle such risks. We also need to analyse the risks
that we earlier decided to do nothing about if they
do not become reality. Has the situation changed in
some way? Are they still valid?
In a time to market focused world answering these
questions should be on the top of the agenda at all
steering committee meetings and design team
meetings as well as in your own thoughts about your
individual tasks!
6.2 Honk in time
The absolute fatal thing to do when realizing that a
commitment will not be fulfilled is of course to say
nothing about it. The following sentence explains
the value to be followed.
It is ok to fail, but it is not ok to fail in announcing in
time that you will fail.
By announcing problems and trying to find solutions
for them early, we will of course improve our
chances of fulfilling our commitment. A rule of
thumb defining “in time” is the following:
You should never announce a delay extending half
of the time left to the agreed delivery date.
If you are you have not been monitoring your work
properly. Announcing a two-week delay two weeks
before the agreed delivery date is not acceptable!
You should have known this earlier!
The only exception to this rule is when a risk
becomes due. If, for example, we have decided to
live with the risk of being dependent upon a key
person and this person becomes ill the risk is due
and we need to manage this situation as we planned
when we decided to live with this risk as discussed
in section 5.3.
6.3 Take Responsibility and Take Action
Consider a steering group meeting. The project
manager reports that the current estimate is that the
project will be three weeks delayed due to some
problems with the development environment.
Just coming to the steering committee with this news
will not do! It is the responsibility of the project to
come up with some bright ideas about what can be
done to get back on track. If these suggested actions
need some additional resources outside the defined
scope it should be presented to the steering
committee. If not, it is an internal project issue. This
principle goes for all levels in the organization. In
this case maybe a design team hiring an expert for
two days could solve it and then the steering group
would not even have to know about it.
This was about the assignee’s responsibility. What
about the responsibility of the other party, the
assignor, then?
Well, her main responsibility is making decisions
and taking responsibility for the effects of these
decisions. If you do not realize that this is your main
job, you should immediately leave the steering

committee or the role as line manager, project
manager, team leader etc.
In this example, if the project manager did suggest
that she needs two more persons in the project in
order to still keep the time schedule, what are then
the options for the steering committee? Mainly two:
• Accepting this additional cost in order to deliver
on time. Decision that the project cost can
increase.
• Accepting the three-week delay of the project.
Decision that the time schedule has been
extended by three weeks.
Compromises in-between these two alternatives are
also of course possible and the steering committee
may also suggest and discuss alternative solutions
with the project manager. However, trying to push
the problem back to the project manager by saying
“We can not accept any additional costs and the
delivery plan is settled with the customer so it can
definitely not be extended” is not an option! This
kind of behaviour only indicates the following:
• You have no trust in the project manager – if
this really is the case you should take actions
towards replacing her.
• You are not willing to take any responsibility
for the project – if this is the case the rest of the
organization will have a good excuse for acting
in the same way.
If you want to implement a culture of commitment it
is vital that all levels within the organization act
according to the same values and this goes
especially for the management.
7. Making it Real
We already mentioned that commitments are about
attitude. However, some techniques and lessons
learned may help.
7.1 Linking Commitments at Different Levels
When we perform a task that involves several people
we make commitments at different levels. These
commitments need to be linked together to form a
whole.
Consider a project. When it is started we need to
make a plan that shows the big picture for how the
project will be executed. This project plan is part of
the agreement between the project and its orderer in
the line organization. It also serves as a framework
and reference for monitoring the project by tracking
time and effort throughout project execution.
It is not advisable to incorporate all kinds of details
in such a plan since we do not know everything
about the task, about what resources we will have
access to, and so on. Therefore, we work with
commitments that occur at different times and on
different levels in the project. Consequently, as
illustrated by Figure 3, we need to work with
planning and tracking on different levels of the
project. At the same time, everything has to combine
to form a whole.
Figure 3. Planning and Tracking on different levels.
When a commitment is made the corresponding plan
is frozen. Effort dispersed in time assigned to the
different activities of the frozen plan is called
baseline work. Throughout the execution, actual
work and remaining work are collected and
compared to baseline work. If an activity is, for
example, delayed we need to re-plan that activity.
However, we do not change baseline work, our
reference for comparison.
When a plan is broken down into plans on a lower
level, new commitments are made and new baselines
are established. If, for example, an activity is broken
down into 10 smaller activities the sum of the
baseline work for the 10 activities need not be the
same as the baseline work for the overall activity.
This is because we might have gained insight since
the overall plan was established. However, this
gained insight should not have any influence on the
baseline work on the higher level – we still want to
compare ourselves towards the original baseline on
that level. However, when baseline work is
established on a lower level that will provide input
for the planned work on the higher level.
Since plans on a lower level are more detailed they
have a shorter time frame as indicated by Figure 3.
By repeatedly breaking down the near future of an
overall plan into detailed plans we can move the
time frame continuously, while keeping the baseline

work on the overall level as a reference for
comparison.
This approach to planning and tracking of the
project is not a replacement for methods like
incremental development. They rather complement
each other and they should be combined.
Basically we think that there are three different
levels in a project where we define commitments,
namely:
1. Project level
2. Team level
3. Personal level
The project level commitment is documented in a
project definition including an overall project time
schedule. It is agreed upon between the project
manager and the steering committee.
The team level commitment is made up by a detailed
time schedule for a part of the overall time schedule
and it could also be documented in a sub-project
definition. It is agreed upon between the team leader
and the project manager.
The personal level is made up by a personal time
schedule. It is agreed upon between the team leader
and individual team members.
There could of course be additional levels in-
between the team level and the project level, but that
does only imply that there will be an additional team
level. Also, the fundamental mechanisms of
commitments are the same on all levels.
It is very important that all the three levels are
covered when implementing a culture of
commitments – lacking for instance the personal
level will be fatal.
7.2 Active Planning & Tracking in the Team
At the team meetings every Monday morning the
whole team participates in reporting, discussing,
feedback, analysis, and planning. The current tasks
of the team are walked through one by one. For each
task status, technical difficulties, risks, and actions
are discussed. At the same time effort data is
collected – how much effort has been spent on the
task and how much is remaining. The whole team
makes a joint estimate for the remaining work of the
task and makes a plan for that.
Today’s status is compared with the commitment. If
a task is found to be off track the team need to take
actions to get it back on track. If this is not possible,
the team need to analyze the consequences for the
higher-level commitment on the team level. Maybe
it is needed to re-plan some other tasks in order to be
able to fulfil the team’s commitment towards the rest
of the project. If that is not possible, the team need
to give notice to the project management – the
situation cannot be handled within the team and its
level of authority.
Each team member brings her personal time
schedule for last week to the meeting. In that
schedule she has taken daily notes on how much
effort she has spent on different activities and she
also made estimations for remaining work for the
activities she has committed to. These estimations
are input for the joint estimate made at the meeting.
The team member also brings a preliminary time
schedule for the current week, which also comprises
her commitments outside the team in question. As
the meeting proceeds, the team member updates her
personal schedule for the current week.
The schedule of the team is also updated as the
meeting proceeds, but of course, the team leader
spends time doing analysis and planning before and
after the meeting as well. A computerized tool is
used to generate graphs that visualize the progress of
the team from different perspectives. The tool is also
used to couple the tracking on the team level to
tracking on higher levels in the project and in the
organization.
In between the team meetings each team member
updates her personal schedule with the actual work
spent on the different tasks. It is important that this
is done on a daily basis and that all working time is
allocated to activities.
The advantage of this approach is that the whole
team is active in the planning and tracking process.
Everyone’s unique knowledge is utilized and
underlying assumptions and priorities can be
communicated and questioned. As a result of this we
will have a dedicated team willing to commit to their
tasks.
7.3 Organizing the R&D
The previous two sections discuss techniques for
implementing a commitment culture on all levels in
a project. However, it is not enough if this is valid
only in the projects – it must of course be valid in
the line organization as well. So far the role of the
line organization have been mentioned when
describing the role of the steering committee.

Lessons learned show that in order to be an effective
organization regarding decision making you cannot
have different steering committees for projects
within the same organization. Our experience is that
it is better to have one steering committee in order to
make priorities between the different projects and
long/short term goals. This steering committee must
contain persons responsible for the resource
allocation between the projects. In fact, all members
of the steering committee should be there for some
reason – they must all have the authorities needed in
order to make decisions and take responsibility.
Often there are also conflicts within the matrix
organization. The line organization is usually
responsible for allocating resources and the projects
are responsible to reach their project targets. The
two parts then have goals that could be in conflict
with each other.
As we see it the line organization is also responsible
for the success of the project. A line manager has, as
the orderer of the project, delegated the execution of
the project to a project manager, but cannot escape
from the overall responsibility as discussed in
section 4. Allocating project responsibility within
the hierarchy of the line organization is then a wise
thing to do. This means that the project hierarchy
should be reflected in the line organization. Now the
line organization’s objectives are more in line with
the objectives of the different projects. It is then also
important to allocate the funding of the projects to
the concerned line managers. Now, having authority
over both money and people, the possibility for
decision-making has improved dramatically also on
lower levels of the line organization. This means the
risk that the top management becomes a bottleneck
in making decisions is reduced.
Now we can also define a clear responsibility
between the line organization and the project.
Project:
• To execute the project as agreed with its
orderer.
• To monitor and report status.
• To handle changes and risks that is within the
scope of the commitment.
• To work proactively on the risk situation, for
example:
 Formal risk analysis, for example, once
every quarter.
 Continuously monitoring the risk situation
at project and team meetings.
• To give alternative proposals for how to handle
situations exceeding the project’s authorities.
Line organization:
• To request the status of the project.
• To prioritise between different projects.
• To prioritise between long-term (beyond
running projects) and short-term goals.
• To make decisions that create new prerequisites
for the project.
• To control resources for handling risks that we
are not trying to eliminate.
8. Conclusions
In a world where R&D is becoming increasingly
important and speed is not only a matter of
competitiveness, but a matter of survival we have to
provide an R&D environment where people are
inspired to take responsibility and to deliver as
promised. We call this working environment a
culture of commitments.
A committed R&D organization is built upon the
genuine interplay by management and staff, by
projects and the line organization, characterized by:
• Personal commitments on all levels
• Great responsibility assumed by all parties
• Constant striving for the objectives
• Proactive risk management
• Failure is looked at as valuable experience and
is used to avoid future mistakes
Everyone in the organization needs to stand up for
this behaviour in order to obtain a culture of
commitments. Changing behaviours is tough.
However, striving for a culture of commitment is
worthwhile since a lot of good things are achieved:
predictability, personal growth and team spirit; to
name a few. We really believe that a culture of
commitments is essential for all R&D organizations,
especially those focusing on time to market, in order
to be able to answer the question “When will you be
done?”

9. References [1] Höglund M. Efficient and Effective Use of Effort
Metrics. The European Conference on Software
Process Improvement (SPI 99), Barcelona, Spain,
1999.

committed

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (17)

Similar to committed

Similar to committed (20)

committed