Computers in Industry 47 (2002) 7788

Framework for managing business development in the

networked organisation
David O'Sullivan*
CIMRU, National University of Ireland, Galway, Ireland
Received 24 July 2000; accepted 29 June 2001

Abstract

Successful business practice is traditionally discussed in terms of the operational characteristics of business organisations.
How successful organisations operate and behave is of interest to all analysts. Increasingly, however, business success is
viewed through the process of managing development, where management decisions are informed by appropriate and timely
information. Managing development information such as customer requirements, business strategies, development projects
and idea generation is central to achieving business growth. This paper presents research aimed at developing an information
architecture and associated toolset for understanding and managing the process of business development. The research has
lead to the creation of a groupware application that marries a number of distinct areas of research including strategic planning,
performance measurement, enterprise modelling, project portfolio management and team management. The groupware helps
communicate all the core development information necessary for informed decision-making and brings all the people
responsible for development in the organisation closer together. # 2002 Elsevier Science B.V. All rights reserved.

Keywords: Business development; Networked organisations; Teams; Development funnel; Internet teams

1. Introduction companies, it should not be. We already know many of

Industry we are told manages development poorly.
Surveys indicate that most development programmes
fail to meet their objectives. The reasons cited seem
familiar: poor goal denition, poor alignment of
actions to goals, and poor participation among
employees. Innovation we observe is also managed
poorly. In many companies, the knowledge of most
employees remains untapped for solving problems and
generating new ideas. Harnessing and utilising this
knowledge is central to improving development. And
while this seems a formidable challenge for many
*
Tel.: 353-91-750-400; fax: 353-91-562-894.
E-mail address: dos@nuigalway.ie (D. O'Sullivan).
the skills we need. What seems lacking is a concise
roadmap for the process of development within orga-
nisations and more importantly how elements within
this process interact.
A survey of Fortune 500 companies found that over
60% of change programmes fail to meet their goals
[1]. Some analysts argue that this could be as high as
80% [2]. Most change programmes consist of identi-
ed actions or projects in specic areas of the business
environment and these individual projects are also
failing. Hammer and Staunton [3] highlight that
between 50 and 70% of all projects fail to achieve
their goals. Other research also supports these rates of
failure for development projects in organisations:
Jaikumar [4] discusses 5075% failure rates among
projects; Field [5] quotes failure rates of 73% among

0166-3615/02/$ see front matter # 2002 Elsevier Science B.V. All rights reserved.
PII: S 0 1 6 6 - 3 6 1 5 ( 0 1 ) 0 0 1 3 5 - X
78 D. O'Sullivan / Computers in Industry 47 (2002) 7788
IT projects; and Burnes [6] cites research that shows
70% of technology projects fail, and 80% of TQM
initiatives fail. It has to be stressed that the denition
for a failed project among the above references ranges
from abandoned projects to projects that simply do not
meet their full goal potential or simply have schedule
overrun problems. Regardless of the reason for failure
the cost for business in terms of inefciency and lost
potential is signicant. What is perhaps more signi-
cant in the long-term is cynicism and loss of morale
among employees, leading to either an acceptance of
low success rates, denial of failure and poor follow-up
on any lessons that can be learned to make future
projects more successful.
The causes for failure are varied. However, the
following have been distilled from a number of
sources [711] and backed up by a survey of inter-
national companies [12]:
1. poor goal denition;
2. poor alignment of goals to projects;
3. poor participation among employees;
4. poor idea generation and problem solving;
5. poor mapping of change to key processes;
6. poor reporting of results; and
7. poor management of projects.
An analysis of these causes highlights one telling
observation they have little to do with the absence
of `good operations practice'. All of the above causes
are developmental rather than operational in nature.
One is tempted to conclude that identifying best
operations practice merely gives a company a 60%
chance of failure because that is approximately the
proportion of its efforts that will fail. On the other
hand, identifying good development practice gives an
organisation its best chance of success.
2. Development approaches
These seven causes of failure hint at a number of
existing approaches for fostering a better approach to
development. In the past, various paradigms have
emerged that offer effective tools and techniques
for better implementation of change. In the discus-
sion that follows a number of core approaches are
presented in terms of their impact on reducing causes
of failure.
2.1. Goal denition
Zairi [13] cites lack of goal clarity as a common
cause of inhibiting successful change projects. Busi-
ness goals are dynamic and change in response to an
ever changing business environment. Two major areas
have evolved for facilitating goal denition in orga-
nisations strategic planning and performance mea-
surement. Various authors have discussed the
importance of strategic planning at length over the
years. Hayes et al. [7] and Porter [14] have offered
widely accepted approaches to managing strategy
within business organisations that include: business
requirements analysis; identifying strategic thrusts;
developing individual strategies and objectives; and
monitoring progress. More recent perspectives by
Tidd et al. [11] and Ettlie [15] emphasise the need
for organisations to identify `market pull' as opposed
to `technology push' strategies. Making a clear dis-
tinction between `requirements' and strategies can
help to keep `market pull' issues such as customer
requirements in focus. Performance measurement as a
goal denition exercise is a complementary approach
to strategic planning and is seen by one source as ``a
primary strategy deployment tool'' [10]. Key charac-
teristics of the performance measurement approach
include the identication of measures or indicators,
setting rm and stretch targets of performance and
nally monitoring and communicating performance
regularly.
2.2. Alignment of goals to projects
In one report, Price [10] suggest that the importance
of correlating goals with projects since ``many man-
agers are faced with an undisciplined collection of
change projects that make little sense and do not reveal
any pattern or integration of objectives''. Berger et al.
[16] identify the importance of ``alignment of actions
. . . to organisational objectives''. A number of tech-
niques facilitate this alignment including quality func-
tional deployment and management matrices. A key
ingredient for proper alignment is a consensus
approach among managers towards deployment as
discussed by Kotter [9] and a contingency manage-
ment style where alignments change as the business
environment changes [17]. Quality function deploy-
ment (QFD) is widely accepted as a useful alignment
 D. O'Sullivan / Computers in Industry 47 (2002) 7788
tool. The application of QFD varies signicantly from
simple matrices to full blow house of quality style
diagrams [18]. In the approach presented in this paper,
the simplicity of matrices supports greater manage-
ment involvement in developing consensus-based
decisions that respond to changing environmental
demands.
2.3. Participation among employees
Resistance to change from employees has been
cited frequently as a primary cause of project failure.
Resistance to change takes on many forms and exists
is various overt and covert forms throughout the
organisation [19]. Most researchers agree that the
most potent defence against resistance to change is
greater participation among employees [20]. Current
approaches to knowledge management stress the
importance of greater employee participation in gen-
erating ideas and sharing information. Teamwork,
where employees can engage in permanent or non-
permanent activities can harness tacit knowledge and
also lower resistance. Another area important in
increasing participation is the alignment of employ-
ees' personal goals with the goals of the organisation
[21]. In organisations, where boundaries are increas-
ing within and across unique organisations, the con-
cept of virtual teams is proving essential for engaging
employees in organisational development [22].
2.4. Idea generation and problem solving
Idea generation and problem solving is seen by
many analysts as the seeds of innovation. Kanter
denes innovation as the ``the process of bringing
any new problem solving idea into use'' [20]. Innova-
tion within organisations is a critical success factor in
populating development plans. Harnessing the tacit
knowledge of employees unleashes new potential and
distributes the load of idea generation and team parti-
cipation. In the past emphasis has been on reactive and
proactive problem solving. As organisations mature
the issue of stimulating creative thought and generat-
ing new ideas becomes possible. Cumming [23] pre-
sents a number of factors useful in stimulating the
creativity process and ultimately generating ideas for
change. Problem solving and idea generation cannot
exist outside the context of satisfying development
79
goals. Alignment of goals to ideas and problems can
be achieved using matrices or simply indicating which
goals are affected by a particular idea.
2.5. Mapping of change to key processes
A signicant body of knowledge has been devel-
oped within the discipline of enterprise modelling and
business architectures. In general, the results of this
work provides insights into how organisations cur-
rently operate and may operate in the future. The CIM-
OSA framework, e.g. divides the organisation into
four domains: processes; information; physical equip-
ment; and organisation [19]. Process modelling is
viewed as an important way to avoid the problems
posed by functional departmentation and reects bet-
ter the ow of information and decisions within an
organisation. The emergence of `business process
reengineering' lead by such writers as Hammer and
Champy [24] and Davenport [25] provided much
emphasis on the need to view an organisation through
its processes. The IDEFo methodology is perhaps the
most effective tool in helping managers model and
understand business processes [19]. Linking activities
in an IDEFo model to projects is a simple process of
deployment discussed earlier. It provides information
on what processes are currently being affected by
projects. Deployment also provides a vehicle for
managers to encourage more ideas and projects in
processes deemed critical for future development.
2.6. Reporting of results
One of the most elusive aspects of managing devel-
opment has been the monitoring and the reporting of
results. In recent years, Kaplan and Norton's `balanced
scorecard' approach has done much to improve this
issue [26]. The time lag between a change and the
results of the change can often be measured in years
and sometimes beyond most people's memory of a
specic change initiative. We have found through our
own surveys that monitoring results is a learning
process for teams and managers rather than a denitive
statement of performance. In this regard, it needs to
take place around four core areas performance
measurement, project implementation, strategy adop-
tion and employee appraisal. Performance measure-
ment is clearly quantitative whereas strategy adoption
80 D. O'Sullivan / Computers in Industry 47 (2002) 7788
is qualitative. Qualitative reporting requires honest
judgement and reporting by managers and in this
respect the trafc lights metaphor, where results are
either red, green, or amber is simple, yet effective. In
the context of honest judgement a learning approach
within the organisation is clearly important where
managers and employees are allowed to make mis-
takes so long as they are openly discussed so every-
body can learn how to avoid them in the future. Pond
[27] calls this ``organisational learning through trau-
mas and triumphs''.
2.7. Management of projects
Effective project management has long been iden-
tied as a key activity for successful development
[28]. A considerable body of knowledge has been
written on successful project management. The Pro-
ject Management Institute's `Project Management
Body of Knowledge' has become an important fra-
mework for improving project management within
organisations [29]. In the context of development
within business organisations an interesting topic
to emerge is `project portfolio management'. In port-
folio management, the emphasis is on managing a
dynamically changing portfolio of projects rather
than on one project alone [30]. Project portfolio
management identies that organisations change
as a result of many projects being implemented
together. As business goals change, so too does the
portfolio some projects are dropped, others are
introduced and all compete for better priority. Key
issues in portfolio management include effective
project ranking, resource allocation and nancial
planning. There are also a large number of nancial
and non-nancial techniques used in ranking and
selection of projects [31]. Archer and Ghasemzadeh
[32] provides a useful perspective on project ranking
with respect to project portfolio selection. Cooper
[33] identies a number of performance goals for
effective project portfolio management including
populating the portfolio with goal centred projects,
avoiding gridlock through the effective use of rank-
ing and resource allocation, and having balance in the
portfolio between long-term versus short-term pro-
jects; high risk versus low risk projects; and across
various abstractions from technology to organisation,
information to process.
This paper presents the results of research under-
taken to develop a framework for understanding deve-
lopment in organisations that specically addresses
the above causes of failure and more. The study has
identied seven core processes for the management
of business development and adopts the labels: (i)
customers, (ii) goals, (iii) innovations, (iv) projects,
(v) teams, (vi) models and (vii) results. Each process
demands tools and techniques necessary to manage
development information. Once deployed they harvest
development knowledge in a way that fosters greater
employee involvement and more goal centred change.
3. Development framework
The development funnel is a powerful metaphor for
explaining how the development process works in
organisations and in particular how various elements
of the development process interact with each other.
The rst use of the funnel came to our notice through
work by Hayes et al. [7]. Levene and Gofn [34] and
many others have also used the funnel metaphor to
explain business development. We have adapted these
early approaches, to create our own funnel for identi-
fying and positioning the seven core development
processes (see Fig. 1). The funnel itself represents
the `development process'. Using the IDEFo process
modelling methodology [19], we give the funnel the
activity title: `manage development'. Following the
IDEFo methodology, we can identify four main ows
around the funnel. The funnel has `inputs' which are
Fig. 1. Development funnel.
 D. O'Sullivan / Computers in Industry 47 (2002) 7788
transformed by the development process into `out-
puts'. The transformation takes place under the con-
straints of `controls' and `resources'. A label missing
from this diagram is `deployment' which represents
the best match between inputs, controls, resources and
resulting output.
Innovations are the primary input to the develop-
ment process. Innovations (e.g. ideas and problems)
that map well with the controls and resources of the
organisation, ow more easily into the funnel to
become outputs (e.g. projects). Organisations can
regulate the number of innovations by tightening or
loosening the controls and resources at the neck of the
funnel. Poor goal denition results in broadening the
neck of the funnel allowing the development process
to become cluttered. Poor resource availability, budget
availability and process modelling lowers the amount
of new ideas that can be managed. The principle
concept is that new ideas and problems are encouraged
into the mouth of the funnel and the four main con-
straints regulate which innovations are allowed
through to become goal centred projects. If innova-
tions are initially matched with goals then their like-
lihood of proceeding through the funnel increase.
Goals are articulated through ve separate, but inter-
related processes: statements, requirements, strate-
gies, standards and measures. If innovations do not
map easily onto strategies or measures, e.g. then they
may be aborted. On the other hand, if they do map with
goals then they can be eventually processed as a key
change initiative (e.g. a project). The process of ow is
at all times regulated by the user(s) who take decisions
at various stages about what ows into the funnel, and
what constraints act to regulate ow.
The other constraints on the neck of the funnel are
`models' and `teams'. Teams represent the resource
constraints of the organisation. Clearly, the more
people available for `projects' the weaker this con-
straint. But interestingly there is another dimension to
this constraint employee performance reviews.
Employees that are linked to goals through their
performance appraisal system are motivated to engage
in goal centred projects and clearly this element of the
development process must also be incorporated to
increase the ow of innovations. The nal resource
`models' is perhaps best described as a mapping
constraint. Using the models of the enterprise, only
those innovations within predened critical processes
81
or functions may be adopted or given higher priority
than other innovations. The models work in concert
with the strategies to lter innovations that create
required change within certain areas of the enterprise.
Not all innovations need proceed into the funnel.
Some that do not require signicant resources can
be adopted by the organisation as incremental
improvements or quick wins.
The projects process represents the minimum cri-
tical specications for each of the projects that ow
through the funnel. Part of the specication includes
routines for ranking projects. Although projects may
have comfortably steered their way through the four
main constraints, they may still fall foul of budgetary
constraints by simple virtue of being ranked lower
than more deserving projects. Part of this ranking
procedure must include criteria such as `level of risk',
`impact on strategies', `impact on measures of per-
formance', `resistance to change' and `probability of
success'. The nal process indicated on the funnel
process is labelled `results'. Results represent the
actual performance of the organisation in terms of
its measures of performance, but also in terms of
progress of strategy implementation and of progress
of project implementation. Projects are typically mea-
sured in terms of time schedules and budgets, mea-
sures in terms of trends. Both of these are easily
quantiable. Strategies on the other hand are more
qualitative, and thus, rely on managers and leaders
giving a structured report on progress and an indica-
tion of implementation status (e.g. red, amber, green)
and percentage complete. All three provide a snap shot
of the `results' of the development process. In the case
of performance measures there is clearly a time lag
between a project's implementation and its effects on
performance. Managers need to use their experience
and the data available to judge whether a particular
project actually contributes towards performance
improvement.
3.1. Development variables
There are a number of variables around the innova-
tion funnel that can be manipulated by the develop-
ment team:
1. The number and quality of innovations depends
to a large extent on employee involvement,
82 D. O'Sullivan / Computers in Industry 47 (2002) 7788
mechanisms for reporting innovations and the
clear communication of business goals.
2. The way goals are deployed into innovations as
they ow through the funnel is a critical variable.
Tightly dened measures of performance and
unambiguous strategies mean innovations can be
more easily ltered according to their potential
impact on business growth.
3. The effectiveness of teams depends on many
factors, but one important factor is how each team
member is linked to the goals of the organisation
through their own performance appraisal system.
If management want more goal centred innovation
then employee reward must be linked to business
goals.
4. Customer requirements will vary from time to
time and these variations must be communicated
to innovators and project managers as soon as they
occur. This can be achieved by implanting live
customer requirements within the tools used to
manage ideas, problems and projects.
An important aspect in distilling the core traits
necessary for successful management of the develop-
ment process is the identication of best practice
criteria. These criteria are identied following through
a combination of theoretical research; interviews with
development managers and experience gained from
other research projects. The criteria are presented in
Table 1 as a self-assessment questionnaire for devel-
opment teams. A full denition of the terms is outside
the scope of this discussion, but many terms are
implicitly dened elsewhere in this paper. The impli-
cation of the self-assessment is simple; scoring high
on most criteria gives an organisation its best chance
of success in implementing a development programme
successfully.
4. Software design criteria
Seven software design goals were created to guide
software development of a groupware tool to support
the development processes described above. These
goals were selected to guide designers into incorporat-
ing many of the ideas discussed above into the soft-
ware. The design goals selected for software deve-
lopment were grouped into the following headings: (i)
goal driven; (ii) action centred; (iii) networked orga-
nisation; (iv) deployment mapping; (v) innovation; (vi)
critical knowledge; and (vii) results oriented.
4.1. Goal driven
All development activities need to be goal driven,
and this concept permeates every element of change.
Surprisingly, many organisations seem incapable of
deploying this absolute into their development activ-
ities. Part of the problem is poor goal denition as
discussed earlier, but part must also be attributable to
poor design of planning tools. Our research discovered
two broad categories of software available for the
development process: tools for managing goals; and
tools for managing projects. Project management tools
including those most popularly deployed in organisa-
tions do not include modules for dening and deploy-
ing goals. On the other hand, tools for managing goals
(performance measures, strategic plans, etc.) do not
expand to include the issue of project management or
more specically project portfolio management. In the
context of managing development this software design
goal is critical. This software design criterion suggests
a tool for facilitating better goal denition and deploy-
ment of goals into projects. In the context of `goals' as
dened in the previous section the main elements that
need to be deployed are `strategies' and `measures'.
Another important element of this criterion is that
goals need to be clearly dened and communicated to
all employees, since all employees may potentially be
involved in all aspects of change.
4.2. Action centred
This design goal emphasises the need to visualise
change and development through actions such as
ideas, problems and projects rather than through
behaviour or best practice traits. Many researchers,
e.g. adopt a modelling approach that attempts to view
the `factory of the future'. While the results of this
research have their value, they provide specic com-
panies with little more than insights into how they may
or may not behave in the future. Rather than dening
the factory of the future in terms of how it operates,
it becomes necessary to dene it in terms of how it
will change, i.e. its actions. A portfolio of projects
or ideas can be far more effective in presenting the
 D. O'Sullivan / Computers in Industry 47 (2002) 7788 83

Table 1
Self-assessment Criteriaa

Customers (C)
Complaints from customers are recorded and easily accessible
Warranty claims are accessible and easily deployed
Requirements of customers are documented
Expectations of customers future needs are documented
Goals (G)
Statements of core business values are defined and communicated
Stakeholder requirements are concisely defined and easily assessable
Strategies are easily assessable and concisely defined
Measures of performance are defined and easily accessible
Benchmarking is actively supported and results communicated
Teams (T)
Individual staff members participate in idea generation and problem solving
Teams, both permanent and non-permanent are defined and supported
Information on activities of staff is easily accessible
Review process links staff performance to company goals
Review process allows employees to engage in developing company policy
Models (M)
Models of company structures and hierarchies are easily accessible
Models are used to position actions (projects and innovations)
Process and information models of core business activities are available
Innovations (I)
Idea and problem proposal generation is facilitated
Critical information on all ideas and problems is easily accessible
Ideas and problem solving is managed effectively
Relationships are drawn between innovations and goals of the company
Stage gate process ensures appropriate management of ideas
Decisions on ideas can be monitored easily by initiator
Information on staff participation in innovations is easily accessible
Projects (P)
Project proposals are facilitated and managed effectively
Critical information on projects is easily accessible
Project portfolio is managed effectively
Relationships are drawn between projects and goals of the company
Ranking is appropriately utilised on projects
Resources (people) of projects are managed effectively
Information on staff participation in projects is easily accessible
Results (R)
Measures are tracked and easily accessible by defined time period (scorecard)
Trends of all critical measures are easily accessible
Review of all project progress is appropriately managed
Progress towards completion of strategies is accessible
a
Score your organisations performance using the following criteria: strongly disagree, 1; disagree, 2; neutral, 3; agree, 4; strongly agree, 5.

factory of the future than an enterprise model. This
goal demands a tool centred on actions creations,
problems, ideas, investigations and projects, and a
tool that adopts an enterprise modelling approach
that identies where change needs to occur, rather
than how companies should operate in the future.
Other design features within this label include various
project portfolio techniques discussed earlier such as
project ranking and resource allocation.
4.3. Networked organisation
This label is used loosely and here represents the
need for the software to facilitate the behaviour of a
84 D. O'Sullivan / Computers in Industry 47 (2002) 7788
networked organisation and communication among
virtual teams. Specically, the goal demands that
the software supports a collaborative workgroup envir-
onment that crosses functional and geographical
boundaries. Also incorporated is the need to cross-
technological boundaries where members of the same
project team can use dissimilar computer platforms
and mobile technologies. The implication is client-
server technology and browser based applications.
Various collaborative roles need to be identied for
the software from `initiators' who submit ideas and
`authors' such as project managers who manage indi-
vidual projects.
4.4. Deployment mapping
This design goal demands that all actions (innova-
tions and projects) must have linkage to the goals of
the organisation. It also demands that enterprise mod-
els be linked to both the goals of the organisation
and all innovations and projects. This can be achie-
ved in a number of ways and it was decided early in
development that deployment must not interfere with
Fig. 2. Deployment mapping.
the knowledge of users, as they use the tool. The
traditional tendency by software specialists to `hard
wire' relationships between entities was to avoided in
place of `soft wiring' where users could change goals
easily, but not necessarily affect deployments that
have already taken place with older goals. The deploy-
ment design goal is illustrated in Fig. 2. Here the
reader can see a schematic representation of how the
main forms used in the software system can build
relationships with each other. The projects form, e.g.
(presented later) has an area for deploying goals,
models and teams into its activities.
4.5. Innovation
Engaging employees in the innovation process has
clear advantages for the employee and the growth of
the company. This goal demanded that the front of the
development funnel be properly codied to facilitate
the innovation process. A browser-based architecture
means that any user can access the ideas module from
anywhere in the company intranet. A state gate pro-
cess is key to achieving the correct management
 D. O'Sullivan / Computers in Industry 47 (2002) 7788
of this process. Clearly, all ideas will not be appro-
priate for an organisation, and while the deployment
design goal will attempt to make sure ideas are goal
centred, some ideas will require actions such as `inves-
tigation' by more experienced analysts. In effect the
modules at the front of the funnel must be developed
to incorporate appropriate capturing of large quanti-
ties of data and its subsequent ltering, sorting and
selection.
4.6. Critical knowledge
A key principle here is the need for `minimum
critical codication' of development information. This
means that all elds designed into forms must facil-
itate rather than burden the knowledge worker. The
task of dening what is critical versus what is unim-
portant can be greatly facilitated by `test site' com-
panies. Sufce it to say that end users have a vested
interest in reminding researchers of this design goal.
Most researchers left to their own devices within the
four walls of the research centre will tend to over
specify solutions.
4.7. Result oriented
The nal design goal requires that key goals and
actions be monitored and reported to employees in the
same environment where they were adding ideas,
managing projects and appraising employee perfor-
mance. The design goal demands that critical infor-
mation regarding the results of performance measures,
strategies and project implementation is easily acces-
sible and that exceptional performance (good and bad)
is easily separated and identied by the user. Indeed, a
common theme running throughout these design goals
is instant access to information for knowledge workers
using the groupware system.
5. Software architecture
The prototype software system developed through
this research was implemented using a forms-based
development platform and objects were selected to
meet the process requirements of the development
funnel described earlier. In this respect, nine `control'
related forms were designed for codication. Nine
85
Fig. 3. Software forms.
`resource' related forms were developed. Five forms
were specied for `inputs'. Each form included elds
for stage gating (e.g. management approval elds) as
ideas and projects owed naturally from one stage the
next. The `ideas' module for example includes forms
for dening creations, problems and ideas. One form
was designed for `project' and three for the various
aspects of reporting `results'. Each of the main clusters
of forms is presented in Fig. 3 for illustration.
5.1. Project form
Part of the project form is illustrated in Fig. 4 for
further illustration. It contains a number of data elds
that represent critical knowledge about a project for
the user. Typical information regarding schedules,
timesheets and cost-benet is supplemented with
elds that allow the user to map the project to stra-
tegies, measures, process models and so on. The user
can also map the project to various project classica-
tions presented earlier in the paper and used for sorting
and ltering large project portfolios. Illustrated in this
gure is the design goal that demands that when
developing a project the user is constantly reminded
of the goals of the organisation this clearly
improves the users understanding of these goals and
ultimately empowers the user to contribute towards
these goals. Many elds have been hidden in sections
in this gure, and they include techniques for ranking
the project, conducting cost-benet analysis and
developing individual Gantt charts.
86 D. O'Sullivan / Computers in Industry 47 (2002) 7788
Fig. 4. Sample `project' form.
6. Conclusions
The software and underlying theory presented in
this paper has been validated in over 30 companies.
Validation of the theoretical aspects of the research
was facilitated through the use of self-assessment
surveys that helped companies to identify the best
practice traits for development management and in
particular where their strengths and weaknesses may
lie. The criteria and results of some of these surveys
are published in related publications [12]. The soft-
ware validation mainly involved ne tuning core
software functionality through a process of reduc-
tion. Each of the core software functions were
populated and tested thoroughly, with each test con-
tinually reducing functionality to an absolute mini-
mum. Another result of the validation process was
the modularisation of core functionality, allowing
client companies select only those modules where
they need software assistance. A groupware appli-
cation has now been created that `operationalises'
key aspects of development management. With hind-
sight few new management concepts have been pro-
vided by this research. Rather, existing concepts from
a wide variety of research domains have been brought
together. Concepts such as strategic planning,
innovation management and enterprise modelling
have found a common implementation framework.
Tools such as quality function deployment, mind
mapping and project ranking interact with others to
provide an integrated suite of tools for development
teams. It is perhaps useful to revisit the causes of
failure identied at the beginning of this paper and
argue why this approach has moved someway
towards improving the efciency of the development
process:
 Poor goal definition: The approach facilitates the
development, management and communication of
goals to all members of a development team.
 Poor alignment of goals to projects: The approach
deploys goals into innovations and projects. Inno-
vations and projects are easily traceable to goals.
 Poor participation among employees: The approach
supports group activity within organisations. In
addition, all individuals are linked to the goals of
the development process through an in-built per-
formance appraisal system.
 Poor idea generation and problem solving: The
groupware provides modules for stimulating idea
creation, managing ideas, and managing problems.
 Poor mapping of change to key processes: The
groupware provides enterprise-modelling tools for
common modelling abstractions including pro-
ducts, processes, functions, organisation and infor-
mation. These models are used to map projects onto
key areas of change within the organisation, and in
particular, business processes.
 D. O'Sullivan / Computers in Industry 47 (2002) 7788
 Poor reporting of results: The approach supports
focused and concise reporting of `results' for all
goals and actions. The results area of the methodol-
ogy deploys effective management techniques such
as the `traffic lights' metaphor and control charts
that allow results to float within predefined limits
before they attract attention.
 Poor management of projects: The approach pro-
vides a project portfolio management tool incorpor-
ating light versions of standard project management
techniques, such as project scheduling, ranking,
loading and budgeting. Management of individual
projects through common project management soft-
ware platforms can be linked into the portfolio.
Not unlike most research activities our work is
perhaps never complete. Future work now includes
broadening the scope of the application domain to
incorporate collaborative development across the
extended enterprise testing out how suppliers, dis-
tributors and customers can also become part of devel-
opment in the networked organisation. Other aspects
of future development include resource deployment
based on skill requirements at various stages of project
portfolio development and enhancing the groupware
aspects of the approach by building in tools that
enhance `community' such as games and learning tools.
Acknowledgements
The author would like to kindly acknowledge the
contributions of the following researchers who
assisted in this research over the last 5 years: Mark
Davis, Siobhan Wreath, Yu Ming, Kathryn Cormican
at CIMRU, National University of Ireland, Galway
and Lawrence Dooley at the University of Dundee.
The author also acknowledges the following for their
support: Enterprise Ireland, Thermo King, Nortel Net-
works, and Mike Lang.
References
[1] P. Strebel, Why do employees resist change, Harvard
Business Review on Change, Harvard Business School Press,
Boston, 1999, pp. 139157.
[2] R. Rothwell, Successful industrial innovation, R&D Manage-
ment 22 (1992) 221239.
87
[3] M. Hammer, S.A. Staunton, The Reengineering Revolution
The Handbook, HarperCollins, London, 1995.
[4] R. Jaikumar, Post-industrial manufacturing, Harvard Business
Review 37 (1986) 7986.
[5] T. Field, When bad things happen to good projects, CIO
Magazine, 1997 (Oct.) 19.
[6] B. Burnes, Managing Change: A Strategic Approach to
Organisational Dynamics, Pitman, London, 1996.
[7] R. Hayes, S.C. Wheelright, K. Clarke, Dynamic Manufactur-
ing Creating the Learning Organisation, Free Press, New
York, 1988.
[8] T.H. Davenport, Process Innovation Reengineering Work
Through Information Technology, Harvard Business School
Press, Boston, 1993.
[9] J.P. Kotter, A Force for Change: How Leadership Differs from
Management, Free Press, New York, 1990.
[10] W. Price, The Paradox Principles, Irwin, Chicago, 1996.
[11] J. Tidd, J. Bessant, K. Pavitt, Managing Innovation
Integrated Technological, Market and Organisational Change,
Wiley, Chichester, 1997.
[12] L. Dooley, D. O'Sullivan, Supporting systems innovation,
International Journal of Innovation Management 4 (2000) 124.
[13] M. Zairi, Best Practice Systems Innovation Management,
Butterworths, New York, 1999.
[14] M. Porter, Competitive Strategy, Free Press, New York, 1980.
[15] J.E. Ettlie, Managing Technological Innovation, Wiley, New
York, 2000.
[16] L.A. Berger, M. Sikora, D.R. Berger, The Change Manage-
ment Handbook, Irwin, New York, 1995.
[17] H.W. Dettmer, Breaking the Constraints to World Class
Performance, ASQ Publishing, Milwaukee, 1998.
[18] P. Bradley, CIMRU 156, National University of Ireland,
Galway, 1996.
[19] D. O'Sullivan, Manufacturing Systems Redesign, Prentice-
Hall, Englewood Cliffs, NJ, 1995.
[20] R.M. Kanter, The Change Masters, Simon and Schuster, New
York, 1983.
[21] E.E. Lawler, High Involvement Management: Participative
Strategies for Improving Organisational Performance, Jossey-
Bass, San Francisco, CA, 1986.
[22] R.M. Kanter, World Class: Thriving Locally in the Global
Economy, Touchstone Books, New York, 1997.
[23] B. Cumming, in: M. Zairi (Ed.), Best Practice: Process
Innovation Management, Butterworths, Oxford, 1999.
[24] M. Hammer, J. Champy, Reengineering the Corporation A
Manifesto for Business Revolution, Nicholas Brealey, Lon-
don, 1993.
[25] T.H. Davenport, Process Innovation: Reengineering Work
Through Information Technology, Harvard Business School
Press, Boston, 1993.
[26] S. Kaplan, D. Norton, Using the balanced scorecard as a
strategic management system, Harvard Business Review, Jan
Feb (1996) 7585.
[27] L.R. Pond, in: L.O. Montgomery (Ed.), Transition to Agile
Manufacturing, ASQC Quality Press, Milwaukee, 1996.
[28] A. Rolstadas, Management by projects, International Journal
of Production Planning and Control 10 (1999) 12.
88 D. O'Sullivan / Computers in Industry 47 (2002) 7788
[29] W. Duncan, A Guide to the Project Management Body of
Knowledge, Project Management Institute, North Carolina,
1996.
[30] T.C. Spradlin, D.M. Kutoloski, Action-oriented portfolio
management, Research Technology Management 42 (1999)
2632.
[31] J.R. Meredith, S.J. Mantel, Project Management A
Managerial Approach, Wiley, New York, 1995.
[32] N.P. Archer, F. Ghasemzadeh, An integrated framework for
project portfolio selection, International Journal of Project
Management 17 (1999) 207216.
[33] R.G. Cooper, From experience: the invisible success factors
in product innovation, Journal of Product Innovation Manage-
ment 16 (1999) 115133.
[34] R.J. Levene, K.R.H. Gofn, in: Proceedings of the 28th
Annual Symposium at Project Management Institute, Chica-
go, IL, 1997.
David O'Sullivan is lecturer at the
National University of Ireland, Galway
and director of CIMRU, a research orga-
nisation in the eld of innovative solu-
tions for the digital enterprise. David's
personal research interests are in innova-
tion management where he directs a
number industry sponsored research pro-
jects in areas such as product innovation
management, systems innovation man-
agement, virtual development teams and development management.
He has over 50 publications including a book entitled `Manufactur-
ing Systems Redesign' and contributions to various other books
including: `Reengineering the Enterprise' and `Handbook of IS
Management'. In 1995, David was honoured with the prestigious
`Outstanding Young Manufacturing Engineer of the Year' by the
Society of Manufacturing Engineers, Dearborn, Michigan.