ArticlePDF Available

Supervising Projects You Don’t (Fully) Understand: Lessons for Effective Project Governance by Steering Committees

Authors:

Abstract and Figures

Strategically important projects involve high stakes, uncertainty, and stakeholder complexity, with contingencies and risks typically surfacing repeatedly as the project evolves. This is challenging not only for the project team (PT) but also in particular for the steering committee (SC), the top management oversight structure typically used to align a project with the organization’s strategic goals. This article explores how senior executives on SCs can exercise leadership and effective oversight of strategic projects, although they have only limited time and often incomplete expertise. The SC can keep a project aligned, even with limited time, through focused understanding of the key logic and drivers of the project. The SC needs to manage the surprises and crises that inevitably arise in a difficult project through proactive analysis that goes to the bottom of the problem and by working with the PT to generate solutions.
Content may be subject to copyright.
Supervising Projects You Don’t (Fully) Understand: Lessons for
Effective Project Governance by Steering Committees
Christoph Loch, Magnus Mähring, Svenja Sommer1
June 2016
Accepted for publication in California Management ReviewWorking paper version
Abstract
Strategically important projects involve high stakes, uncertainty, and stakeholder complexity, with
contingencies and risks typically surfacing repeatedly as the project evolves. This is challenging not
only for the project team, but also in particular for the steering committee (SC), the top management
oversight structure typically used to align a project with the organization’s strategic goals. Our paper
explores how senior executives on steering committees can exercise leadership and effective oversight
of strategic projects, although they have only limited time and often incomplete expertise.
We identify five themes of oversight: steering committee composition, goal agreement, project
team motivation and control, intelligence gathering, and managing surprises and change. We show
that a SC can keep a project aligned, even with limited time, through focused understanding of the
key logic and drivers of the project. The SC needs to manage the surprises and crises that inevitably
arise in a difficult project through proactive analysis that goes to the bottom of the problem and by
working with the project team to generate solutions. This article thus offers insights and actionable
advice on a paradoxical challenge of executive work: providing meaningful guidance and governance
in contexts where time is scarce, information is potentially unreliable, and you don’t fully understand
the complexities and implications involved.
Keywords: strategic projects, project supervision and oversight, project governance, steering committee work,
focused understanding, managing surprises
1!Christoph H. Loch is Professor of Management and Dean of the Judge Business School, University of
Cambridge, UK, c.loch@jbs.cam.ac.uk. Magnus Mähring is Professor of Business Administration at the
Stockholm School of Economics, Sweden, magnus.mahring@hhs.se. Svenja Sommer is Associate Professor
in the Information Systems and Operations Management department, HEC Paris, France, sommers@hec.fr.
1
1. Introduction
If you have a nagging feeling of worry about some of the strategically important projects in your
organization, you are in good company. Many senior executives are frustrated with how difficult it is
to influence projects, whether in order to align them better with strategy, manage risk levels, get ailing
projects back on track, or even get valid information on them in the first place.i Executives on project
steering committees sometimes describe themselves as hostages, overwhelmed by myriad opaque
technical issues and by the difficulty to really understand what is going on.
At the same time, the role of top management is crucial,ii and it goes far beyond the well-known
“sponsor” roleiii (or head cheerleader”).iv Critically, top management must monitor projectsv to
ensure that they produce value and align with the organization’s strategic goals. Typically, this takes
place through the Steering Committee (SC), a temporary group of senior executives charged with a
joint project ownership role, on top of their regular tasks, roles and responsibilities. With limited
expertise and facing severe time constraints,vi SCs have to balance support and governance and make
sound decisions.vii
Consider a project aimed at developing a new cancer diagnostic test based on a biological blood
marker, carried out at a global diagnostics company in partnership with a small biotech company: 18
months in, the project faced horrendous schedule and budget overruns, with market entry so much
delayed that profitability became unreachable, and it was abandoned. The key reason for this was
supervision failure: The large company’s SC members did not understand the uncertainty involved
and trusted the technical experts too much, not realizing that their “expert jargon” hid weak
assumptions. Once difficulties arose, the SC fell into the trap of desperately wanting the business to
materialize, dropping the issues they did not want to see until it was too late. One executive
commented: “We finally started to challenge the assumptions of the project, but we did this 18 months
too late.” Had they insisted early on a clear account of the uncertainty, the SC could have guided the
project team (PT) towards a modified development approach, including the creation of backup plans.
This could have either rescued the project to a profitable conclusion, or terminated it earlier, saving
time and money.
2
This leads us to the central leadership dilemma addressed in this article: How can the SC keep
difficult projects on track when they are not familiar with all the issues involved and have limited
time?
Prior research has remained largely silent on how SCs should fulfill the heavy responsibility of
ensuring and maintaining the alignment of a complex strategic project with the organization’s goals
and priorities. Work on SCs is scarceviii and mainly focuses on up-front composition and self-
organizationix and on goal setting.x Studies acknowledge the importance of the SC throughout the
project’s life cycle,xi its role in communication and power brokering,xii and in solving problems and
providing directions when dealing with emerging issues.xiii However, too little attention has been paid
to the dilemma of how a SC can achieve effective oversight in spite of lack of detailed expertise and
time. It is this gap that the current study attempts to fill.
In our study, we examined strategic projects that were important for the future competitive
position of the organization (and thus supervised by a senior SC); the strategic (non-repeated) nature
of the projects also made the SCs “one-time” task forces rather than standing committees. In order to
focus on the challenge of supervision when standard milestone approaches are insufficient, we asked
our respondents to consider “difficult” projects. In the words of our respondents, this meant the
following: “Insufficient clarification (and definition) of interfaces and interactions of work packages,
be the interfaces internal or external. This includes novelty and uncertainty (lack of knowledge of
cause-and-effect) as well as complexity (many interactions, either technical among system
components, or among stakeholders), explicitly forcing the SC to engage in ad-hoc problem solving
rather than mere routine milestone reviews.
2.How We Conducted the Study
To explore the challenges facing SCs and identify effective strategies for SCs, we conducted in-depth
interviews with 17 senior executives or CEOs from different industries on 29 projects (see Table 1).
To prepare our participants, we provided them with a set of questions beforehand (see Appendix). We
also asked them to prepare by thinking of two “difficult” strategic projects, for which standard
3
milestone oversight processes were insufficient: one project where SC supervision had worked well,
and one where it had not worked as hoped.
[Insert Table 1 here]
We considered three types of projects that previous research typically considered separately: R&D
projects, engineering services projects, and organizational change and IT-related projects (see Table
1). When asking about “difficult” projects, we intentionally left this term undefined because we
wanted to see what key supervision challenges would emerge. Interestingly, it turned out that in all
three project types (R&D, engineering services, and organizational change), respondents agreed on
what made a project difficult (see definition at the end of the introduction section) and on the most
important sources of difficulty: different stakeholder interests, project novelty, and project complexity
(see Table 2 for a summary). This consensus suggests that the three types of projects are not very
different for the purpose of SC supervision, and we therefore combined them in our analysis. By
categorizing the constructs identified in our analysis, we identified five themes, which we discuss in
the next section. (We provide more details on our methodology, including a consensus list of
constructs, in the Appendix.)
[Insert Table 2 here]
3.Results
What are typical mistakes made by SCs? We identified five themes of supervision challenges for the
SC: steering committee composition, goal agreement, project team motivation and control,
intelligence gathering, and managing surprises and change. Table 3 highlights typical “traps” that
each theme poses for SCs: for example (Theme 1), SCs are often put together politically rather than
expertise-covering. They also often insufficiently prepare for changing project circumstances, which
may require difficult negotiations about a new project approach. Traps also exist in how SCs agree on
project goals, how they control and motivate the project teams (PT), how they become knowledgeable
about actual project progress, and how they deal with the inevitable changes and surprises that befall
difficult projects. All of the traps in Table 3 can cause supervision to fail and projects to go wrong.
4
[Insert Table 3 here]
Themes 1 through 3 have been discussed in previous work---while the recommendations are still often
not adhered to and lead to the traps in Table 3, research has identified what should be done.
Therefore, we focus our detailed discussion on Theme 4, “Intelligence Gathering” and Theme 5,
“Managing Surprises and Changes”. In the conclusion, we incorporate the recommendations by our
respondents also on Themes 1-3, in order to provide a complete picture.
Despite the lack of prior research on Themes 4 and 5, they are particularly important for
“difficult” projects: How can the SC keep abreast of what is really going on? And how does the SC
make difficult decisions when the project is in trouble and needs to be redefined? Indeed, a lack of
understanding by the SC may contribute to surprises over the course of the project.
3.1. Intelligence Gathering - Coping with Insufficient Information
Many SCs fail to become sufficiently knowledgeable: “Some people on SCs do not invest the effort
to question and insist until they have a clear understanding of the fundamental logic and drivers. This
has two reasons, (a) because they are too busy (and do not have enough time for this important
responsibility), or (b) because they do not want to admit that they don’t know---after all, when you
have reached a certain seniority, you become more reluctant to admit in front of the ‘troops’ that there
is stuff of which you are ignorant. However, when the SC is not informed, then decisions are either
not made (one respondent called it, “the project is covered in wool and becomes opaque”), or they are
made by the PT in ways that are not necessarily aligned with the company strategy and can cause
problems later.
Two examples from two facility engineering companies illustrate how critical it is for the SC to
understand the key tradeoffs and risks in the project. In the first example, the company took on a
large, complex project that required compatibility with legacy regulations. The SC accepted the
project plan without sufficiently challenging the assumptions, failing to become aware of some
technical challenges as well as some legal regulations affecting customer requirements. As a result,
the company agreed to a project that could not be achieved within the time plan, and only after the
third schedule delay did it begin to dawn on them that this project was a bottomless pit”.
5
In the second example, the company constructed a new chemical production plant: In this
project, all key decision makers were in the SC, and everyone on the SC understood at the beginning
that this was a highly risky project. This created the willingness to openly discuss even the most
difficult issues. The SC learnt to identify the most important challenges before problems became
critical. When challenges occurred that required changes, the need for change was openly discussed,
and decisions were made quickly and unanimously to prevent the project from spinning out of control.
But how can the SC become sufficiently knowledgeable, as itcannot try to understand the
details, there is not enough time.” Our responses suggest that successful SCs approach this problem
from two sides: on their own side, they strive for a focused understanding of the project. On the side
of the PT, the SCs try to motivate the PT to reveal complete and truthful information about events. If
necessary, outside information can help to enforce minimum transparency.
1. Invest in Focused Understanding. While it is impossible to understand all details, the SC needs to
understand the logic of the project, its key parameters and key barriers to success, including an
understanding where the project novelty lies: Ideally, you should understand 70% of what’s going
on; realistically, it is often closer to 50%, but it’s not 30%.” This requires “going beyond a
consumption attitude”, to study the relevant documentation beforehand, and to question assumptions
throughout the project.
To enable this, each SC member has to repeatedly ask herself: “Have I understood this? And if
not, ask again, and if necessary, even meet with the team outside of the official SC meetings. Clarify
for yourself what questions you do have, do not simply wait for what they tell you. This allows you
plausibility checks and consistency checks.” An important aspect of this is that technical jargon must
be translated into business language that reveals the key trade-offs. “People tell you a lot of stuff in
such situations, on one extreme pseudo-plausible hot air (the lack of substance of which becomes
apparent only over time), and on the other extreme expert jargon behind which one can hide weak
assumptions and weaknesses. I have to regularly test the milestones for their controllability. I must
understand what [reaching the] milestone gives me what I did not have before: a clear analysis, a
partial functionality, a customer, …”
Exactly what is critical for an individual SC member to understand depends on her role. “Are
6
you there for general/overall input […], or do you have a specific role? Depending on your role, ask
yourself: What will help me to drive success? What will help me to understand the critical path? And,
what will help me to understand the key barriers, the contentious or scarce resources or the critical
pieces?” Finally, it might be useful to look at the project through the PT’s own eyes, for example
through site visits and informal conversations. Being in direct touch with the project often provides a
better understanding of the problem and reveals risks more easily.”
2. Get Truthful Information. In addition to getting a focused understanding of the project, the SC
also needs to “get the truth” in a timely manner, especially about critical events or mistakes later in
the project. Open discussion and exchange is a key element for this, a no-blame culture where the
“messenger is not in danger of being shot”. “It all comes down how mistakes are treated. The answer
should not be a barrage of criticism (`this HAS to change!), but working with the mistakes: the SC
must insist on a de facto correction of the error, but not necessarily with a damning reaction.
Mistakes are caused for many reasons. It is a natural reaction by the SC to become irritated when a
mistake was covered up. But the trick is to not get into a negative spiral. Make it unambiguously
clear that the rules here require openness in order to be able to collaborate, but at least the first few
times the SC should also show some understanding and sympathy. It is a trap to fall too quickly into a
suspicion of being cheated.”
A vivid example of withholding blame happened at a pharmaceutical company. The VP was on
his way to an award ceremony, where outstanding PTs were honored for their work. On the way, he
received an urgent phone from the project manager (PM), reporting that an unexpected toxicity
problem had arisen in the very drug that was scheduled to win an award. Arriving at the venue, the
VP informed the CEO. Should they cancel the award for this team? They decided to go ahead and
award the team, but afterward, they took the team aside, alerting it that top management was aware of
the issue. The CEO criticized and partly blamed the VP in front of the team for the fact that this
problem had been discovered so late. The VP, resisting blaming the team, swallowed the criticism.
This showed the PT that they could trust him as a superior and SC member, and they doubled their
efforts. Three weeks later, they made a breakthrough, reducing toxicity by 70%, so the drug could
safely go ahead. While passing the buck and blaming the PT would likely have had a demotivating
7
effect, the no-blame approach of the VP instead focused the PT on solving the problem, and instilled
them with confidence and loyalty. The PT never forgot this in subsequent projects.
3. Get Outside Information. If serious inconsistencies or problems arise, the SC may seek
additional opinions by interacting with team employees or consulting external experts. Caution is
advised, however, since this approach may be viewed as distrusting and could disempower the PM,
reducing PT motivation.
[Insert Box 1 here]
It is essential that getting additional and sometimes detailed information, e.g. from team members,
does not lead to meddling in details, or creates a concern in the PT that this might happen.
3.2. Managing Surprises and Changes
As many executives know from hard-earned experience, strategic projects of extended duration that
are novel, complex and/or involve multiple stakeholders share the characteristic that even the best-laid
plans will not come true. When surprises materialize and crises occur, the PT and the SC need to
show flexibility and have the ability to re-plan the project and adapt its goals.
For example, one of our interviewees described a construction project involving a historical
building to be partly renovated and partly rebuilt. This was a showcase project for the company, with
a major known complication, namely asbestos. A major surprise occurred, however, when the PT
realized that asbestos was not only in the walls (anticipated), but also in the load-bearing concrete
structures. Neither the PT nor the SC had prior experience with this problem, so they brought people
from different backgrounds together (engineers, supervisors, workers) and brainstormed for several
days to come up with solutions. Finally, one project engineer had the idea to apply an approach used
in underground parking garages. With some cost penalties, this solution resulted in a viable timetable
and enabled a successful completion of the highly visible project..
Our interviewees described that if the PT and SC cannot jointly address a crisis, the project
often begins to cycle through destructive phases of window-dressing (by the PT) and re-eruption of
problems, undermining the SC PT relationship. Conflicts within the SC itself also typically emerge.
How can the SC best address unavoidable surprises? Our interviews revealed six useful
8
approaches: : (1) foresee that surprises will occur, and agree on solution procedures at the outset, (2)
get informed quickly, and (3) understand the reasons for and the consequences of the event, (4) use
the PT’s expertise in getting solutions on the table, and (5) make a clear decision. Finally, (6)
experiments can be used in some cases in order to proactively learn.
1. Foresee solution procedures at the outset. The uncertainty inherent in a difficult project ideally
needs to be accounted for from the beginning. However, this aspect of project initiation is often
underplayed, partly due to a managerial craving for control” (and the fear that detailed analyses of
uncertainties can stop the project before it got started). Furthermore, unaddressed differences amongst
SC members sometimes lead to glossing over or down-playing problems (which pushes ambiguity
onto the PT’s work). Also, there is often an unfounded belief that up-front planning can reduce
uncertainty to a level that can be managed with buffers. xiv
Nevertheless, it is important that the SC already at the outset develops procedures for how to
deal with possible plan modifications: “Once the problem has occurred, it is already too late because
everybody descends into their trenches”---in other words, uncertainty interacts with the SCs ability to
maintain a common goal. The elements required for successful renegotiation include relationships of
trust among SC members, recognition of uncertainty and the resulting possibility of substantial plan
modifications in the initial plan, and the in-advance specification of a renegotiation process. Project
changes can upset the balance among stakeholders and imperil a working coalition, resulting in
conflicts in the SC. Projects will succeed only if the SC continues to find compromises that do not
create losers.
2. Get informed quickly. Even if the SC has identified operational targets that reflect (rather than
hide) tradeoffs, surprises often appear as bolts of lightning from a clear sky. When trouble hits, the
SC and PT must avoid both extremes of sticking too long with the action plan (which may be
obsolete) and of indiscriminate firefighting in response to a multitude of external events. There are
several reasons why the SC might not react to signs of trouble: (i) the SC may receive so many
complaints that it cannot respond to every alarm; (ii) performance targets may be so rigid that the PT
is insufficiently open with the SC; and (iii) the SC might “fall into the trap of desperately wanting the
business to materialize, so you do not want to see the problems… [so] you give in and drop [the ball
9
regarding] what you don’t want to see.” But to be effective, the SC needs to create a quick
reaction: The issues must be brought on the table quickly and clearly ---[I tolerate] no delay under
the mantra ‘we can still make it’.”
Realizing quickly that there is a severe problem rests on having a good “baseline” comparison,
in other words, a sufficiently detailed plan. In the words of an engineering services CEO, “A ‘first
tier’ team produces a comprehensive networked project plan with interactions, which allows a
diagnosis at any time when problems arise. This is not an issue of having captured all interactions,
but of having the critical interactions. A good base plan allows you to diagnose progress and the
effect of changes [to the plan].” #
Ensuring this openness from the PT towards the SC is directly related to the type of incentives
used in the project. “When you are doing new things in the organization, bonuses are terrible.
Bonuses assume that you know where you are going and that you make the bonus depend on the right
indicator. But that causes rigidity because when new things happen, the previously defined indicators
become wrong; they need to change. Bonuses encourage more of the same.” In other words, formal
incentives are rigid because they cement things that may need to change in the project. Similarly, if
the SC focuses only on what can be measured (using key performance indicators), this may lead the
PT to neglect to report or even hide information to protect itself, undermining trust. #
Addressing incentive issues thus requires a combination of formal and informal evaluations:
The SC should reward not only successful outcomes, but also consider effective problem solving and
open communication. “We do not have only super heroes in our organization […]. Everyone makes
mistakes, and we do NOT […] link project outcomes […] to bonuses or salaries. […], we base our
judgment on the PM’s activities: How does he keep schedules, or at least the parts that he can
influence? How does he deal with problems? Does he anticipate them or react only when an
explosion occurs? Does he push (e.g., try to change the environment and mobilize resources) when he
runs into problems, and does he seek help and support when there is danger? How does he work with
the SC to get through difficult situations?” Such an evaluation on activities rather than outcomes is
sometimes referred to as process incentives.
10
3. Understand the reasons for and the consequences of the event. When surprises do occur, it is
essential to determine whether the deviation reflects a correctable mistake, an unavoidable but minor
occurrence that can be compensated for, or grounds for modifying the plan. To allow the SC to make
this assessment, executives should “ask for an analysis of the consequences of these new
developments: […] a red yellow green assessment. If this is a red flag, you want to talk in depth
about the situation, […]”. To avoid continuous “firefighting” it is also important to assess the full
scale of the problem: “There is nothing worse than repeatedbad news and a realization that the
fresh resources that we brought to bear are insufficient.”
4. Use the PT’s expertise in getting solutions on the table. It is crucial that the SC does not impose
solutions: “It is not OK to force onto the team the solution that oneself would have chosen. Some SCs
influence the decision on the color of the linoleum floor of the facility building. This way, (a) the SC
ridicules itself and (b) you may get “funny solutions”. However, the SC does need to take
responsibility for decisions being made at all, for example by asking “Does the floor correspond to the
specs, and will it be put in place according to schedule?” If it does emerge that the original
specification of the floor was incorrect, then the SC should still not take the decision on the right
color, but it or the PM, depending on who sees this first, should raise the flag and initiate a correction
of the specs.”
Apart from the fact that the SC members typically do not have the detailed project knowledge
required to identify the best possible solution, the SC also needs to avoid demotivating the PT. Indeed,
another CEO states: “Do not meddle in operational issues (especially not when the customer is
involved). It demotivates the team because you are denying them being taken serious, and it wears
out your authority---senior managers should be brought to bear in careful dosages.”
5. Make a clear decision and articulate priorities. When changes do occur, the SC must make a
clear decision on the project direction. The SC ducking important decisions amounts to an abdication
of responsibility. For example, one pharmaceutical supervisory council was confronted with trial data
hinting toward heart-damaging side effects of a new drug. When the CEO, who had the supervisory
role for the project, was confronted with this information, “the CEO simply said, `I trust you. But
what he was implying was, `I don’t understand any of this, so you make a decision. The VPs ended
11
up taking the decision to introduce the drug. Without guidance, they settled the risk-reward trade-off
in one way, but it was not necessarily the tradeoff that the CEO wanted or that was consistent with the
overall vision of the project.
While abdication is one problem, allowing too many voices and not prioritizing what should be done
is equally problematic. Consider an electronics strategy project in an automotive company. The
project cut across multiple functions, all represented in the SC. The PT could never nail down the
stakeholders because the SC was ambivalent toward allowing enforcement of their decisions rather
than voluntary buy-in. But sound general principles often became questionable at the level of specific
processes, priorities and decisions, reducing ambition level and progress. In the end, this project
never came close to reaching its original mission. This is a common fate of projects that carry the
burden of ambivalent leadership at the SC level.
In extreme cases, when the defined context of the existing project is violated, making a clear
decision might require more than a project re-direction. Rather than “muddling through”, the SC
might want to declare the project terminated, and then start a new project from scratch where the old
one left off. The new project would have to start with a new business plan and a new resource
allocation: “Make a clear cut”, and get a fresh start, but with the knowledge and experience gained
in the previous attempt intact.
6. Use experiments. In some cases (where time is not so pressing that risks need to be taken in order
to move forward), uncertainty can be anticipated and diffused with experiments, which can help break
through problems: “It is dangerous to plan a three-year process and stick with that plan [regardless].
Had we done that, the process would have derailed a long time ago.” Unfortunately, experiments tend
to look expensive and time-consuming: In fact, only two of our respondents use experiments
regularly. However, when fundamental risks and assumptions are not understood and making
“progress” is a mirage, a small investment in an experiment may pay back manifold if it helps
uncover a major erroneous assumption. Since experiments are underused, we provide additional
details in the box below.
[Insert Box 2 here]
12
4.Summary and Conclusion
Our study shows that effective steering committee (SC) work is crucial for strategic, difficult projects.
We identified traps and problems in current practice (see Table 1 above), but also effective strategies
that executives can use (Table 4 below). Recognizing the challenge of SCs to ensure project
alignment and progress in spite of limited expertise and time, our study offers detailed and actionable
insight into how SCs can carry out their important governance and oversight responsibilities for
difficult projects.
From our interviews with senior executives, we identify five major themes of SC supervision
challenges: SC composition, goal agreement, project team (PT) motivation and control, intelligence
gathering, and managing surprises. Each of these five themes can lead to supervision and project
failure, and yet, only the first three have been discussed in earlier research., Hence we have placed
particular attention on reporting and discussing the insights related to Themes 4 and 5. Nevertheless,
we also summarize the recommendations for Themes 1-3 in Table 4 below: although they are
“known”, they emerge in our interviews as challenges, suggesting that they have not yet become part
of the standard methodology of project management in firms.
For the SC’s ability to gather intelligence to understand the project, the recommendation is,
first, focused understanding: the SC members need to spend the time to understand the key logic and
its drivers, and the key risks and their reasons. This includes insisting on a successful translation of
technical jargon into business language, and continuing to ask “dumb” questions until the SC member
can perform plausibility checks on information that comes to them from different sources. Focused
understanding requires discipline --- do not give up for convenience or because you feel that you are
“looking incompetent,” but keep going until you do understand. While seeking information from
multiple team members, resist the “shortcut” of too quickly bringing in outside experts to make
yourself more comfortable, because this might signal lack of confidence in the PT.
[Insert Table 4 here]
13
The hardest test of a SC comes when major surprises occur and the project must adjust. First, the
unfolding of this challenge is intertwined with the SC’s internal relationships and the quality of its
decision procedures. Trust and transparency is needed for the SC to be able to adapt and renegotiate
the project’s goals while coping with shifting benefits for different SC members. Second, the
capability to guide the change depends on the SC PT relationship: the SC must be immediately
informed of possible changes, not only when they have actually occurred. This requires trust (as
opposed to a culture of scapegoating or fear) and evaluation based on actions, rather than formal
incentives. Third, the SC must be disciplined enough to understand reasons and consequences for this
change, including the worst scenario, to avoid getting stuck in a piecemeal approach to fixing
problems. Fourth, the PT is where the expertise lies, so it must make solution proposals. Fifth, the
SC must make clear decisions to address the problems and make constructive changes in a timely
manner. This allows either rescuing the project to a profitable conclusion or terminating it early,
saving time and money. Finally, small-scale experimentations can be a way to break a deadlock.
All these activities require discipline, functioning relationships, engagement, courage and
know-how. SCs often fail to execute key activities across all five themes, and therefore, our
recommendations of what SCs should do are important. The respondents in this study, senior
executives with extensive experience in the management of strategic projects, all readily identified
examples from their own organizations where SCs failed. Indeed, all our study participants confirmed
that the results of this study were relevant to their organizations, and several told us that they passed
the initial study report on to their project management staff in order to incorporate some of the lessons
into corporate procedures and practices.
As the number of organizations in our study was limited, we sought the opportunity to obtain
more evidence for the robustness of our findings in two workshops, one with 21 Swedish IT
executives and one with 32 Swedish senior executives from the financial services and healthcare
sectors (for details, see Appendix). Both sets of participants recognized and found useful the five
supervision themes and confirmed that in their experience, more than one of the themes was often not
well managed. The weaknesses they pointed to were spread over all five themes---they all are
relevant for diagnosing whether and where an organization’s SC activity can be improved.
14
Our findings cut across the fields of leadership and project management, helping executives
strike a careful balance between helpful top management involvement and destructive meddling, and
to direct their efforts towards workable strategies for oversight and guidance of the strategically
important projects that are crucial for organizational renewal.
15
Appendix: Research Methodology
Our study derives an empirically grounded framework inductively from the data collected through our
in-depth interviews with executives.xv The reason for this methodological choice is that there is no
distinct theory of project supervision that could be testedprevious work has pointed to a broad set of
issues that might be at play, such as incentives, information asymmetry, problem solving, team
support and motivation, resource allocation, unaligned interests, information ambiguity, and
complexity, but no causal theory of what makes supervision effective has been developed. Therefore,
we identified patterns of responses from the experienced executives, comparing their descriptions of
effective supervision and ineffective supervision.xvi
All three authors used their industry networks to approach companies. The following sampling
strategy was used.xvii We focused on executives with extensive experience on steering committees,
who have seen their share of project disasters and successes, and who have amassed experience on
how to steer projects. As previously described, 17 senior executives or CEOs from different industries
were interviewed, capturing data on 29 projects. Interviews were semi-structured, we employed an
interview protocol (Text Box A1) to guide the interview, and a set of questions was shared with
interviewees beforehand. A third of the interviews were conducted by two authors for mutual
calibration, the remaining by one author. Each author wrote a detailed transcript of the conversation
the same day (the “24 hours rule”)xviii and shared it with the other authors. Each author analysed all
interview responses independently and produced a table of emerging patterns and constructs. The
authors then compared their proposed constructs and reconciled differences (see Table A1).
In order to provide more background on our data and analysis process, we provide three tables
summarizing detailed quotes from respondents on the key themes discussed in this article. Tables A2
and A3 correspond to action points one and two of Section 3.1 respectively; Table A4 corresponds to
action points in Section 3.2.
As with all research, the question of robustness of research results is important. For our study,
three aspects strengthen the likelihood that our results will we applicable and useful in cases and
settings beyond those included in the study. First, our study covered a wide range of projects and
16
found consistent patterns and results across projects, with different technical and organizational
complexities and challenges, in different industrial and geographical settings. Second, while some of
our results are novel and have not been addressed previously, within those themes already identified
by earlier research, our results are consistent.
Finally, we obtained additional feedback on the framework, both from several participants in
the original study and from executives not previously involved in the study. For the latter, we
conducted two workshops with executives to tentatively test our framework and recommendations,
one with 21 Swedish IT executives and another with 32 Swedish senior managers from the financial
services and healthcare sectors. Participants were first introduced to the framework and then asked to
consider its the applicability in their respective organizations, indicating on response sheets which
themes they saw as particularly important and their organizations’ relative strengths in the different
themes. Both sets of workshop participants recognized and found useful the five supervision themes,
and confirmed that in their experience, more than one of the themes were often not well managed.
During a follow-up discussion, the weaknesses in organizational practices that they pointed to were
spread over all five themes, indicating that the themes are all relevant for understanding and
improving an organization’s SC activities in many organizations. Finally, we also asked participants if
they could identify additional themes that were not included in the framework, but no such themes
surfaced.
[Insert Text Box A1 here]
[Insert Table A1 here]
[Insert Table A2 here]
[Insert Table A3 here]
[Insert Table A4 here]
1
Table 1: Interviewees and example projects
Industry
Country
Success Project
Failure Project
1. Car
manufacturing
Germany
(General issues discussed but no specific projects
given)
R&D Projects
2. Car
manufacturing
Germany
Vehicle development
Pre-development
3. Car
manufacturing
Germany
New vehicle concept
development
Address system
interactions across car
4. Owner
Investor
Israel
New printing product
that would kill current
product line
Intestinal cancer marker
based on new technology
5. Pharma-
ceutical R&D
Belgium
New risky compound
Trial with unexpected
negative outcomes
6. Pharma-
ceutical R&D
Germany
Development collab.
with large US partner but
from another industry
Development collaboration
with small Asian partner
7. Chemical
engineering
Germany
Two projects each with strengths and weaknesses:
high-risk new technology, and collaborative work with
business units.
8. Hospital
Sweden
Organizational
restructuring (into
divisions)
Shared patient
documentation across
hospitals
Organizational change projects
9. Truck
manufacturing
Sweden
Global order
management for
customized trucks
Solution for process
support of reseller service
provision
10. Power
Electronics
Germany
Cross-functional
technology development
Corporate sustainability
strategy
11. Local
Health Care
Authority
Sweden
Patient record
consolidation into one
system
Shared data management
across hospitals
12. Banking
France
(general issues discussed but no specific projects
given)
13. Tele-
communication
Sweden
Personnel integration of
an acquired company
Salary administration after
a merger
14. Software
Germany
System to allocate
employees to service
projects
Knowledge management
system
15. Engineering
Services
Germany
(general issues discussed but no specific projects
given)
Engineering
services projects
16.
Construction
France
One project with strengths and weaknesses:
construction of a new type of building
17. Engineering
and machinery
Germany
Chemical production
facility at unprece-dented
scale on another
continent
Development of
emergency power
generators for nuclear
plant
2
Table 2: Sources of supervision challenges
Case No.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Sum
R&D!
Organizational!Change!
Stakeholders!
x!
x!
x!
x!
x!
x!
x!
x!
x!
x!
x!
x!
13!
Novelty/!
uncertainty!
x!
x!
x!
x!
x!
x!
x!
!x!
x!
x!
x!
11!
Complexity!
x!
x!
x!
x!
x!
x!
x!
7!
Lack!of!ownership!
x!
x!
x!
3!
Method!rigidity!
x!
x!
2!
Table 3: Themes of SC Responsibility and Challenges
1. SC
Composition
2. Goal
Agreement
3. Motivation and
Control
4. Intelligence
Gathering
5. Managing
Surprises and
Changes
Challenges in SC
creation:
Temptation to
include everyone
“who is important”
or “everyone even
remotely concerned”
Challenges regarding
SC discipline:
“Just show up
between other
responsibilities”
Lack of procedural
agreement leads to
breakdown of
collaboration when
things get difficult
Challenges:
Conflicts of
interest of
stakeholders
are “swept
under the
carpet”
In order to
avoid conflicts
in the SC, goals
become too
vague to be
measurable
Challenges for incentives:
Bonuses lead to “more
of the same” behavior,
or incentives absent,
leading to PT having
nothing at stake
Challenges in motivation:
Micro-manage on the
one hand, or over-
reliance on trust,
effectively abdicating
responsibility
SC blames and thus
suppresses open
discussions
Challenges for
detecting deviations
from plan and
getting project back
on track:
SC does not
understand key
drivers and
barriers
SC fails to ensure
that information
it gets is valid
SC meetings are
ceremonial, do
not challenge
assumptions
Challenges:
obsolete action plan
maintained too long
Inadequate response to
changes, e.g.,
firefighting or incorrect
interpretation
changed situation
changes interest
constellation among
stakeholders, and
collaboration within SC
is lost
SC does not provide
clear decisions
Box 1: Strategies of Acquiring Information from Multiple Sources
Building additional information channels may help:
Make field visits: “I visit the units (straight into the field) to take a look at what was going on. If you are the
captain you have to walk the deck at times, not just stand on the bridge.” According to another CEO, “You
cannot understand a facility project unless you have gone to the site to see it.
Go to trade shows and see artifacts, even “wear different hats” and talk to people informally, without relying
on your official position.
Look for friends who have access to and can provide additional, perhaps diverging, information. For
example, board members, other people who know the industry. Sometimes, you might even call on a PT
member “socially” (it is a “non-meeting”, perhaps even “non-quotable”, so you get sensitive information).
Create an advisory group of external people.
However, external opinions, especially formal reviews, are to be treated with caution because they can also do
damage, as external experts may not understand the strategic priorities or have their own agendas:
What is the “right” external opinion? “I trust the people in my organization (within limits) to try to do the
right thing. I do not have that trust in external advisors; they too often try to tell you what they think you
want to hear.”
While many interviewees advocated searching for information anywhere you can get it, some advised
caution about appearing to break the chain of command: “I do not go around spying behind the back of the
PM. If I meet team members lower down and talk to them, that is happenstance.”
3
Box 2: The Need for Experimentation and Iteration
When you do not get credible answers, [because the team does not know how to proceed]… the process becomes
iterative. You can set a general direction and an overall vision, but you don’t know all the conditions from the
beginning and the environment changes, and you have to take that into account.… We do a trial first, but always
formalize what we do. The trial becomes a written assignment, with a defined task for that phase.
Example from one Respondent: How Experimentation Works
When an ad agency designs an ad, a proof needs to be approved before the offset press starts running it in large
quantities. We developed a normal laser printer to provide this proof, “simulating” the offset press at only 10%
of its costs. But since this digital proof is not 100% “true”, the designers refused to sign off the digital proof: we
faced market resistance.
Trying to address the discomfort of the ad designers, we got into preliminary test prints that did not commit
anyone. The people who received them liked them, worked with them, and became comfortable with them.
This, first, already generated a business (although smaller than originally foreseen), and, second, after two years
the organizations had become so comfortable with the digital proofs that ultimately the final offset proof became
irrelevant. Everyone had learned to interpret and work with the (less than perfect) digital proofs. Thus, we had
indeed overcome the market resistance.
More generally, when surprises happen causing resistance, you ask, “Can we conceptually break the resistance
down into smaller components, or redefine it?” For example, you go from the “true” offset proof to the interim
(approximate) digital proof. You create micro-level experimentation to create something that works. This is a
trial-and-error decision process that can, of course, also lead to termination at any point.
Table 4: Summary of Recommendations for Effective Steering Committee Work
1. SC
Composition
2. Goal Agreement
3. Motivation
and Control
4. Intelligence
Gathering
5. Managing
Surprises and
Changes
Manage SC
creation:
Key stakeholders
represented, but
not more than 6-8
people,
Every member
understands
his/her own role
of what s/he can
contribute
Set up governance:
Agree on meeting
rules, procedures
for negotiation
and decision
making
Invest in
relationship and
trust building.
Articulate conflicts of
interest and produce
workable and stable
compromises: build
win-win spirit
Translate desired
business contribution
into clear, operational
deliverables that can be
translated into
measures (measures to
be developed later by
the team)
Produce detailed
scoping document:
required actions, rough
budget, important
conflicts and tradeoffs
among goals, required
expertise, key barriers
and risks, and areas of
insufficient knowledge;
candid working
document, not political
statement.
Ideal PT has right
competence mix
and experience, but
often PT is already
in place when SC is
established
Incentives: not only
quantitative
indicators but also
process goals:
professionalism,
communication,
and resourceful-
ness. But here
must be no
possibility to profit
from failure
Motivation: avoid
both micro-
management and
pure trust (verify
key tradeoffs),
build culture of
openness, coach the
PT.
Invest in focused
understanding:
understand logic
and risks, challenge
assumptions, force
translation of
technical issues into
business issues,
have first-hand
information
Get truthful
information:
maintain no-blame
culture, don’t rely
only on outcome
incentives
Get outside
information: field
visits, external
visits (etc.), but be
wary of external
expert opinions
(which have their
own biases).
Establish SC problem
solving procedures at
the outset, to
maintain win-win
relationship
Get informed quickly
(standard of proactive
reporting)
Understand reasons
and consequences of
change (“get to the
bottom”)
The PT is responsible
for generating
solutions
Make a clear decision
Use experiments to
learn and explore
available approaches.
4
Text Box A1: Abbreviated Interview Protocol
(I) Check how the interviewee categorizes routine/straightforward and difficult projects or not
1. In your opinion, do different types of projects require different styles of project supervision, or is there a set of
rules for project supervision that make you successful in the management across different project types?
2. What project characteristics do you look at? In other words, are there different types of projects in your mind,
and if so, how would you describe or distinguish them?
(II) Description and classification of the two projects chosen
3. Tell us specifically why the two projects that you want to describe were “difficult” rather than “straightforward”.
4. What were the “symptoms” that make you assess their supervision as effective in one case and less effective in
the other case? I.e., what project characteristics or evolution or outcome (or what else) lead to the conclusion for
governance?
5. What were the key reasons why supervision was effective in one and less effective in the other case?
(III) Questions related to project supervision (each question to be asked for BOTH projects,
contrasting them directly during this question)
6. What kinds of targets do you set; what kinds of intermediate targets/ milestones? How do you assess how
challenging the target is? Do you use targets that are connected not to outcomes but to activities or processes
used?
7. What do you try to understand about the project, and what do you let go? How do you learn enough to supervise
the project (e.g., briefings, customer discussions, etc.)?
8. Do you give guidelines or help with respect to the chosen priorities or required actions?
9. How do you ensure that the chosen activities are appropriate for the target?
10. How do you measure progress? How do you ensure that the milestones are appropriate, and how do you monitor
them?
11. Do you supervise different parts of the project differently? How do you prioritize the areas of the project that
you get more involved in?
(IV) Questions related to alternative management strategies
12. Do you recall an instance where a project discovered significant knowledge gaps during execution: in such a
case, do you support anything different from the usual milestones and target delivery planning in the project?
13. Did unforeseen changes/surprises come up? Do you prepare for unexpected deviations? If yes, how?
14. How do you deal with surprises or deviations, especially if they relate to performance problems?
15. In particular, do you allow (or even support or enforce) changes in the project’s targets? Under which
circumstances? How do you update your milestones?
16. Before allowing for changes in the target and / or milestones, how do you ensure that you learned the truth about
the current status? How do you differentiate whether the change w as caused by an unforeseeable event or was
caused by a lack of “diligence”?
(V) Questions related to team motivation (“control variables”)
17. How do you interact with the project team members (e.g., formally versus informally, with what frequency, how
much time do you spend, do you act as a listener)?
18. How important are transparency of decisions and discussions of decisions before they are finalized with the
project team?
5
Table A1: Raw interview constructs and categorizations from coding
!
!"# $%&'()*'+),('-./0'(&1 2(&&.31 %4)516
Case%Nr. 7 8 9 : ; < = > ? 7@ 77 78 79 7: 7; 7< 7=
(,41-+ABC(51 %+')(+A D D D D D D D D D D D
5,EF-1D)+A .G+'6H.I.+150(,-,&AB'%50)+15+C%1.
I.J)6+%K.H(,L-1J&1M
D D D D D D D
6+'H10,-J1%6.G1 D+1%('-B)(+1%('-B.5C-+C%'-N .
,L(1%60)FN.(CEO1 %N.)(+1%16+6N.&,'-6M
DDDDDD DDDDDDD
E1+0,J.%)&)J)+A.B.E,J) P)5'+),( D D
-'5H.,P.,L(1%60)F D D D
)J1()+P A.H1A.)66C16.'(J.1D1%5)61.QCJ&E1 (+ D
J1P)(1 J.E1EO1%60)F.GH1A.6+'H10,-J1 %6N.
61(),%N.-)E) +1J.6)*1M
D D D D D D D
(,%E6.G5,EE)+.+)E1N.5C-+C%1.,F1(( 166N.
,F1(.J)65C66),(6N .(,.F%16+)&1M
D D D D D D D
E11+)(&.F%,51JC%16.'(J.%C-1 6.GF%161(51N.
'&1(J'N.E)(C+16N.J,5CE1(+'+) ,(N.J15)6),(R
E'H)(&.F%,5166M
D D D D D D
!1-'+),(60) F6.'(J.+%C6+.G&,,J.%1-'+),(60) F6.
L)+0)(.3/N.F1%6,('- .(1+L,%HN.Q,)(+.&,'-6.
O1P,%1.6F15)'- .)(+1%16+6N.F%166C%1.PC(5+),(6.
+,.5,,F1%'+)41M
DDDD. D D D D D D D D
/-1'%.&,'-6.'(J.&,'-.J1P)() +),(6.'(J.
J15)6),(6
D D D D D D D D D
S%,O-1E.%1J1P )()+),(.GE,JC-'%)*'+),(M . D
P,5C6.,(.E')(.)66C16.G<@T.)6.1(,C&0N.+%'PP)5.
-)&0+6..L1)&0+1 J.5,EO)('+),(.,P.1DF1%+6M
D D D D D D D D
'66CE1.F1%6,('-.%16F,(6) O)-)+A.G'6H.C(+)-.
A,C.C(J1%6+'(JN.J,(U+.6)&(.L)+0,C+.
C(J1%6+'(J)(&N.0'41.A,C%.,L(.,F)() ,(.,(.
+01.J)%15+),(M
DDDDDDD
C(J1%6+'(J.+'%&1+6.'(J.J1-)41 %'O-16. D D D D D D D
C(J1%6+'(J.C(J1%-A) (&.-,&)5.GF%,O-1E6N.
6,-C+),(6N.5,(61V KW.6+%'+1&ABOC6)(166.5'61W.
J14)'+),(6M
D D D D D D D D D D D D D
C(J1%6+'(J.H1A.%)6H6. D D D D D D D D D D
C(J1%6+'(J.1DF1%+) 61B'++)+CJ1B'O)-) +A.,P.SX.
'(J.F%,Q15+.+1'E
D D D D D D.
50'--1(&1.'66CEF+) ,(6.G+%)'(&C-'+),(N.
5,01%1(+.6+,%AN.F'%+)5)F'+1.)(.1DF 1%)E1(+6M
D D D D D D D D D
Y,,H.L)+0.A,C%.,L(.1A16 D D
)(P,%E'-.E11+) (&6.L)+0.SX.G'(J.+1'EM D D D D D D D D D D
Z%'(6F'%1(5A.'(J.P')%(166.G(,.O-'E1N.6F1'H.
CF.5C-+C%1M
D D D D D D (, D D D
1D+1%('-.41%) P)5'+),(.G,(1.1DF1%+.+,.3/N.
5,(6C-+.1DF1%+6.'6.(11J1 JN.615,(J.,F)(),(N.
O1(50E'%H)(&N.&,.)(+,.,F1%'+),(6N.4) 6)+.6)+1N.
J1J)5'+1J.[5,(+%,-.6+'PP[M
D D D D D (,. D D D D D
2EF,L1%E1(+.'(J.+%C6+.G(,.E)5%,R
E'('&1E1(+M
D D D D D D D D D D D
3+'(J'%J.E1+0,J6.G+%'5H)(&.E)-16+,(1 6N.%)6H.
+%'5H)(&N.J1P)(1.+'%&1+6N.E'FF) (&.+'%&1+6.+,.
'5+),(6M
D D D D D D D D D D D D D
\-1D) O-1.E)-16+,(16.GVC '-)+'+)41N.-1'%()(&.I.
)(+1%E1J) '+1.+'%&1+6N.)(6)&0+.E)- 16+,(16M.
D D D D D D
\)('(5)'-.E1'6C%16 D
S%,5166.)(51(+)41 6 D . D
\)('(5)'-.)(51(+) 416 (, D(,. D
])41.%16F15+.GL'-H.+01 .J15H.I.60,L.A,C.5'%1.
I.%15,&()+),(M
D D D D D D
/,'50)(&.G%1VC16+.)(P, .+,.)(P-C1 (51M D D
30'F)(&.+01.F%,Q15+.)E'&1.G)( P-C1(51.
'++%'5+)41(166.,P.F%,Q15+M
D D D D D
S%,'5+)41.%1F,%+)(&N.VC)5H.5,EEC()5'+),(.
,P.F%,O-1E6
D D D D D D D D
^1%)P) 5'+),(.L)+0.SX.'(J.+1'E D D D D D D D D D
2D+1%('-.41%)P) 5'+),(.G8(J.,F)(),(.R.1D+1%('-.
1DF1%+6N.[)(6) J1%6[M
D D D D D (,. D(, DDD(,
S%1J1P)( 1J.F%,51JC%16.GF%1-)E)('%A.+16+6.
'(J.+%)'-6N.F%1J1P) (1J.5,(+%'5+.P,%.
5,(+)(&1(5)16N .OC%J1(.60'%)(&M
D D D D
Z1'E.E'H16.6,-C+),(.F%,F,6'- D D D D D D D
3/.&)416.O%,'J.J)%15+),( D D D
_,)(+.6,-C+),(.J1 41-,FE1(+ D D D
Z'6H.P,%51 .6,-416 .F%,O-1E D D D D
Z1%E)('+1.'(J.%16+'%+ D
2DF1%)E1(+'+), ( D D
The%SC's%balancing%of%learning%benefits%and%learning%costs
Getting%the%right%information
Coping%with%
information%
asymmtery%
Understand%reasons%for%change
Responsibilities%and%solution%procedures
SC%Composition
PM%team%
incentives%and%
motivation
challenges%/%what%
complicates%
supervision
Goal%agreement
Unforeseeable%
uncertainty:%
Managing%surprises%
and%Chang e
Project%Control
6
Table A2: Quotes on Supervision through Focused Understanding
Understand the LOGIC:
WHAT should I understand? The key parameters are: Business model, unique selling points (USPs), the market, the
technology (what functionality it offers at what risks), and the competitive environment.
I don’t have the time to read everything, but I can get them to think through their situation. This is just four simple questions:
What have you accomplished so far? What have you done so far? What do you plan to do next? What are the problems/
opportunities? How you do deal with those?
When you accept to serve on a SC, you need to be clear on what is your role: are you there for general/overall input (this is
always there to some degree because the SC is, in the end, collectively responsible), or do you have a specific role?
Depending on your role, ask yourself: What will help me to DRIVE success? What will help me to understand the critical
path? And, what will help me to understand the key barriers, the contentious or scarce resources or the critical pieces?
I always try to understand [the logic] because otherwise I cannot really evaluate whether we are on the right track. People tell
you a lot of stuff in such situations, on one extreme pseudo-plausible hot air (the lack of substance of which become apparent
only over time), and on the other extreme “expert jargon” behind which one can hide weak assumptions and weaknesses. I
have to regularly test the milestones for their controllability. I must understand what the [fulfillment of the] milestone gives
me what I did not have before: a clear analysis, a partial functionality, a customer compatibility, etc.
Understand key risks and uncertainties:
I can’t just trust people, I must understand. Understanding risks is one way to learn more. Then I can say whether I have
learned enough.
The SC member should have an understanding of the probability of reaching a certain (sub-) goal, of the degree of
uncertainty. Look at the sub-goals and get an estimate of their risk, their likelihood of being achieved. Get the team to show
you the risk list and the root causes.
Part of the understanding is clarifying for yourself where the novelty in the project lies, e.g., larger than before, more
complex, new location, etc.
Question Assumptions:
I ask questions, I push for alternatives (“have you thought of x, y and z?”). However, I do NOT read all the detailed
documentation; I trust my people that they carry out technically competent work. This way, you quickly find the gaps.
The GOLDEN RULE is to never agree to or sign anything that I have not really understood. Even if there are complex
issues that I do not understand at first, I force them to explain them to me in a way that I can understand.
I make sure that I always have the relevant documentation beforehand, so I can study them. Ask clarifying questions. Go
beyond a “consumption attitude”. Make yourself detailed notes and ask the next time the questions that you had noted down.
Make an explicit comparison to the status the last time.
Ask yourself, “Have I understood this?” And if not, ask again, and if necessary, even meet with the team outside of the
official SC meetings. Clarify for yourself what questions you do have, do not simply wait for what they tell you. This allows
you plausibility checks and consistency checks (I don’t like it when teams change documents without an estimate of what
effects the change may have).
Look with your own eyes:
Part of [understanding] comes from the SC members’ responsibility to look at things themselves: reading, but also going on
site, at least once (you don’t understand a facility and a project unless you have seen the site).
I visited the units to take a look at what was going on. If you are the captain you have to walk the deck at times, not just stand
on the bridge. As a doctor you take a look at the wound. It’s also to show people that you care and that they are important.
And I get a better feel than if only listening to the project manager.
7
Table A3: Quotes on overcoming “getting the truth”
Establish a Culture of No-Blame:
Whether your people release the critical information depends on the climate that you build: no blaming is critical, making
people part of the solution and not part of the problem.
This is largely driven by how the SC reacts to problems that it is reported or finds out. It all comes down how mistakes are
treated. The answer should not be a barrage of criticism (“this HAS to change!”), but working with the mistakes: the SC
must insist on a de facto correction of the error, but not necessarily with a damning reaction (“How COULD you do this?”).
Mistakes are caused by many reasons. It is a natural reaction by the SC to become irritated when a mistake was covered up.
But the trick is to not get into a negative spiral. Make it unambiguously clear that the rules here require openness in order to
be able to collaborate, but at least the first few times the SC should also some understanding and sympathy. It is a trap to fall
too quickly into a suspicion of feeling cheated.
We created a culture in which people report their problems or even report when a colleague faces a problem.
When to Use Outside Information Channels:
[Eliciting alternative information sources] may well happen, especially if you have an intuition that something is missing.
You may sometimes ask externally simply to enrich one’s own knowledge. But if there are issues that have not been
clarified, or if there are two factions in the SC who have different interpretations or conclusions, then it is a useful exercise to
observe a question and answer exchange of a group of experts. This may (a) clarify your own understanding, and (b) the
experts become a bit more guarded in their claims when they know that other experts are present and can call them on
unsubstantiated claims.
HOWEVER:
The tendency is to first try to clarify things internally before going to the outside. First, going outside dis-empowers the
team. Moreover, it is often not so clear what the right external expert is. Often, claims by outside expert simply do not apply
to the specific situation of the project. If the SC succeeds in creating an atmosphere of openness with the team, it can create a
learning dynamic: what works for us?
I mostly talk to the PM. I do not go around spying behind the back of the PM. If I meet team members lower down and talk
to them, that is happenstance.
In an extreme case, we might decide to put a second (small) team, or an external consultant, on it to independently verify and
unearth all facts. However, this would only happen if the situation is highly confused, and/or if an important decision needs
to be made.
Another way of checking the arguments of the PM would be to carry out a formal project review with external analyses. But
this is not often done---I don’t know why, perhaps because people simply don’t think about it, because you don’t know what
is the right second opinion, and you don’t want to admit weakness or ignorance by ordering this review. Possibly, it may also
demotivate the PM by giving a sign of non-confidence.
I need to have a couple of people whom I trust AND who are close to the details and have the expertise. They represent a
second source of information because the official SC presentations are always mere samples chosen by the PM (e.g., 10
slides plus 30 backups). (…) if something comes up, I want to hear about it, to be more proactive.
There are two gaps, the knowledge gap and the context gap. The latter is the more important one, and it refers to “what does
it [the information] mean?” It requires a judgment call, for example, what they tell me about the schedule, or the market
potential, is it really true? Because it requires a judgment call, I take a “social” rather than a “functional” approach, I look for
[informal] partners for a dialogue that fills the gap [e.g., trade show, or friends].
!
8
Table A4: Quotes on how to respond to surprises and make changes
Demand proactive reporting
The issues must be brought quickly and clearly on the table.
One thing I do look at is if I was informed quickly. I do not want to be faced with a fait accompli.
Understand the reasons for and the consequences of the surprise
I try to understand the reason.
I ask whether there are alternative scenarios: “have we looked at the situation from multiple sides, [possibly uncovering
new opportunities] rather than just saying, “no can do”?
The steering committee must be informed before the meeting, not only in a presentation at the meeting.
All facts must come on the table, no hiding of information.
Ideally, the SC understands the change, is committee, and decides whether the change is enacted or not. This includes that
the project assumptions (framework) are re-evaluated, and this can lead also to the conclusion that the project is terminated.
We should have a systematic list of fundamental project assumptions---we have had this in some cases in a rudimentary
form, but this is something that we should probably make more systematic.
I analyze the situation before making changes to see what caused the need for delays or additional budgets. It is often
difficult to find why a problem occurred, or especially if some other action could have prevented it. I always ask for an
explanation of the situation, but there is no standard or quantifiable criteria to say how I do it.
You ask for an analysis of the consequences of these new developments: What do we need to do to handle this? What
decisions do we need to take? What are the necessary resources for this? It’s also a red yellow green assessment. If this is
a red flag, you want to talk in depth about the situation, the risks and the consequences.
It is important to find out WHY things went wrong, not necessarily to “find a throat to choke”.
When the change becomes apparent, I would ideally like to isolate it and give it (if it’s large enough) to a task force that deals
with it “separately”, “off line”. (…) The main challenge is to recognize and safeguard the bottom: When have we reached
the maximum size (or impact) of the problem that we can guarantee to contain (“I can rely upon it not getting worse than
this”)? There is nothing worse than repeated changes in the bad news and a realization that the fresh resources that we
brought to bear are insufficient.
The project team must make a solution proposal
We discuss together what we should do, and normally, the team has a proposal (for example, “the [production] volumes will
go up [versus the original assumptions], and therefore, we require a higher budget”).
The way this is done is that the team comes up with content proposals and the tradeoffs. In our case, we kept the delivered
functionality, but the demand side was delayed, and that was a decision [supported by the SC].
The good PM reports and presents solution alternatives, with their budget and schedule effects. THEN the SC can take a
decision, possibly after asking additional questions and perhaps demanding some additional analyses.
SC must make a clear decision.
In an extreme case (“We need to change the target market segment”), the defined context of the existing project is violated.
You cannot simply “muddle through” this situation. In this case, the SC might want to declare the project as terminated, and
then start a new project from scratch where the old one left off. The new project would have to start with a new business plan
and a new resource allocation. “Make a clear cut”.
17
Endnotes
i Mark Keil and Magnus Mähring, “Is Your Project Turning into a Black Hole?”, California Management
Review, 53(1), Fall 2010, 6-31.
ii Jeffrey K. Pinto, and Dennis P. Slevin, "Critical Factors in Successful Project Implementation," IEEE
Transactions on Engineering Management, 34:1, (1987): 22-27. Jeffrey K. Pinto, and Samuel J. Mantel, "The
Causes of Project Failure," IEEE Transactions on Engineering Management, 37:4 (1990): 269-276.
iii Lynn H. Crawford and Christine Brett, “Exploring the role of the project sponsor”, in: Proceedings of the PMI
New Zealand Annual Conference 2001, Wellington, New Zealand: 2001. Kosheek Sewchurran, and Michelle
Barron, “An Investigation Into Successfully Managing and Sustaining the Project SponsorProject Manager
Relationship Using Soft Systems Methodology”, Project Management Journal, 39, Supplement, (2008): S56
S68; Timothy J. Kloppenborg, Debbie Tesch, and Chris Manolis. “Investigation of the sponsor’s role in project
planning,” Management Research Review, 34:4 (2011): 400-416. Jane Helm, and Kaye Remington, “Effective
project sponsorship: The evaluation of the role of the executive sponsor in complex infrastructure projects by
senior project managers,” Project Management Journal, 36:3 (2005): 5161. Lynn H. Crawford, Terry Cooke-
Davies, Brian Hobbs, Les Labuschagne, Kaye Remington, Ping Chen, “Governance and Support in the
Sponsoring of Projects and Programs”, Project Management Journal, 39, Supplement, (2008): S43S55
iv Jeffrey K. Pinto and Dennis P. Slevin, “The Project Champion: Key to Implementation Success,” Project
Management Journal, 20:4 (1988): 15-20.
v Lynn H. Crawford et al., 2008, op. cit.
vi Suvi Elonen, and Karlos A. Artto, “Problems in managing internal development projects in multi-project
environments,” International Journal of Project Management, 21 (2003): 395402. John P. Kotter, “General
Managers are not Generalists.Organ. Dynamics 10:4 (1982): 5-19; Charles Perrow, Complex Organizations: a
Critical Essay. New York, NY: Random House (3rd ed.; 1986).
vii Terry J. Cooke-Davies, Lynn H. Crawford, Thomas G. Lechler, “Project Management Systems: Moving
Project Management from an Operational to a Strategic Discipline”, Project Management Journal, 40:1 (2009):
110-123. Traditionally, top management was implicitly assumed to have all the competences for effective
project supervision, with supervision seen as a question of the willingness to help with resources when
necessary, but this view is no longer tenable today (Jeffrey K. Pinto and Dennis P. Slevin, 1988, op. cit.).
viii Thomas G. Lechler, and Martin Cohen, “Exploring the Role of Steering Committees in Realizing Value from
Project Management,” Project Management Journal, 40:1 (2009): 4254; Matti A. Kaulio, “Project leadership
in multi-project settings: Findings from a critical incident study,” International Journal of Project Management,
26 (2008): 338347.
ix Suvi Elonen, and Karlos A. Artto, 2003, op. cit.; Paul L. Bowen, May-Yin D. Cheung, and Fiona H. Rohde,
“Enhancing IT governance practices: A model and case study of an organization’s effort,” International Journal
of Accounting Information Systems, 8 (2007): 191221. Thomas G. Lechler, and Martin Cohen (2009) op. cit. J.
Bradley, “Management based critical success factors in the implementation of Enterprise Resource Planning
systems,” International Journal of Accounting Information Systems, 9 (2008), pp. 175200; Matti A. Kaulio
(2008) op. cit. Vincent A. Mabert, Ashok Soni, and Munirpallam A. Venkataramanan, “Enterprise resource
planning: Managing the implementation process,” European Journal of Operational Research 146 (2003): 302
314.
x Paul L. Bowen et al., 2007, op. cit.; Timothy J. Kloppenborg, Debbie Tesch, and Chris Manolis. “Project
Success and Executive Sponsor Behaviors: Empirical Life Cycle Stage,” Project Management Journal, 45:1
(2014): 920; Toni M. Somers, and Klara G. Nelson, “A taxonomy of players and activities across the ERP
project life cycle,” Information & Management 41 (2004): 257278.
xi Toni M. Somers, and Klara G. Nelson, 2004, op. cit. Timothey J. Kloppenborg, Debbie Tesch, and Chris
Manolis, 2014, op. cit.
xii Toni M. Somers, and Klara G. Nelson. “The impact of strategy and integration mechanisms on enterprise
system value: Empirical evidence from manufacturing firms,” European J. of Operational Research, 146 (2003):
18
315338. Graeme Shanks, “A model of ERP project implementation,” Journal of Information Technology, 15/4
(2000): 289304. Paul L. Bowen, May-Yin D. Cheung, and Fiona H. Rohde (2007), op. cit. Yash P. Gupta, and
T.S. Raghunathan, “Impact of information systems (IS) steering committees on IS planning,” Decision Sciences,
20/4 (1989): 77793.
xiii Davide Aloini, Riccardo Dulmin, and Valeria Mininno, “Risk management in ERP project introduction:
Review of the literature,” Information & Management, 44 (2007): 547567; Matti A. Kaulio, 2008, op. cit.
xiv Sylvain Lenfle and Christoph H. Loch, “Lost Roots: How Project Management Came to Emphasize Control
over Flexibility and Novelty,” California Management Review 53(1), Winter 2010, 32-55.
xv Anselm Strauss and Juliet M. Corbin, Basics of Qualitative research: Grounded Theory Procedures and
Techniques, Newbury Park, CA: Sage Publications, 1990. While this book inspired our inductive approach, we
do not claim that we have employed a “complete” grounded theory toolbox in the study.
xvi Matthew B. Miles and Michael Huberman, Qualitative Data Analysis: A Sourcebook of New Methods (2nd
ed.)., Newbury Park, CA: Sage Publications, 1994.
xvii Robert K. Yin, Case Study Research: Design and Methods, Sage Publications, Thousand Oaks, CA. 2009.
xviii Kathleen M. Eisenhardt and L. Jill Bourgeois III, “Politics of decision making in high velocity
environments: Towards a midrange theory”, Academy of Management Journal, 31(4) (1988): 737-770.
... enefits include centralized accountability, role clarification, issue resolution, and transparent communication.Derakhshan et al. (2019) underscored the importance of inclusive stakeholder frameworks and the engagement of external stakeholders in governance decisions. They critiqued existing theories for overlooking external stakeholders' concerns.Loch et al. (2017) discussed senior executives' challenges in overseeing complex projects and stressed transparency, trust, and constructive decision-making for unforeseen circumstances and project adaptations.Too and Weaver (2014) highlighted project governance's role in value creation and proposed a framework to align project deliverables with organizat ...
... Derakhshan et al. (2019) proposed an inclusive stakeholder framework,Loch et al. (2017) addressed the challenges faced by project steering committees, and Too and Weaver (2014) introduced a comprehensive governance framework. These studies provide practical insights for enhancing project governance practices, ensuring transparency, alignment, and value creation.While these sources offer valuable insights, they also acknowledge certain limitations.Derakhshan et al. (2019) andToo and Weaver (2014) proposed conceptual frameworks that require further empirical validation, whileLoch et al. (2017) relied on a sole case study, potentially limiting generalizability. ...
... Derakhshan et al. (2019) proposed an inclusive stakeholder framework,Loch et al. (2017) addressed the challenges faced by project steering committees, and Too and Weaver (2014) introduced a comprehensive governance framework. These studies provide practical insights for enhancing project governance practices, ensuring transparency, alignment, and value creation.While these sources offer valuable insights, they also acknowledge certain limitations.Derakhshan et al. (2019) andToo and Weaver (2014) proposed conceptual frameworks that require further empirical validation, whileLoch et al. (2017) relied on a sole case study, potentially limiting generalizability. However, their strengths lie in their empirical analysis and practical recommendations, which contributed to understanding effective project governance.These studies underscored the necessity for stakeholder involvement, congruence with organizational strategies, and proficient decision-making within project governance frameworks. ...
Thesis
Full-text available
U.S. government agency projects are under intense scrutiny due to historical reporting of overspending and significant delays; however, only 13% of U.S. government information technology projects over $6M succeed, costing taxpayers money. Grounded in the theory of constraints, the purpose of this qualitative, pragmatic inquiry was to explore strategies that U.S. government executive stakeholders use to mitigate higher project costs and user adoption failure rates. The participants included three U.S. government agency executive stakeholders in Raleigh, North Carolina, the United States, who successfully implemented strategies to mitigate higher project costs and user adoption failure rates. Data were collected using semistructured interviews and publicly available North Carolina project management documentation. Four themes emerged through thematic analysis: (a) written documentation, (b) communication strategies, (c) project management tools, and (d) project team resources. A key recommendation is for U.S. government agencies to emphasize meticulous documentation throughout the project's lifecycle, encapsulating plans, requisites, resolutions, and gleaned insights. The implication for positive social change includes the potential to reduce project failure rates, improve the sustainability of information technology projects, and bring about significant societal benefits, such as creating more U.S. government jobs, making processes more efficient, and saving taxpayers money.
... Projects need oversight by senior management in order to be successful (Biesenthal & Wilden, 2014), often executed by a Steering Committee (Müller, 2009). The oversight can consist of both governance and support activities (Crawford et al., 2008;Loch, Mähring, & Sommer, 2017). The funding organization generally starts by appointing a project owner, who in turn appoints a project manager for the daily management of the project (Fama & Jensen, 1983). ...
... McGrath and Whitty (2018b) mix both usages, by referring to both the work of Nolan (1982), who used the term for ICT coordination groups, and Murphy (2016), who does explicitly focus on temporary committees for a project. The formation of temporary project steering committees is tailored to the goals and specifics of the project (Molen, 2015) and the members might have limited experience in supervising a project (Loch et al., 2017). Therefore, the empirical study discussed in this paper focused only on temporary PSCs that are dedicated to a single project or program. ...
... This paper will refer to a PSC as a body which can provide both governance and support, following Crawford et al. (2008). It will use oversight as the overarching term, in the meaning of "watchful and responsible care" (Merriam-Webster Incorporated, 2020a), which is in line with the use by Loch et al. (2017). ...
Article
Full-text available
Literature aimed at practitioners recommends dedicated Steering Committees for oversight of a project. However, most scientific research focusses on project governance in general or the role of the single owner. This paper adds to literature by inductively exploring the formation and the functioning of a Project Steering Committees, based on experiences of both members and project managers. Nine project managers and four Steering Committee members were interviewed. Data was analyzed, leading to five aggregate dimensions: on relevance and goals, the formation process, decision�making, roles and responsibilities of the members and ideal characteristics of the members. Findings were triangulated by a qualitative questionnaire. The study shows that dedicated Project Steering Committees are used for oversight of a project. As predicted by literature, the oversight consists of governance and support activities. The Steering Committee structure is primarily based on existing practices in the organization and the needed support from owners and other stakeholders. The project owner, often in consultation with the project manager, selects Steering Committee members based on functional representation. Competences needed for a role in the Steering Committee and interest in the project are generally taken for granted, but not always present. Follow-up research can focus on the roles and responsibilities of the members, characteristics the members should have, and the decision-making process.
... In this regard, prior research has found that senior IS managers are likely to approach the control of an IS project differently than project managers [35], for example, by being more prone to using an authoritative control style [2,76]. Senior managers' preference for this control style is at least partly due to power asymmetries (vis-à-vis IS project managers) and severe time constraints for control activities due to competing demands [51]. Still, earlier studies also tell us that an enabling control style has clear advantages over an authoritative control style in terms of project outcomes [2,65], which suggests a decision-related control dilemma for senior IS managers. ...
... We do so because novelty-induced project (task) uncertainty arguably 'forces' senior IS managers to take on a more active and/or directive role in IS projects. Among other things, this can be explained by project novelty increasing the risk of decision paralysis at the project-team level [54] and exacerbating accountability issues at the senior-manager level [51,61]. Against this backdrop, we draw on Rustagi et al. [68] and Sakka et al. [69] to define (novelty-induced) IS project uncertainty as the degree to which the 1 We acknowledge that senior IS managers' use of an authoritative control style does not preclude them from also drawing on some elements of an enabling control style, and vice versa. ...
... Corresponding studies highlight that senior IS managers fulfill an important directive role, which includes overseeing and controlling IS project activities in order to ensure IT-enabled value creation in alignment with business needs [25,35,49,52]. For instance, serving on the steering committee of an IS project, senior IS managers are tasked with articulating the project vision, defining the project scope, cost, and schedule, as well as with monitoring progress and exercising control over the IS project manager [e.g., 49,51,61]. ...
Article
Information systems (IS) projects are notoriously difficult to control, especially under conditions of uncertainty. This difficulty is particularly pronounced for senior IS managers, such as CIOs and IT Vice Presidents, who tend to have scarce time and limited project-related knowledge but are ultimately held accountable for IS project performance. Focusing on this under-researched controller category, the study at hand contributes new insights into the enactment of controls by exploring how IS project uncertainty affects senior IS managers' control-style choices, as well as how it moderates the impact of such choices on process and product performance. Based on a survey of 150 senior IS managers, we find that IS project uncertainty increases managers' use of an authoritative control style but is unrelated to their use of an enabling control style. Further, in IS projects characterized by uncertainty, an authoritative control style is found to be effective for process performance, whereas an enabling style is found to be effective for product performance. Moreover, the results of a post-hoc analysis show that using the two control styles simultaneously under uncertainty delivers no discernible benefits, suggesting a decision-related control dilemma. Theoretical and practical implications are discussed.
... Taken together, our article offers a bridge between research on information aggregation in political science and organizational design, elucidates the dual function of thresholds, and provides empirical evidence for the effect of thresholds on voting behavior. making among equals is particularly widespread in top management teams (Eisenhardt 1989, Hambrick et al. 1996, boards (Westphal andFredrickson 2001, Garg 2013), steering committees (Loch et al. 2017), investment committees (Csaszar 2012, Hu et al. 2022, and panels (Boudreau et al. 2016, Criscuolo et al. 2017. ...
... Such decision Piezunka and Schilke: Organizational Structures and Voting Behavior 2 Organization Science, Articles in Advance, pp. 1-24, © 2023 The Author(s) making among equals is particularly widespread in top management teams (Eisenhardt 1989, Hambrick et al. 1996, boards (Westphal andFredrickson 2001, Garg 2013), steering committees (Loch et al. 2017), investment committees (Csaszar 2012, Hu et al. 2022, and panels (Boudreau et al. 2016, Criscuolo et al. 2017. ...
Article
Full-text available
How do organizational structures influence organizational decision making? This article reveals organizational structures’ dual function: they both (1) aggregate and (2) shape individuals’ decisions. What makes this dual function so remarkable is that the two effects are diametrically opposed to one another. Ceteris paribus, a less stringent decision-making structure reduces the amount of support required for a given project to be greenlit at the organizational level, which should result in more investments getting approved. However, we find that this ceteris paribus assumption does not hold, because a less stringent decision-making structure also reduces individuals’ tendency to provide their support for an investment. Our experimental investigation of organizational voting provides evidence for our position that organizational structure plays an important role beyond mere aggregation: voting thresholds also affect individuals’ voting behavior. The combination of both effects explains why the organizational adoption of a new voting threshold may not yield the intended outcome. Funding: This work was supported by a National Science Foundation CAREER Award from the Directorate for Social, Behavioral and Economic Sciences [Grant 1943688] granted to O. Schilke. Supplemental Material: The online appendices are available at https://doi.org/10.1287/orsc.2023.1653 .
Article
Full-text available
Purpose The performance of large-scale projects is often challenged due to major environmental changes that occur during their life. However, literature has paid little attention to the governance adaptations required to respond effectively to these changes. This paper aims to study changes in the project environment over time, the corresponding governance adaptations and their impact on project performance. Design/methodology/approach To ensure triangulation between two sources of evidence, we used both primary and secondary data sources and examined 14 projects through 2 studies, the first focused on seven documented, illustrative case projects and the second on interviews with senior and project managers involved in seven additional projects. Findings We found the key environmental changes that should trigger appropriate governance adaptations to be market evolutions, technological advancements and sociopolitical events. However, we also found that these necessary governance adaptations are not commonly implemented timely, sufficiently or effectively. Originality/value The paper distills the dynamics of large-scale projects in achieving project effectiveness and raises theoretical propositions on the combination of environmental changes and deficient governance adaptations that, over time, turns efficient projects into ineffective projects and discusses implications for theory and practice.
Article
We present a typology in which commonly encountered project types and widely used project management process types are matched. This generates four propositions: (1) Process types match project types but do not cover all encountered project types; (2) a formal project management change process should be articulated; (3) the project management processes represent a portfolio that can help managers address project types (or other nonroutine challenges for the organization) in productive ways; and (4), while array and wicked projects cannot be fully addressed by any one of the project management processes, combinations of the processes may be able to deliver such projects.
Article
Full-text available
The article discusses understanding of the concept of project governance according to systematic literature review. Its objectives are to identify current research fields and to indicate new research directions. Project governance is the management construct poorly recognizable among practitioners. Results of systematic literature review highlight that: a universally acceptable definition of project governance or its methodological framework are being sought. The paper presents that three fields of studies related to project governance are recognized: correlation with project management, utilization of management theories, exploration of features constituting project governance (e.g.: leadership, trust, ethics, strategy, control, performance, contract). Comparing the obtained results with other similar studies, two additional research areas were identified: project governance as control-support system, governance of project procurement.
Article
Purpose The purpose of this paper is to explore how organizations manage and integrate exploration and exploitation across the innovation project portfolio. Such ambidextrous capabilities are required for organizations to innovate and succeed in today's rapidly changing competitive environment. Understanding how exploration and exploitation projects are integrated can illustrate ways to enhance ambidexterity and boost learning for the benefit of both approaches. Design/methodology/approach A multiple-case study approach was used to explore innovation portfolio management in six large organizations that emphasize innovation in their strategies. Findings The findings draw upon concepts of paradox and contingency to reveal that the inherent tension between formality and flexibility in managing innovation project portfolios is aligned with the need for organizational ambidexterity that maintains effective exploitative innovation while supporting explorative innovation capabilities. Four integration mechanisms are identified that enhance ambidexterity across the innovation portfolio by embedding processes for transition from exploration to exploitation and cross-fertilizing knowledge to build innovation capability across both exploration and exploitation. Practical implications Managers may find inspiration on ways to enhance learning by bridging exploration and exploitation projects from the four types of integration mechanisms. Recognizing the paradoxical nature of the tension between formality and flexibility in project and portfolio management may also help guide organizations to effectively develop ambidextrous approaches to enhance overall innovation outcomes. Originality/value In contrast to perspectives which suggest that paradox and contingency approaches represent disparate perspectives, the authors demonstrate how they can complement each other and work together through innovation portfolio management to support ambidexterity at the portfolio and project levels.
Conference Paper
The success of an IT implementation largely depends on the project management methodologies adopted which keeps a close track of the alignment of project tasks to the project objectives. However, due to emphasis on adoption of technology or the solution, the mode of implementation is given less priority which actually determines the success of the implementation. Project Management methodologies do not often receive the required importance in many IT implementations. This research explores the importance of Project Management methodology and the factors that affect the success of IT implementation from a project management perspective. A literature review was done to find out the major parameters affecting project management in IT implementation and the extent of its adoption is measured using a survey response among IT professionals in Kerala, India. An exploratory factor analysis was done to understand the common factors that affect the project management of IT projects from a Kerala perspective. The analysis helped to identify three factors namely, Project factors, Organisational factors and Risk factors which affect the adoption of project management in IT sector in Kerala. This study would provide practicing project managers in IT domain, the important aspects that should be considered and measured while implementing projects and thereby ensure project success.
Article
Full-text available
This paper describes a process used to determine critical success factors that are felt to be predictive of successful project management. Full time managers who have had experience with projects were used to generate critical success factors that they felt to be crucial to successful project implementation. Ten factors were discovered that relate well to previous theoretical formulations in the literature. In addition, these ten factors have been linked together in an interdependent quasi-sequential framework. This research has provided the basis for developing a behavioral instrument to be used as a diagnostic for assessing the status of any project as determined by the ten factor model.
Article
Full-text available
Any seasoned executive knows that information technology (IT) projects have a high failure rate. Large IT projects can become the business equivalent of what astrophysicists know as black holes, absorbing large quantities of matter and energy. Resources get sucked in, but little or nothing ever emerges. Of course, projects do not become black holes overnight. They get there one day at a time through a process known as escalating commitment to a failing course of action. Without executive intervention, these projects almost inevitably turn into black holes. This article sheds light on the insidious process through which projects that devour resources, yet fail to produce business value, are created and gradually evolve into black holes. It presents a framework that explains the creation of black hole projects as a sequence of three phases: drifting, treating symptoms, and rationalizing continuation. The framework is illustrated through two cases: EuroBank and California DMV. The article then presents recommendations to prevent escalating projects from becoming black holes and provides a means for detecting problems at an early stage.
Article
This study examines critical success factors for implementing Enterprise Resource Planning systems using the framework of classical management theory. The study is motivated by conflicting results in earlier studies examining critical success factors in Enterprise Resource Planning implementation, many of which are anecdotal in nature. Ten critical success factors in ERP systems implementation proposed in past literature are selected. The relationship between each of these factors and project success is examined. Project success is defined as organizational impact and on time and on/under budget project completion. Eight implementation projects were qualitatively analyzed using the case study method to examine the proposed relationships. The findings suggest that choosing the right full time project manager, training of personnel, and the presence of a champion relate to project success. The use of consultants, the role of management in reducing user resistance and the use of a steering committee to control the project do not appear to differentiate successful and unsuccessful projects. Integration of ERP planning with business planning, reporting level of the project manager, and active participation of the CEO beyond project approvals, resource allocation and occasional project review, are not found to be critical factors of success. Considering the financial cost and risk associated with these projects, a better understanding of critical success factors will enable practitioners and academics to improve the chance of success in the implementation projects. All organizations implementing ERP, especially small and mid-sized enterprises with limited resources, will benefit from this knowledge.
Article
The impact of steering committees on project performance and their role in creating value from project management capabilities is not well understood. A case study analysis was chosen to analyze the configurations and specific functions of project steering committees. A measurement model for steering committee configurations was developed to enable further survey-based studies. One of the major insights resulting from the authors' interviews with project managers and senior managers was that they perceived the existence of a project steering committee only when the context was defined and clarified. Furthermore, a large variety of committee involvements was identified, concluding that steering committees per se are very rare. On the project level, the cases clearly demonstrate that committees with project steering functions play an important role in the selection, initiation, definition, and control of projects. On the organizational level, they are important to implement and maintain project management standards. Finally, the results clearly indicate that steering committees directly support project success and are instrumental for attaining value from an organization's investments in its project management system.
Article
This paper “conceptualizes the fit” of enterprise resource planning systems in manufacturing firms by conducting a study to identify how well organizational strategies and integrating mechanisms fit management’s expectations of the system’s value. The empirical findings indicate that the extent of BPR, competitive strategy, adequacy of end-user training, role of steering committee, package functionality, integration of IT, and manufacturing decisions related to technology, workforce, quality, production planning and organization are important determinants of managements perceptions of system value.
Article
Over the past few years, thousands of companies around the world have implemented enterprise resource planning (ERP) systems. Implementing an ERP system is generally a formidable challenge, with a typical ERP implementation taking anywhere from one to five years. The story of the success of ERP systems in achieving the stated objectives is mixed. Some companies have had very successful implementations while others have struggled. This paper empirically investigates and identifies key differences in the approaches used by companies that managed their implementations on-time and/or on/under-budget versus the ones that did not using data collected through a survey of US manufacturing companies that have implemented ERP systems. Logistic regressions are used to classify on-time and on/under-budget firm groups based on the survey responses and to identify the significant variables that contribute to on-time and on/under-budget implementation performance. The results indicate that many different factors ranging from pre-implementation planning to system configuration influence performance, which managers should be sensitive about when implementing major systems like ERP.