BB

Project Management for Information Systems
by James Cadle and Donald Yeates

End of chapter Questions and ns!ers
Chapter " Managing change
Q1 Figure 1.7 shows how bad an implementation can become. Action needs to be taken to
prevent this kind of situation. What would you recommend should be done?
This model is about how badly wrong the development and implementation can
become, but it applies equally to the imposition of change. The secret lies in
preventing this situation from arising by
Making sure that everyone understands the reasons for the change
Has the opportunity to play a part in influencing the shape of the new situation
or system
And doesnt have to deal with so much change that there are no anchor points
for those involved.
Q !ou are the pro"ect manager for a new management accounting system that will
provide monthly profit and loss accounts to a chain of #$ computer dealerships% each of
which is franchised to its local owner&manager. 'hey have all done their own accounting
before. What change issues would you e(pect to encounter? )oes the fact that they are *+
dealerships make any difference? Why might they have "oined together in the chain?
everal change issues will arise!
the imperative to change" #hy does the franchise owner want to impose this
change $ if indeed it is being imposed"
meeting the many and varied individual needs
the implementation process
the changeover process
post implementation support
the nature of the franchisees response and the resistance if any
%n principle, the fact that they are &' dealerships should make little difference, but
they will be well aware of the problems of changing over from one software system to
another, and interfacing it to other e(isting systems.
The dealers probably )oined the franchise network in the first place to share
purchasing, advertising and marketing costs. They may pay the franchise owner
according to their success, in which case the new system may have a big impact on
them as it will declare financial information in a consistent manner across all
franchisees and reduce the opportunity for creative ad)ustments by the franchisees.
Q# +onsider the organisation that employs you or where you study. What is its culture?
Why does it have that particular culture? What organisational culture would give you most
satisfaction as an employee? Where might you find such an employer? ,iven your
preferred organisational culture% what would it mean for you as an employee in terms of
your responsibilities and obligations?
Two models for analysing culture have been described in this chapter. %dentify your
organisations culture using these models. #ork with others if you can. The culture
may be the result of deliberate choice or may have arisen by accident. The key
*s and As &age + of ,-
question is whether or not it moves the organisation forwards in an efficient way
towards the achievement of its goals.
To identify a culture that suits you, first work out what you want from your work and
from your employer. .o you like freedom to get on with things, the opportunity to be
creative, and do you have an urge to make changes all of the time. /ou do" Then an
Apollo culture may not suit you. The is no inherently 0good or 0bad culture )ust
different ones, so choosing one that suits you is a personal choice that doesnt come
with value )udgements attached.
Q- !ou have to design a .hearts and minds/ programme connected with the
implementation of a new system for the recording and management of stock in a book0
publishing company and for the supply of books to booksellers. What would be the main
stages of such a programme?
A good place to start is with the reasons for the implementation of this system. %f it
aims to reduce stock holding costs for the publisher but may lead to delays in shipping
books to bookshops, then the message is different from if it also speeded up or made
easier the ordering and delivery of books.
1e(t, make a stakeholder analysis and assess the impact of the new system on the
different stakeholders. %nvolve the stakeholders in planning for implementation and
think about getting key 0change agents from the publisher and the book trade to work
with you.
2nsure that everyone knows whats happening and that people are properly trained
and supported. 'reate a forum for the identification and speedy solution of issues.
Chapter # $usiness strategy and information systems
Q1 Why is it important for pro"ect managers to understand the strategy of the organisation
that uses their services?
%t enables the pro)ect to be seen in the conte(t of what the business is trying to
achieve. %t means that links between this system and others under development or in
operation can be better understood and managed. %t enables the pro)ect manager to
see how the pro)ect delivers value and how further value could come through the
identification of new opportunities.
Q 1f you knew about an organisation/s strategy% could you suggest 12 applications that
would support it? For e(ample% how could a large supermarket chain use information
systems for cost reduction% or for a strategy based on differentiation?
ystems that aim at cost reduction strategies might lead to applications development
in logistics, stock control and stock planning, or in financial management and
budgetary control, or in supplier management. .ifferentiation strategies might call
for T*M applications, the launch of new systems in customer care or in symbiotic
applications such as personal banking, loans and insurance.
*s and As &age 3 of ,-
Q# 1f you had to develop a strategy for a small software house employing 3$ or so
professional computer people% how would you go about it? What criteria would you use to
test whether or not the strategy was sound?
A firm of this si4e is probably owned and run by the top management with some
outside financial backing, so you should work first of all with this group of
stakeholders. /ou could take it in stages as follows!
+. 'ollect data. #hat does the management team think" #hat are the
companys strengths and weaknesses 5use #6T"7 and core competencies"
#hat about competitors and markets.
3. .evelop some alternatives and evaluate their attractiveness. .ecide on the
kind of business they want to be.
,. 'reate a vision for the business and a strategy to achieve it.
8. &ut the structures, systems, styles, skills, staff and shared values in place to
achieve the strategy.
To test the soundness of the strategy you could ask someone else to assess it for
'larity. .o all of the companys managers know what to do in their
part of the business to support the strategy"
2mpowerment. %s everyone enthusiastic about it and do they feel
empowered to act to achieve it"
'oncentration. .oes the strategy focus on the core competences of the
business"
9le(ibility. 'an the strategy be fle(ed in the face of market changes
and competitive pressures"
Chapter % &he business case
Q1 At what point in the pro"ect lifecycle should the business case be prepared?
The short answer to this is 0before any serious work has been done and before ma)or
resources are committed to the pro)ect. Many pro)ects are preceded by a feasibility
study, the aim of which is to see whether there is a prima facie case for undertaking
the pro)ect and a business case is often a ma)or output from such a study.
%n addition, % studies often start with some form of requirements analysis and
specification. #here this is the case, the detailed information discovered here may
necessitate a reappraisal of the business case, to make sure that the costs and benefits
identified in the feasibility study are still realistic.
%n fact, the business case should be revisited at each stage of a pro)ect, to make sure
that the pro)ect is still on target to achieve the business benefits for which the pro)ect
has been initiated.
Q What should be the role of the pro"ect manager in relation to the business case?
%deally, the pro)ect manager should be appointed early enough to contribute to the
development of the business case $ or even to take the lead in its development. At the
*s and As &age , of ,-
very least, someone with a pro)ect management background should be asked to review
the business case to make sure that the approach proposed is realistic.
%f the pro)ect manager has not contributed to the creation of the business case, then
one of his or her first )obs after appointment should be e(amine it and to satisfy
themselves that they are happy to take responsibility for the pro)ect. %f they think that
the scope, budget or timescale is unfeasible, they should raise their ob)ections with the
pro)ect sponsor and endeavour to negotiate a more realistic programme.
6nce the pro)ect is underway, the pro)ect manager needs to keep a watchful eye on the
business case to make sure that the way the pro)ect is going is not going to
compromise the achievement of the benefits outlined in the business case.
Q# 4(plain the term .cost&benefit analysis/
'ost:benefit analysis is the process of identifying, and as far as possible quantifying,
the costs of undertaking a pro)ect and contrasting these with the benefits e(pected to
flow from it. 9or a pro)ect to be approved, senior managers will have to be convinced
that the benefits outweigh the costs.
Q- What do you understand by the terms .tangible/ and .intangible/ when applied to costs
and benefits?
Tangible costs or benefits are those for which a plausible quantitative value can be
calculated, such as increased profits or reduced staff costs. %ntangible costs or
benefits are those where it is not practical to calculate a quantitative value.
%n theory, almost anything can be quantified, given enough time and the right
resources to do the analysis. 9or e(ample, 0improved public image could be
measured through opinion polls or surveys and could even, perhaps, be linked directly
to sales figures. However, in most cases, the e(pert resources are not available to do
the research and, in any case, the results are often debatable and sometimes not
believed by the decision makers. %t is generally better, therefore, when dealing with
intangible costs and benefits to e(plain in the business case what they are and to let
the decision makers put their own 5sub)ective7 value on what they might be worth.
Q3 What is meant by the term .benefits realisation/ and why is it important?
;enefits realisation is the process of managing a pro)ect $ and the post<pro)ect
operation of, for e(ample, a new information system $ so as to ma(imise the chances
of getting the benefits claimed in the business case. All pro)ects should be followed,
after a suitable interval, by a post<pro)ect review, the main aim of which should be to
find out whether the e(pected benefits have been realised or not.
Chapter ' &he organisational frame!or(
Q1 5ow many different types of customer may there be for a systems development pro"ect?
Who are they? What kind of relationship and reporting arrangements should the pro"ect
manager have with the sponsor?
.epending on the specific pro)ect, the 0customers could include some or all of the
following=
The management of the organisation that has commissioned the pro)ect, who will
be interested in the achievement of the benefits described in the business case.
The users of the proposed information system, who will probably mainly be
interested in its effects on their )obs.
The end<customers of the organisation commissioning the pro)ect, who will be
interested in how it affects the 0customer e(perience.
Managers and others in other departments indirectly affected by the pro)ect.
The sponsor of a pro)ect represents the management of the organisation that
commissioned it. Thus, she or he is TH2 customer for the pro)ect manager and it is
important that they have a good, frank and effective working relationship. The
sponsor and pro)ect manager should agree between themselves a suitable timescale
and framework for reporting but, typically, this would involve a regular written report
supplemented by a meeting where issues can be discussed face<to<face. The
frequency of reporting will clearly depend on the overall si4e and timescale of the
pro)ect! one with a total duration of a month or so will probably require weekly
reports but, for a pro)ect spanning several months, a monthly reporting cycle may be
sufficient.
Q )escribe the roles of 6a7 the sponsor and 6b7 the pro"ect manager
5a7 The sponsors role is to represent the organisation commissioning the pro)ect and
to make the ma)or business decisions concerning it. The sponsor should approve the
original pro)ect initiation document and decide on any subsequent changes of scope.
The sponsor is also the 0internal champion of the pro)ect and may, on occasion, have
to 0knock heads together where various users cannot agree on the pro)ects direction.
At the end of the pro)ect, it is the sponsor who must accept from the pro)ect teams the
various deliverables specified.
5b7 The pro)ect manager is responsible for the day<to<day management of the pro)ect
within constraints laid down by the sponsor. %t is a good idea for the pro)ect manager
to be given some tolerances within which to operate $ for e(ample, a completion
deadline of +
st
March with permission to delay until +
st
April if necessary. 2ssentially,
it is the pro)ect managers )ob to ensure that the defined scope of the pro)ect is
delivered within timescale and budget.
Q# What are the principal problems of managing pro"ects within a completely functional
organisation structure?
The main problems of functional organisations are to do with what may be termed a
0silo mentality, whereby people pursue functional, rather than organisational,
ob)ectives. %n addition, people may have little knowledge of $ or interest in $ things
outside of their functional specialism.
The problem with managing a pro)ect in this environment is that, if the pro)ect is run
from within one function, people from other functions may not cooperate fully with it,
*s and As &age - of ,-
or may even work to frustrate it. %f the pro)ect is cross<functional, the pro)ect manager
may face interference from line managers in the various functions.
Q- What are the pros and cons of a .pure/ pro"ect organisation compared with a pro"ect
operating within a matri( structure
A 0pure pro)ect organisation contains within itself all of the resources needed to
complete the pro)ects ob)ectives. Thus, the pro)ect manager has the whole pro)ect
under his or her direct control. However, the pro)ect may be inefficient in its use of
resources, since one cannot have less than one resource of a particular type even if
there is not a full<time )ob for that person. %n addition, pro)ect team members often
suffer from a feeling of insecurity, not knowing what will happen to them at the end of
the pro)ect. 9inally, the pro)ect may become somewhat detached from $ and possibly
resented by $ the rest of the organisation.
A pro)ect operating within a matri( structure tends to be more resource efficient since
it is perfectly feasible, say, to have the part<time services of a particular specialist.
Team members also do not lose touch with their 0home functions. The main
problems with matri( structures stem from people having more than one manager,
leading to difficulties in prioritisation of effort and time management.
Q3 1n a *819+4: pro"ect structure there are formal committees% a pro"ect board and
specific roles. What is your opinion about the value of this kind of arrangement? 5ow do
you see it working in large and small pro"ects? +ould it be useful for pro"ects outside 1'?
The use of established roles within the &>%1'23? environment usually smoothes
setting up a pro)ect, since people get to understand what is required of, for e(ample,
the 0e(ecutive on a pro)ect board. The pro)ect board itself provides an e(cellent
forum for the various stakeholders and customers 5see question +7 to come together to
make decisions about the pro)ect. &art of the design brief for &>%1'23? was to
make it suitable for non<%T pro)ects. &>%1'23? has been proven in practice over a
large number of large pro)ects.
maller pro)ects often have some difficulty with the &>%1'23? approach, since it
can feel somewhat bureaucratic and top<heavy in these circumstances. ;ut it is a
tailorable approach and, for e(ample, the pro)ect board can be reduced to two people
e(ecutive:senior user and senior supplier7 if that seems appropriate. The reporting
regime between the pro)ect manager and pro)ect board can also be streamlined and
abbreviated for smaller pro)ects.
Chapter ) &he programme and project support office
Q1 4(plain why the concept of **2; arose in the first place.
The origins of the &&6 lie in the provision of administrative support for pro)ect
managers, to take care of some of the routine tasks such as writing meeting minutes
and updating plans. %n time, it was realised that this sort of support was required for
all pro)ects and could be most efficiently supplied by having a &&6 that supports a
number of pro)ects. This also enables &&6 personnel to develop a good
*s and As &age @ of ,-
understanding of the basic issues of pro)ect management, which can be placed at the
disposal of many pro)ect managers.
Q What are the advantages to an organisation of having a **2;?
The main advantages to an organisation from having a &&6 include=
'ollection of information on past pro)ects, which can be used to assist in planning
and risk management.
'onsistency of approach, in terms of practices, planning and documentation,
across all pro)ects $ thereby avoiding 0re<inventing the wheel for each new
pro)ect.
%ndependence, whereby the &&6 can provide a slightly different perspective on
all pro)ects for senior management.
pecialism, where &&6 staff develop skills $ for e(ample in pro)ect management
tools $ that can be used by many pro)ects.
'entre of e(cellence $ the development of a central repository of guidance for
pro)ect managers and pro)ect teams.
Q# What conflicts are likely to arise between pro"ect managers and **2; staff?
&&6 staff can, if they are not careful $ or if they are not properly managed $ begin to
think that they are actually running pro)ects, rather than acting as a support function.
The management of the pro)ect remains the responsibility of the pro)ect manager.
%n addition, in pursuit of consistency, &&6 staff may try to impose on all pro)ects the
same 0one si4e fits all methods and standards, where specific pro)ects require a more
tailored approach.
9inally, where senior management ask a &&6 to audit the various pro)ects that they
support, the &&6 can come to be seen by pro)ect managers as a 0police force, rather
than as a support organisation.
Q- What skills are useful when working in **2;?
The skills that are most useful probably include=
A logical approach to the collection and analysis of information.
The ability to draft succinct meeting minutes and reports.
kill in using pro)ect management and other software packages.
Tenacity in getting to the real facts of a situation.
.iplomacy and tact for dealing with people involved in pro)ects, who are usually
under a lot of pressure.
Chapter * De+elopment lifecycles and approaches
Q1 !ou have been asked to take charge of a system development where the customer
re<uires about 3$ per cent of the functionality very urgently to meet a business opportunity
but where the remaining functions can be delivered over the ne(t few years. Which of the
various development lifecycles do you think would be most suitable for this pro"ect and
why?
*s and As &age A of ,-
2ither the incremental or the spiral model would provide a good approach in this
situation. #ith the incremental approach, the whole system is designed in outline and
then developed and delivered as a number of stages. The spiral model assumes no
overall design at the outset and the system evolves as new features are introduced in
progressive stages. #hich of the two lifecycles is most suitable in the circumstances
described may depend on how fully the users of the proposed system can specify their
overall requirement at this stage.
Q What would you say are the principal advantages and disadvantages of the se<uential
approach to system development offered by the waterfall and .=/ lifecycle models?
The waterfall approach and its 0B model variant offer a logical set of steps that have
to be followed to develop and implement a system. They provide good control for a
pro)ect manager as $ in theory at any rate $ each stage should be complete and signed
off by the pro)ect sponsor before proceeding to the ne(t. This also means that each
stage builds properly on its predecessor and hence assists in the creation of a high<
quality deliverable. The models assist in resource deployment as it is easier to see
what skills are needed at each stage $ business or systems analysis during
requirements analysis, designers during the design stages, development during code
and test and so on. The 0B model has the additional advantage that it shows
e(plicitly the connections between the earlier and later pro)ect stages $ between
requirements specification and user acceptance for e(ample.
The main disadvantages of these approaches are that pro)ects undertaken with them
can take rather a long time from inception to delivery and this is often not very
suitable for modern business conditions, where change is incessant and constant.
#ith the linear approaches, changes that arise later in the pro)ect are difficult to
accommodate as the earlier stages should be revisited to reflect the changes. 9inally,
these approaches do assume, as a starting point, that the users can specify in some
detail what they want from their new system whereas in many cases $ for e(ample,
where a system is needed to meet an unprecedented business situation $ this is very
far from being the case. #here such uncertainty e(ists, an evolutionary lifecycle 5the
spiral7 is probably more suitable.
Q# 2ome critics have said that the use of structured methods% such as 22A)>% increases
both delivery time and bureaucracy. )o you think these criticisms are "ustified and what
are the claimed advantages in the use of structured methods?
%t is true that structured methods require more work to be done 0up front in a pro)ect,
during the analysis and design stages. The formality and rigour that their techniques
impose require analysts to get down to more detail than often happened using
0traditional methods. The upside of this, of course, is that there is greater clarity
about what the users want which should 5a7 reduce the actual work of system
construction, since programmers do not have to keep going back to the users with
questions and 5b7 result in a system that better meets the usersC real needs.
An additional advantage of the depth and quality of documentation that results from a
structured approach is that it is easier to maintain and enhance the system once
delivered. ;earing in mind that most of the costs of an information system are
incurred after initial delivery, this can be of considerable benefit.
*s and As &age D of ,-
However, it has to be admitted that, although these advantages sound plausible, there
is an unfortunate lack of hard evidence to prove that they have been realised in
practice. To a large e(tent, the benefits of the structured approach are only apparent to
people who have worked in the % field for some time, especially those involved in
maintenance and support.
tructured methods are, nevertheless, open to the charge of bureaucracy. ;ecause
everything is documented very thoroughly, pro)ects using structured methods can end
up accumulating a vast amount of paperwork. This, in turn, can prove very difficult to
control and lead to the pro)ect team spending a lot of time in document management
instead of in actual analysis or development. The answer to this, of course, is to find
$ or perhaps create, using one of the readily<available database products $ a suitable
'A2 5computer<aided software engineering7 tool.
Q- 1ncreasing interest is being taken in the use of rapid application development. Why is
this% and are there any dangers associated with the 8A) approach?
>A. has come to prominence because of the increasing pace of change within all
organisations. The argument goes that, against such a background, the conventional,
linear approaches $ as represented by the waterfall lifecycle $ do not produce results
quickly enough. 6ften, it is more important to get some sort of solution quickly than
the best solution in a couple of years. %n addition, the advocates of >A., for e(ample
the ..M 'onsortium, contend that, because of the close working relationship
between users and developers that is inherent in the >A. approach, the users are
more likely to get a system that meets their real needs than with a more conventional
approach. %ndeed, in recent years, >A.s proponents have been stressing fitness to
purpose over speed of development.
The main dangers associated with >A. are to do with its very speed in that it leaves
little time for reflection and, if not managed tightly, less still for documentation.
ome critics have described >A. as a 0licence to hack. The real problems with
poorly documented systems come later in their lifecycle, when maintenance becomes
difficult and unpredictable, since the support engineers do not have adequate
information on why and how the system has been created as it is. A further potential
problem is that the part of the system chosen as a starting point $ because of perceived
business needs $ may not, in fact, turn out to be quite so central and the finished
system may be 0skewed as a result.
Q3 +onsider how you would organise your pro"ect team for a 8A)0type pro"ect. What
leadership practices would it re<uire from the pro"ect leader and what would the team
members have to do? 5ow% and at which points% would you involve the users?
>A. requires, for its success, a close and ongoing relationship between developers
and users. The actual organisation may depend on the skills available on the
development team, for e(ample=
%f the analysts have the skills to create software themselves, they may themselves
work with the users to create and evaluate prototypes! this represents, in effect, a
return of the old 0analyst:programmer role.
*s and As &age E of ,-
6therwise, analysts and developers will have to form small )oint teams to work
with the users.
A ma)or issue for pro)ect leaders in a >A. environment is what may be called
0e(pectation management. The users $ and also the developers $ must be kept
focused on the 5limited7 ob)ectives of the stage in hand and must also be encouraged
to keep to the often<tight timescales for the stage. Fsers often also need convincing
that they can forego some feature in the current stage but that they will get it in a later
stage. There is often the additional difficulty that user management want something
different $ often less < from the 0coal<face users of the system and the pro)ect leader
must make sure that the views of both constituencies are considered and managed.
Fsers must be involved at all stages of a >A. pro)ect, from initial definition of
requirements $ however generalised $ through the development of prototypes to the
testing of the finished system increments.
Q? What have 8A) and e(treme programming got in common? What are the claimed
advantages of these approaches?
;oth >A. and G& have as their common aim, and as their primary claimed benefit,
the speedy delivery of system features and functionality to meet users needs. The
difference between the two approaches are mainly to do with scale and scope!
whereas >A. is about the development of entire systems, G& seems more concerned
with adding individual features. ;oth approaches involve developers working closely
with users to define the need 5by using 0stories in the case of G&, by developing
prototypes in >A.7 and the advocates of both also stress the need for proper
documentation of the results.
Q7 Why are approaches such as the 2oft 2ystems >ethodology% the 2ocio0'echnical
Approach and @usiness *rocess 8eengineering relevant to 12 pro"ect managers?
The development of information systems does not take place in a vacuum and is not
solely a technical e(ercise. %nformation systems are created to meet business needs
and they have to be developed and implemented within the structure, processes and
culture of an organisation.
The oft ystems Methodology takes a holistic view of 0systems, regarding a
business system 50human activity system in the M terminology7 as something that
takes place within a cultural and structural conte(t. imilarly, the ocio<Technical
approach recognises that systems cannot be simply regarded as inanimate things, and
offers concepts for placing systems in their human and organisational conte(t.
9inally, ;usiness &rocess >eengineering is concerned with the radical redevelopment
of business systems so as to improve the effectiveness and efficiency with which
inputs are transformed into outputs valued by the customer. Many ;&> solutions
involve the use of information and communications technology to promote and
support these improvements.
Chapter , &he profile of a project
Q1 What work goes on prior to pro"ect start0up?
*s and As &age +H of ,-
;efore pro)ect start<up, work is needed to establish the ob)ectives and scope of the
pro)ect. %t is necessary to establish the dimensions of the 0triple constraint of time,
cost and scope:product:quality. #here the development work is to be undertaken by
an e(ternal supplier, there may also be a process of tendering and negotiating a
suitable form of contract for the pro)ect.
%n addition, the pro)ect may be preceded by a feasibility study, which is designed to
establish the business case for the pro)ect and perhaps to e(plore alternative methods
of meeting the perceived business need.
Q )escribe the products that typically result from the following pro"ect stagesA *ro"ect
2tart0upB Analysis of 8e<uirementsB )esign 1ntegration and 'esting.
Typical products include=
&ro)ect tart<Fp= &ro)ect %nitiation .ocument! &ro)ect &lan! *uality &lan! >isk
Management &lan! 'onfiguration Management &lan. 1ote that these various
plans may be combined into one document, especially for smaller pro)ects.
Analysis of >equirements= >equirements pecification 5covering the
requirements themselves plus definitions of the processing and data requirements
for the system7.
.esign= Technical .esign 5include overall architecture of the proposed system,
module specifications and database schema7.
%ntegration= individual modules combined together to create a working system.
Testing= Test results 5from integration, system and acceptance tests7 and an
Acceptance 'ertificate from the users confirming that it meets their requirements
as defined in the >equirements pecification.
Q# 4(plain the incremental approach to testing represented by the se<uenceA unit
6module7 testB integration testB system testB acceptance test.
#ith the incremental approach to testing, each unit 5module or program7 of the system
is first tested to ensure that it does what it supposed to do as defined in the module
specifications. This testing is often carried out by the programmers who developed
the modules, although sometimes a 0peer review approach is used instead.
The integration test seeks to find out whether the modules, when fitted together,
operate as e(pected and interact without problems. The baseline here is provided by
the Technical .esign and by the >equirements pecification. %ntegration testing is
often the responsibility of a specialist testing team.
%n system testing, the developers are checking that the system provides the
functionality defined by the users in the >equirements pecification. As well as the
developers and testers, the business or systems analysts may be involved here to look
at the system from a user perspective.
9inally, the users are invited to conduct an acceptance test to check that what they
have asked for in the >equirements pecification has been provided. 6ften, the users
require help from the business or systems analysts in performing these tests and the
pro)ect manager may also become involved to manage the process! to ensure, for
*s and As &age ++ of ,-
e(ample, that the users do not introduce into the tests any criteria that were not
mentioned in the >equirements pecification.
ometimes, because of overruns in earlier stages, it is necessary to combine the
system and acceptance tests. Although unavoidable, this is not desirable since, by
definition, all of the 0bugs will not have been eliminated before the system testing
5that, after all, is the point of it7 and too many problems can undermine the users
confidence in their new system.
Q- From what product should the acceptance criteria for a pro"ect be derived and why?
The acceptance criteria should be derived from the >equirements pecification, which
is where the users stated needs are documented. The actual acceptance criteria may
not necessarily be defined in the >equirements pecification, which might thereby
become too large and unwieldy, but it is important to make the requirements as
specific and measurable as possible to avoid later arguments over acceptance! for
e(ample, 0a response time of less than 3 seconds for EHI of transactions is a lot more
precise than 0a fast response time. ince the acceptance criteria are based on the
>equirements pecification, this emphasises the importance of that document.
Q3 Why is it important that the pro"ect team and the users develop and agree a process
model for a pro"ect?
Any pro)ect is a cooperative venture between the clients:users and the
suppliers:developers and it is important that both parties have a clear understanding of
what will happen, when and what are their respective responsibilities. A process
model provides a framework so that both parties can see where they will be involved
and what their roles will be at each stage. %t also highlights the important milestones
in the pro)ect and enables the stakeholders to plan their time so as to be available
when they are required.
Chapter - Project planning. understanding the !or(
Q1 ,ive three reasons why it is essential to plan an 12 pro"ect in detail before starting
work on it.
6nly the simplest pro)ects $ which probably means one developer working for one
user $ can get away without having a proper plan of work. 2ven then, both parties
will probably have reached some informal agreement about the order in which things
are to be done and this does constitute a basic plan. Most % pro)ects, however, are
much more complicated than this and, as comple(ity and the number of stakeholders
increases, it becomes more and more important to plan the pro)ect in detail. #ithout
having a detailed plan=
>oles and responsibilities are not defined properly.
The parties involved do not have a clear and shared understanding of the activities
and deliverables involved.
.ependencies, both between activities and on third parties outside of the pro)ect,
are not e(plored and can lead to difficulties during pro)ect e(ecution.
*s and As &age +3 of ,-
%t is probably true that, important though a good pro)ect plan is, a lot of the value in
planning is that it requires the pro)ect manager to think through how they want to
approach the pro)ect and thereby end up with a much clearer idea of the approach they
are going to take.
Q 1deally% the re<uirement for an 12 pro"ect would be specified in some detail before
planning begins. 1f the re<uirement is not detailed enough% what steps can the pro"ect
manager take to improve the likelihood of the pro"ect/s success?
%f the requirements are not specified in enough detail, the pro)ect manager may need
to make some assumptions in order to get started. %f so, these assumptions needed to
be clearly documented, preferably in the &ro)ect %nitiation .ocument, and the
assumptions should be drawn to the attention of the users and, in particular, of the
sponsor. These assumptions then form part of the initial 0baseline for the pro)ect and,
should the work later prove more e(tensive or time<consuming than assumed, the
pro)ect manager will have a good case for approaching the sponsor for more time,
budget or resources to complete it.
Q# 1n essence there are two basic ways of breaking down a pro"ect into plannable chunksA
the use of a work breakdown structure or a product breakdown structure. +ontrast the
advantages and disadvantages of these approaches.
The work breakdown structure 5#;7 concentrates on tasks and the product
breakdown structure 5&;7 on deliverables from tasks. ;oth methods are used and, in
fact, they can be combined so that, at the top levels, the pro)ect is broken down by
product and then, once individual products have been identified, a work breakdown is
created.
The #; is the more traditional approach, and is the basis for most of the readily<
available pro)ect planning software, which makes it easy to adopt and to represent on
a computer. The advantage of the &; is that it requires a concentration on ends
rather than means and it can be somewhat easier to apply in the early stages of
planning where the actual work is unclear but the required deliverables are better
understood. %n addition, once the individual products have been identified, it is
possible to create for them product descriptions that provide, as it were, specifications
of work for the individuals or teams tasked with their development.
Q- What do you understand by the term dependency? 5ow can pro"ect dependencies be
represented for planning purposes?
.ependency occurs when, for e(ample, task or deliverable 0A must be completed
before task or deliverable 0; can be started. %n a comple( pro)ect, the analysis of
dependencies helps to identify streams of work that can be performed in parallel, thus
shortening the overall duration of the pro)ect. The normal way that dependencies are
represented is on a dependency diagram, also known as a network diagram or a &2>T
chart. Microsoft? &ro)ect also shows dependencies on the bar:Jantt chart by vertical
connections between task bars but this can get somewhat confusing on a large or
comple( pro)ect.
Q3 )efine the terms CproductD and Cwork packageD and e(plain how these are related to
each other.
*s and As &age +, of ,-
A product is an individual deliverable from a pro)ect and it may also form a work
package if it is assigned on its own to an individual or team. More commonly,
though, a group of related products $ perhaps products that need to be created together
$ may form a work package.
Q? 9etwork diagrams and bar charts have different parts to play in planning a pro"ect.
Where is each of these tools used and what does it show?
The network diagram analyses and displays the dependencies between the tasks or
deliverables on a pro)ect and it is used to identify the streams of work that can be
undertaken in parallel. The bar chart shows all of the tasks placed against a timeline
to show when they are to be done. The network diagram does not show this contrast
with the timeline very well, whereas on the bar chart the dependencies between tasks
is not necessarily self<evident. The network diagram has other uses, for e(ample in
analysing the potential effect of slippages and risks on the achievement of the
pro)ects deadlines.
Chapter / Project planning. estimating
Q1 4(plain three reasons why estimating for 12 pro"ects has a poor reputation and a bad
track record. What can be done about these problems?
There are a number of reasons which could be advanced, including=
High degree of innovation= Most % pro)ects involve some innovation and many
involve a lot of it. %n these circumstances, it is difficult for the estimators to find
precedents on which to base their assessments. This is often coupled with undue
optimism about what can be achieved by when. The answer to this is to divide the
pro)ect up into its innovative and less innovative components! for the latter,
e(perience and perhaps data from previous pro)ects can be used and, for the
former, ranges rather than single<point estimates can be offered.
Too early commitment= 9irm estimates are often given in % pro)ects before a
clear and agreed >equirements pecification $ still less a full Technical .esign $
is available. hort of refusing the give firm estimates at this stage $ which would
be the logical course of action $ pro)ect managers may again have to insist on
quoting a range of estimates, shortest, most likely and worst<case.
Kack of metrics= 9or some reason, people in the % community are not good at
collecting and publishing metrics even when, as in the case of '6;6K
programming, there should be decades of e(perience to draw on. %n the absence
of industry< or organisation<wide metrics<collection initiatives, pro)ect managers
need to collect data from their own pro)ects for later use, by themselves and
others.
Kack of specialist estimating skills= Fnlike, say, civil engineering, where
specialist estimators are used, in % almost anyone is presumed to be capable of
developing a set of estimates. &ro)ect managers should, ideally, insist on the
involvement of technical people with e(tensive e(perience of the technologies
involved. They should also get more than one opinion, and use more than one
estimating method, and cross<check the results.
*s and As &age +8 of ,-
Q 'he analogy method of estimating is often used to produce broad0brush estimates at
the start of a pro"ect. Why is this method particularly suited to this application?
9inding an analogous pro)ect on which to base estimates does not require the detailed
analysis and work breakdowns required of other methods and so can be used to
generate an estimate fairly quickly. This is particularly suitable at the start of a pro)ect
when the decision<makers are probable more interested in knowing what 0ballpark
they are in, rather than having an e(act calculation of costs and timescales.
Q# 'he analysis effort and programming methods both rest on the principle of
e(trapolating the total development effort from detailed estimates of one phase of the
pro"ect. )escribe the approach taken in each of these methods and show in what
circumstances each might best be employed.
#ith the analysis effort method, the stage of the pro)ect that forms the basis for the
estimates is the analysis of requirements. 2stimates for this can be arrived at by
considering the stakeholders to be involved, the methods to be used 5interviews or
workshops for e(ample7 and by allocating sensible amounts of effort to these. The
analysis effort method is probably the best choice where there is only a vague idea of
the actual requirement but where the stakeholders to be involved in the analysis work
can be identified.
The programming method requires specialists well<versed in the technologies to be
used to take a look at the requirements and then to assess the effort involved to create
the required programs. This could be done by estimating lines of code or perhaps by
categorising programs as large, medium or small or as comple(, moderate or simple.
'learly, this method is most relevant where a >equirements pecification $ perhaps
received as part of an invitation to tender $ is available that gives a good general idea
of the programs likely to be needed.
Q- 'he )elphi techni<ue aims to achieve a consensus estimate from the efforts of a
number of estimators. 5ow is this achieved and what is the advantage of the )elphi
techni<ue over% for e(ample% a round0table discussion?
The chief problem with a round<table discussion is that the personalities and egos of
the estimators get caught up in what should be a rational, dispassionate process.
&eople may feel forced to defend their estimates $ high or low $ because to do
otherwise would be seen to involve a loss of 0face with respected technical
colleagues. The .elphi technique involves asking for estimates from a number of
people and then circulating the results anonymously for all to see. ;ecause the
estimates are anonymous, estimators will not lose face by changing their minds and
seeing other peoples estimates may well cause re<thinks. The problem with the
.elphi technique is that people cannot ask questions about how others have arrived at
their estimates and they may thereby miss some important issues that others have
considered. ;arry ;oehm 5see earlier7 found that a combination of the .elphi
technique with well<run workshops tended to produce good results.
Q3 )escribe how you would go about estimating for the following supporting pro"ect
activities and why you would take your chosen approach to each.
a7 *ro"ect management
*s and As &age +- of ,-
b7 'eam leading&supervision
c7 Quality control
d7 Familiarisation.
a7 &ro)ect management effort is dependent on two things $ whether a full<time
pro)ect manager is to be used or not and the overall e(pected duration of the
pro)ect. %f a full<time manager is required, then one simply multiplies the duration
of the pro)ect by four to get the number of days effort involved 5see the main te(t
for a discussion of why only four days a week is available for each person over the
long run7. %f a half<time pro)ect manager is to be used, then the number of weeks
is multiplied by two and so on.
b7 Team leading can be worked out using the 0rule of thumb that a team leader can
effectively supervise up to five programmers. o, one starts with the total
programming effort and divides by five to get the amount of team leading. #ith
some of the newer, high<productivity programming environments, a ratio of +=8
for team leading may be more appropriate.
c7 *uality control can be added as a percentage on top of each 0doing activity like
creating programs. %n working out what percentage to use, it must be remembered
that quality control review often lead to rework which must also be included in the
estimates.
d7 9amiliarisation is best calculated as an allowance 5a number of days7 per team
member, based on their prior understanding of the business and technical
environment.
Q? 2tate three factors that could influence the estimates for an 12 pro"ect and how you
would attempt to ad"ust the estimates for these factors.
>elevant factors include=
taff e(perience= %n %, the productivity of people, especially developers, can vary
widely, largely but not entirely depending on their e(perience. 6ften, estimates
are made on the assumption that fully<e(perienced personnel will be assigned to
the pro)ect and then a team of newly<trained people is provided instead.
2(perience does not )ust mean technical e(pertise either! equally important is
e(perience of the business area in which the proposed information system will
operate. %n developing the estimates, therefore, it is important to find out e(actly
who will be assigned to the pro)ect and:or to create alternative estimates based on
varying levels of skill within the pro)ect team.
Fse of contract staff= These are often an unknown quantity. %t is reasonable to
assume that people who can make a living freelancing in specific technologies
have a reasonable grip on those technologies but this cannot be guaranteed. %n
addition, contractors may not be familiar with the methods and standards used in
the organisation and there may be a lot of rework required to get their work in line
with those of employed staff. ;efore committing to any estimates, it is wise to
*s and As &age +@ of ,-
interview any proposed contractors and to form an opinion as to whether any
ad)ustments to the timescale may be needed.
Fser involvement and support= The commitment of users and user management to
the pro)ect cannot be assured and many pro)ects get behind schedule because users
cannot find time to review products such as the >equirements pecification. %n
the pre<pro)ect stage, the pro)ect manager should try to form a view about the
users and their commitment to the pro)ect and should make sure that user
responsibilities are fully spelled out in the &ro)ect %nitiation .ocument. %n
addition, it is wise to take user dependencies into account in preparing the pro)ect
plan and to avoid, if possible, putting user tasks on the 0critical path 5see chapter
+H7.
%nstallation and commissioning= This stage of a pro)ect is often either forgotten or
underestimated and can, in fact, turn out to be a considerable piece of work. ome
thought needs to be given to what form of implementation is required 5gradual
cutover, 0big bang or parallel run with old system7, that work should be planned
like any other and proper estimates produced and reviewed by people with
e(perience in the area.
#arranty= %f a system is being developed under contract, it often carries a
warranty for a period of months, or perhaps for a year. %f so, then an assessment
needs to be made of what claims there could be against the warranty and some
contingency should be built in to cover it.
&olitical pressure= 6ften, estimators come under pressure to reduce their estimates
so that some timescale or budgetary constraint can be met. >esisting this requires
a certain amount of willpower but it can be made easier if the estimates have been
developed on sound principles, so that the argument does not degenerate into one
persons guess against anothers.
Chapter "0 Scheduling and resourcing
Q1 4(plain the difference between effort and elapsed time. What is the significance of this
difference for pro"ect planning purposes?
2ffort is the total volume of work involved in a task and is best thought of as how
long it would take to accomplish if one person were assigned to it. 2lapsed time, on
the other hand, is how long the task will take from start to finish and this will depend
on the effort involved, how many people are assigned to the task and what delays or
e(ternal dependencies are involved. 5'reating and correcting an interview report may,
for instance, involve half a days effort but take two weeks elapsed time because the
interviewee is slow to review the document and send back corrections.7 %n planning,
estimates usually 5and rightly7 focus on effort but, when transferring the estimates to
the schedules 5the dependency network and bar chart7, elapsed time also has to be
considered. %n particular, issues like fi(ed 0lead times for obtaining equipment have
to be taken into account.
Q 2cheduling a pro"ect involves understanding the degree to which pro"ect tasks can be
partitioned. What is meant by this term and what effect does partitioning have on the
scheduling process?
*s and As &age +A of ,-
0&artitioning means that a task can be split between more than one person. %f, say, it
takes one man ten days to dig a hole, partitioning it between two men will presumably
mean that the hole can be dug in five days. However, it would probably not be true
that ten men could dig it in one day, partly because they would get in each others way
and partly because some of the time would have to be used in co<ordinating their
efforts rather than actual digging. This leads to the important lesson that one cannot
go on partitioning a task indefinitely and, at some point, one arrives at a task that it is
not sensible to partition any more $ writing<up the results of an interview for e(ample.
Q# 1n long0term pro"ect planning% it is wise to assume that staff will be available for
pro"ect work for less than 1$$ per cent of the total available time. What factors will reduce
staff availability and what ad"ustments should be made for them?
taff will be unavailable for pro)ect work due to=
;ank holidays
Keave
Training courses
ickness
6ther non<working time, such as attendance at company meetings.
The normal way of allowing for this is to schedule people for only four, rather than
five, days work over the duration of a pro)ect. 9or shorter<term planning, where
holidays and training courses are known about, slightly more than four days per week
may be planned for.
Q- What do you understand by the term pro"ect milestone? 5ow would you decide how
many milestones to show on your pro"ect plan?
A milestone is a point at which progress on the pro)ect can be measured. To be useful,
milestones should be attached to the completion of significant deliverables, such as
the acceptance of a >equirements pecification. There need to be sufficient
milestones on a pro)ect plan to allow for adequate control but not so many that their
significance is reduced.
Q3 'he *819+4: pro"ect management method envisages a hierarchy of plans. )escribe
this hierarchy.
At the top level, there would be a &ro)ect &lan that covers the main aspects of the
pro)ect but at a high level of aggregation. 2ach pro)ect stage should then be the
sub)ect of a more detailed tage &lan. #here different teams are involved in the
pro)ect, each may have a very detailed Team &lan for its activities.
#here it becomes evident to a manager in a &>%1'23? pro)ect that their part of the
work is likely to go outside its agreed tolerances, they need to complete an e(ception
report to e(plain the position and an 2(ception &lan showing how they propose to
ad)ust the work to deal with the situation. An 2(ception &lan can e(ist at any or all of
pro)ect, stage or team levels and, if approved, takes the place of the relevant &ro)ect,
tage or Team &lan.
Chapter "" Monitoring progress
*s and As &age +D of ,-
Q1 5ow is effort monitored on a pro"ect? 1t is important that the effort to be spent on
activities is reassessed on a regular basis E why is this so vital?
2ffort is best measured by asking team members to keep timesheets, showing where
e(actly $ on which tasks $ work has been done. This is important so that the pro)ect
manager can keep track of effort and re<evaluate what the final outturn of the pro)ect
is likely to be. %n addition, the effort figures will provide valuable data for people
who may be trying to estimate similar pro)ects in the future.
Q 2taff time is usually the principal cost component of an 12 pro"ect. )escribe five other
areas where pro"ect costs could arise.
&ro)ect costs also arise from=
'ontract labour, where invoices are submitted for the hours worked.
;ought<in items, such as hardware and packaged software, for which again
invoices will be received.
&ro)ect<specific training, either provided in<house or via e(ternal training
providers.
&ro)ect<specific accommodation, for e(ample the leasing of office space.
Kodging and subsistence costs, where people need to work away from a base
location for any length of time.
Travel e(penses, often arranged through third<party travel companies.
'onsumables, such as stationery, cartridges for printers and so on.
%nsurance, for the pro)ects equipment but also to cover such issues as public
liabilities and professional indemnity.
Q# )escribe three methods than could be used to e(ercise <uality control and e(plain the
advantages and disadvantages of each.
Methods include=
elf<checking= *uick, cheap and encourages people to take responsibility for their
own work. ;ut people often have trouble spotting their own mistakes.
&eer review= >elatively ine(pensive and provides a 0second pair of eyes. ;ut
people may be reluctant to criticise their colleagues 5or too eager to do so7 and the
0peer may be too like the author of the product to provide a truly ob)ective view.
Team leader or management review= &rovides a coaching opportunity and allows
the work to be e(amined from a different and perhaps wider perspective. The
manager may not be technically qualified to perform the review and e(cessive use
of the 0red pen can de<motivate staff! also the manager may become a bottleneck
in production.
#alkthrough= Bery thorough, as it involves a number of people e(amining the
product from different perspectives. However, this method is labour<intensive and
therefore e(pensive and committee reviews can be difficult to schedule where
people have busy diaries.
9agan inspection= More structured version of the walkthrough. 2(tremely
thorough but also e(tremely e(pensive and probably best used for very important
or critical deliverables.
2(ternal review= &rovides a very ob)ective review but e(ternal reviewers may not
be familiar enough with the specific pro)ect and raise irrelevant comments.
*s and As &age +E of ,-
Q- 1n what circumstances might you consider increasing the volume and&or fre<uency of
<uality control checks? When might you decrease their volume or fre<uency?
#here a team member is ine(perienced, or )ust unknown, the pro)ect manager may
increase the volume and:or frequency of quality control checks until they are satisfied
that the work is of a sufficient standard. imilarly, checks may be increased where
problems have been uncovered with a particular individual or area of work.
#here the e(isting pattern of checks is uncovering few or no problems, checks may
be decreased in frequency or volume and particular team members may be given more
freedom to work in their own way.
Q3 What does the term .earned value analysis/ mean? What additional insights into the
dynamics of a pro"ect is afforded by the use of 4=A.
2arned value means, in effect, the proportion of a pro)ects total planned deliverable
that has been produced by a given point. 'onventional measurement techniques have
tended to concentrate on effort, or other resources, e(pended, without considering
what has been achieved for that e(penditure, whereas 2BA takes into account both
e(penditure and achievement.
Q? 4(plain these termsA actual cost of work performed 6A+W*7B budgeted cost of work
performed 6@+W*7B budgeted cost of work scheduled 6@+W27.
A'#& is the amount of effort 5e(pressed as such or in monetary terms7 that has
been e(pended in getting to a particular point in a pro)ect.
;'#& is the amount of effort 5or cost7 that should have been e(pended in getting
to a particular point.
;'# is the amount of effort 5or cost7 that should have been e(pended at a
particular point in the pro)ect.
Chapter "# E1ercising control
Q1 What is meant by the term the triple constraint? What are the three elements of the
triple constraint and why is an understanding of their relative weight important in
e(ercising control over a pro"ect?
The term 0triple constraint refers to the fact that any pro)ect takes place within the
envelope of the time it is e(pected to take, the budget available and some
understanding of what has to be delivered, e(pressed as scope, product or quality.
%t is important for a pro)ect manager to understand the balance between the three triple
constraint elements in her pro)ect and this will affect the choices she makes in taking
control actions. #ould it, for e(ample, be acceptable to cut corners in quality to keep
the costs down or must additional funds be found to ensure the quality of the
deliverables"
Q !our pro"ect is behind schedule and you are considering adding e(tra staff to the team.
What would be the potential advantages and disadvantages of this approach?
&rovided that the slippage is spotted early enough, adding e(tra staff may be a feasible
strategy as there will be time for them to be trained and become familiar with the
*s and As &age 3H of ,-
pro)ect. 6therwise, adding e(tra people may actually be counterproductive, as
training them and:or bringing them up to speed on the pro)ect may distract the
e(isting staff from getting on with their work. However, if the slippage is diagnosed
as being due to a lack of e(pertise or e(perience within the pro)ect team, bringing in a
few e(perts may well enable the pro)ect to recover.
Q# 1n what circumstances might you 6a7 increase or 6b7 decrease the amount of
supervision given to a team member?
#here a quality problem has been detected in an individuals work, or where they
seem ine(perienced or unsure of themselves, it may be advisable for them to be
supervised more closely. However, this can prove demoralising to e(perienced and
capable people and the correct approach here may be to give them a lot of latitude to
e(ercise their professional )udgement in how they go about their work.
Q- +hanges often bedevil 12 pro"ects. What steps are re<uired to ensure that proper
change control is e(ercised on a pro"ect?
An effective change control system includes the following steps=
%dentify the change and document it= .o not allow it to 0slip through unnoticed
and unmanaged.
Assess the change= %n terms of its impact on the 0triple constraint factors of time,
cost and scope:product:quality. Also consider what would be the effect of the
change on the pattern of risk on the pro)ect.
.ecide what to do. %f the effect of the change is within the pro)ect managers
tolerances, s:he can make the decision, otherwise the issue will have to be decided
by the pro)ect sponsor.
Q3 4(plain the difference between change control and configuration management and the
relationship between them.
'hange control is the management of the scope of a pro)ect. 'onfiguration
management is the control of the versions of its deliverables and how they fit together.
Jood configuration management records enable a pro)ect manager to assess the e(tent
of the impact of a proposed change, in other words to see which deliverables are
likely to be affected and how.
Chapter "% 2eporting progress
Q1 What factors would you consider when deciding on the fre<uency with which you
would report progress to 6a7 senior 12 management% and 6b7 customer management?
A ma)or factor to consider when deciding the frequency of reporting to anyone is how
long the actual pro)ect is! obviously, if the pro)ect takes only two weeks, a monthly
reporting cycle is not going to be of much useL
Assuming a slightly longer pro)ect duration, however, then reports ought at the least
to be provided at the key milestones, when important deliverables should be finished.
9or reports to the customers $ internal or e(ternal $ reports at key milestones may be
sufficient. However, the pro)ect manager will want to have a regular forum for
*s and As &age 3+ of ,-
meeting customer management and raising any issues that have arisen on the pro)ect
so, if the milestones are a long way apart, perhaps a monthly reporting cycle may be
appropriate. 9or a very fast<moving pro)ect, it may be better to have a brief meeting
once a week )ust to concentrate on the main issues.
% management will probably require more frequent reports, say once a week. These
should, though, be as succinct as possible and concentrate on the main achievements
and problems encountered during the last period or anticipated during the ne(t one.
Q What is meant by the term e(ception reporting? What are the benefits and the
disadvantages of this type of reporting?
2(ception reports concentrate on what has not gone according to plan, the idea being
that things going according to plan is what is supposed to happen and therefore can be
assumed unless informed otherwise. The great advantage of e(ception reporting is
that it makes for short, succinct reports that focus managements attention where it
should be $ on what is going wrong. However, because of this, pure e(ception
reporting tends to assume a rather negative cast and the recipients of the reports will
get the impression that everything is going wrong $ because that is all they are told
aboutL o, most managers tend to depart from the pure e(ception format to emphasise
the achievements, as well as the problems, of their team.
Q# What are the benefits to the pro"ect manager in providing regular progress reports to
the pro"ect team members?
&eople working on a pro)ect like to have an understanding of how its doing and
where what they do fits in to the overall picture. 6n a large pro)ect, in particular,
team members can feel 0buried in their own work with little visibility of the 0big
picture. Also, where bad news $ such as delays and technical problems $ gets known
all too readily on the 0grapevine, better news about deliverables successfully
achieved or how pleased the clients are with progress often gets overlooked. %n
addition to these morale<building aspects of reporting progress to team members, it is
also the case that solutions to problems often come from unlikely sources $ perhaps
someone who is not directly involved in the issue but who can offer a different and
useful perspective on it.
Q- 4(plain the following terms used in the *819+4: pro"ect management methodA
a7 *ro"ect initiation
b7 4nd stage assessment
c7 5ighlight report
d7 +heckpoint.
a7 &ro)ect initiation is a key control point in a &>%1'23? pro)ect as it is where the
&ro)ect ;oard gives formal authority to the pro)ect manager to start work. This
should be done on the basis of a &ro)ect %nitiation .ocument which defines the
scope of the pro)ect and also, in &>%1'23?, includes the ;usiness 'ase and
initial &ro)ect &lan.
b7 At the end of each stage of a &>%1'23? pro)ect, the pro)ect manager is required
to produce an 2nd<tage >eport for the &ro)ect ;oard. This summarises what has
happened during the stage, the problems and how they have been overcome and
requests formal permission to commence the ne(t stage. Thus, 2nd<tage
Assessments are an important part the mechanism by which the organisation keeps
control over pro)ects and prevents them becoming 0runaways.
c7 The Highlight >eport is the regular report from the pro)ect manager to the &ro)ect
;oard. %t focuses on achievements since the last report, problems encountered,
issues and risks and work planned for the ne(t reporting period. 2ssentially, it is
an e(ception report and provides the &ro)ect ;oard with a succinct summary of the
progress of the pro)ect. Highlight >eports are usually based on the relevant
'heckpoint >eports 5see below7.
d7 The 'heckpoint is the regular 5probably weekly7 meeting of a pro)ect or stage
team to review progress. Achievements and deliverables are considered, as are
problems and their potential solutions and any issues or risks that need to be
e(amined. uch meetings are documented in 'heckpoint >eports, and these can
then be summarised to create the &ro)ect ;oards Highlight >eport 5see above7.
Chapter "' Quality
Q1 5ow could the <uality culture behaviours described in section 1-.# be applied in a
hospital?
The total quality management approach and culture are very readily applied to a
hospital. %n general, people working there will be committed to is mission and will be
striving to find better ways to meeting their patients needs. A certain degree of
hierarchy is inevitable in the hospital $ a surgeon must, for instance, be in charge in
the operating theatre $ but modern hospitals are seeing a greater sharing of
responsibilities between, say, doctors and senior nurses and this is leading to more
egalitarian approach. >esources are usually a problem, especially in state<funded
hospitals but this does lead to a need to make sure that scarce resources are utilised
most efficiently.
Q Why do you suppose there are an increasing number of organisations concerned with
the development of <uality practices for 12 development?
%nformation systems often represent considerable e(penditure for organisations and
this has been coupled with increasing scepticism about the value obtained for the
funds spent. At the same time, % is often central to an organisations operations and
key to its growth and development. %n these circumstances, managers will want to
ensure that the development and maintenance of the % investment is carried out in the
most efficient and effective manner and that the resultant systems are fully 0fit for
purpose. Apart from these considerations, many organisations have to satisfy their
customers that their working practices conform to standards such as %6EHH+ and this
will often include the information systems that support these practices.
*s and As &age 3, of ,-
Q# What is the purpose of a Quality *lan? Who should create it?
The *uality &lan essentially defines how the work is to be carried out and it is
complementary to the &ro)ect &lan which is concerned with what is to be done, when
and by whom. The *uality &lan documents the methods and standards that will be
used to perform the work and also to check that it meets its defined quality standards.
The finished plan provides a source of reference for the pro)ect team to tell them how
they should be approaching their work. The *uality &lan should be created by the
pro)ect manager and provides him or her with an opportunity to really think through
what methods are most appropriate to this particular pro)ect.
Q- )o you agree with what )ick @randon said about se( in section 1-.1$? )o not take
this <uestion too seriouslyF
Although the quotation had a humorous intent, it does highlight a serious issue. 6ne
of the biggest problems that beset people trying to maintain and enhance systems $
not to mention their initial development $ is a lack of enough detailed documentation.
Although one can inspect a code listing and find out what a program does, that is very
far from knowing why it works that way and what were the underlying business rules.
#ith very old systems, it can become a case of 0one step forwards, two steps back
because the whole underlying design concept has been totally lost due to a failure to
keep documentation up to date. 6n a more prosaic level, failing to keep the
configuration records of documents up to date can waste enormous amounts of time as
people do a lot of work only to discover that they have been working with a
superseded version.
Chapter ") 2is( management
Q1 Why is the use of risk management techni<ues becoming increasingly important in 12
pro"ects?
% pro)ects $ like pro)ects in many other disciplines $ are becoming increasingly
comple(, with new technologies, demanding business goals and multi<party
contractual arrangements. As comple(ity increases, so does risk and the need to
manage it in a more formal and structured way. %n addition to this, for pro)ects
undertaken by e(ternal suppliers, there has been a gradual movement towards fi(ed<
price contracting, which tends to shift the risk from the customer onto the supplier and
therefore causes the supplier to take risk much more seriously.
Q )escribe a five0stage process for pro"ect risk management.
The main stages in pro)ect risk management are=
&lan the approach= Here, an approach is defined that is appropriate for the
particular pro)ect and which will give adequate control over pro)ect risk. The
approach is documented in the >isk Management &lan 5if there is a separate
document7 or as part of the &ro)ect or *uality &lan.
%dentify risks= The likely risks are identified using peoples e(perience, debriefs
from other pro)ects and checklists. The risks are documented in the risk register
5risk log7.
Assess risks= 2ach risk is assessed in terms of its likelihood, scale of impact and
urgency. The assessments are added to the risk register.
&lan risk responses= Actions are identified to reduce the probability of the risk
occurring and:or to soften its impact if it does. An owner is assigned to take
charge of the actions. The planned responses are recorded in the risk register.
'arry out risk reduction= Hopefully, the risk actions will have dealt with the
problems but the risk register must also be reviewed regularly to check that the
actions have been successful and to identify any new or changed risks. 1ew risks
are sub)ected to the same management process as described above.
Q# 'hree factors that need to be assessed when considering risks are likelihood% impact
and urgency. 4(plain what is meant by each of these terms and show how each might be
assessed.
Kikelihood refers to the probability of the risk occurring. %t can be e(pressed in
percentage terms or, more practically, as either high, medium or low.
%mpact 5strictly, scale of impact7 refers to the si4e of the 0hit the pro)ect would take if
the risk occurred. %t can be assessed numerically 5for e(ample, a +HI increase in cost
or timescale7 or as either large, moderate or small.
Frgency has two aspects, referring to the time when the risk will occur 5if it does7 and
the 0window of opportunity available to deal with it. Frgency can be e(pressed in
time terms 5one month, for e(ample7 or simply as 0very urgent, 0urgent, 0less
urgent.
Q- 8isk actions are of two typesA avoidance actions and mitigation actions. )escribe the
relationship between these types of risk action and where each might be employed.
Avoidance actions are designed to reduce the likelihood of a risk occurring, ideally
reducing its probability to 4ero by eliminating it.
Mitigation actions are designed to reduce the impact of the risk if it occurs, sometimes
by identifying contingency plans that can be activated. A special form of mitigation is
risk transfer whereby the impact is made to fall on someone else, as is the case with
an insurance policy.
%n practice, both types of risk action are usually required as, even if avoidance actions
are available 5which sometimes they are not7, they may fail and a fallback response is
required.
%t is also worth considering that, if the costs of avoidance or mitigation are higher than
that of the perceived risk impact, a perfectly rational response may be to accept the
risk.
Q3 )escribe the characteristics needed in a risk owner.
To be effective in their role, a risk owner needs=
ufficient information about and understanding of the risk
The resources to do something about it
The authority to take the required action.
*s and As &age 3- of ,-
Chapter "* 3alue engineering and +alue management
Q1 4(plain the difference between value management and value engineering.
Balue engineering is concerned with finding the cheapest method of achieving a
previously agreed ob)ective. Balue management is broader and also encompasses
trying to get an agreed value for the ob)ectives themselves.
Q What is meant by the term value tree?
A value tree progressively decomposes the overall goals of a pro)ect into more
specific ob)ectives that can be agreed by the pro)ects stakeholders. These more
detailed ob)ectives can then be used to identify and assess possible system solutions.
Q# 5ow can value management be used to compare different possible design solutions?
6nce the bottom<level ob)ectives for a pro)ect have been identified through such
techniques as a value tree 5see above7, each can be assigned a value, perhaps on a
scale from + to +H. The probable effectiveness of the possible solutions in achieving
these ob)ectives can then be assessed and summed to find out which solution offers
the greatest value.
Q- ;nce a pro"ect is under way% how can value management be used to evaluate proposed
changes?
#hen potential changes to a pro)ect have been identified, value management can be
used to assess the business benefit that implementing them would create and to
compare this benefit with the costs of making the change. Thus, value management
can supplement conventional approaches to change control.
Chapter ", Selling the project
Q1 5ow would you assess the importance of sales skills to a pro"ect manager? Are they% in
your view% increasing or decreasing in importance? Why do you think there is this change?
1s it more important to understand selling or buying?
6pportunities arise all of the time for pro)ect managers to 0sell. This might be
winning some new business for which the client will pay $ with 0real money or with
an internal cross charge to the % department. %t might not be new business at all but
the constant sale of customer satisfaction throughout the pro)ect. #hichever it is, its
valuable. To put it in perspective however, its not the pro)ect managers main task!
being a good salesman but a poor deliverer 0on time, on budget and to quality is not a
good solution.
;eing able to take a commercial view is increasingly important. elling is part of this.
Technology is increasingly taken for granted and the ability to sell solutions often
distinguishes good from average performance.
elling versus buying" These are the two faces of the commercial coin. %t is not
realistic to e(pect to sell unless you know why and how people buy.
*s and As &age 3@ of ,-
Q *ersuading someone to buy is a comple( process. Why is this? 1s the process inherently
comple(% or is it because so many people are involved?
&ersuading is an influencing skill where you seek to get someone to agree with your
proposition by demonstrating that it is what is needed. %t is comple( because there is
never usually )ust one buyer. Typically a buying decision for something as significant
as a systems pro)ect will involve finance people, technical authorities, the ultimate
user and the pro)ect sponsor. A stakeholder analysis will probably show that there
are more stakeholders, but they may not be involved in the purchase decision.
The process is comple( and it involves many people.
Q# 1f selling is an .asking process/% how could you use it to help you sell some e(tra
functionality to a system under development?
%f we use the buying cycle as a guide, wed be asking questions about whether or not
the proposed pro)ect $ without the e(tra functionality $ meets all the needs. %s
everyone satisfied" #as the original functionality a safe option that we could now
improve, now that it is seen more clearly" 'an the unsatisfied people articulate the
implications of not getting this e(tra functionality"
%n short wed ask about
The situation $ no e(tra functionality
The problems $ if nothing is done
The implications of not getting the e(tra functionality
The payoff or benefit from doing it, from meeting this new need.
Chapter "- Managing sta(eholders
Q1 2takeholders have different interests or .stakes/ in a pro"ect. 5ow can you
determine where to put your management effort?
%deally, all stakeholders will have closely similar criteria for )udging the success of the
pro)ect, but this wont always be the case. To identify where to put stakeholder
management effort you should
%dentify stakeholders
.iscover their criteria for success
Analyse stakeholders ability to affect the pro)ect according to their power and
influence
Assign effort first to those with the most power and influence.
Q What is meant by the term managing e(pectations? Why is e(pectation management
an important part of the pro"ect manager/s "ob? What influences a customer/s
e(pectations?
#e all have different e(pectations about the outcomes of a pro)ect or a change at
work. ome are very personal and secret $ M% want to get a desk by the window and a
new &'N, whereas some are business related $ M% want to be able to satisfy customer
*s and As &age 3A of ,-
queries in full over the phoneN. The declared e(pectations will all be business related
or have some non<personal aspect to them. Managing e(pectations means managing
theses declared e(pectations towards the goals of the pro)ect and trying to ensure that
your most powerful stakeholders get their personal e(pectations met as well.
Q#Why is it important for the pro"ect manager to establish a network of contacts within the
12 organisation and also within the user organisation? 1n what circumstances can these
networks be useful?
1etworking is the skill of knowing and building rapport with people who can help you in the
management of your pro)ect but who are not part of the pro)ect team. Traditional
management hierarchies are gradually disappearing and in flatter, decentralised organisations
it helps to know different people in different departments who can give you alternative views
and information, and bring influence to bear on your behalf. /oud certainly want to make
sure that you had connections into all of the stakeholder groups and into 9inance and H> if
they were not identified as stakeholders.
+hapter 1G >anaging suppliers
Q1 )escribe three situations in which an 12 pro"ect may need or wish to use
subcontractors.
>easons for using subcontractors include=
Kack of skills or resources= The organisation may not possess the necessary skills
or may not have enough people with these skills, especially if it is undertaking a
lot of pro)ects at the same time.
&ressure to reduce headcount= %t may be more 0politically acceptable to have the
work done e(ternally $ even at increased cost $ than to retain people on the
permanent establishment.
>elative costs= ometimes, a subcontractor may be able to offer economies of
scale and hence lower costs than with an in<house team. A very contemporary
manifestation of this is to 0offshore work to places such as %ndia where highly<
trained personnel are employed at much lower rates than are the norm in 2urope.
pecialised skills required= The pro)ect may call for very specialist skills indeed
and these may only be available from specific organisations.
>isk transfer= The organisation may wish to transfer some or all of the risk
5technical or commercial7 to another party.
Q 1t is important that the contracts between the main contractor and the customer and
between the main contractor and subcontractors are back0to0backB what is meant by this
term?
The phrase 0back to back means that any contract terms applied to the prime
contractor are 0flowed down to subcontractors. This is important as, otherwise, the
main contractor may find themselves liable for things that they have entrusted to
others, with no legal redress for their subcontractors failings.
*s and As &age 3D of ,-
Q# 2ubcontracts often include penalty clauses to give the main contractor protection in the
case of the supplier/s poor performance. Why are penalty clauses not the complete answer
to safeguarding the main contractor/s position?
&enalty clauses only provide for monetary compensation to be paid in certain
specified circumstances. Apart from the difficulty of enforcing penalty clauses, they
seldom provide complete recompense for all the consequences of a suppliers failure $
like business loss or public damaged as the result of late delivery or poor performance
of a system.
Q- )escribe four methods that can be used to monitor supplier performance.
Methods include=
Approval of designs= The organisation studies, comments on and finally approves
designs, specifications, drawings and so on.
&rogress meetings= These should be regular and:or tied to the completion of
significant deliverables.
#itnessing tests= To check that subcontracted products meet their design
specifications.
>eceipt of goods= 9ormally checking goods received to ensure that they are what
was ordered, in the right quantity and quality.
'hecking invoices= To ensure that they are in accordance with contracts and
purchase orders and that the goods or services invoiced for have been provided.
>isk management= 'hecking on how the subcontractor manages risk and
assessing any risks that could impact on the organisation or main contractor.
Managing the customer interface= 2nsuring that customers only talk to
subcontractors through the organisation or main contractor.
Q3 4(plain how <uality control can be applied to a subcontractor/s work.
*uality control of a subcontractors work starts with a clear, detailed and precise
specification of the goods required or the services to be performed. .etailed
acceptance criteria should also be agreed between the parties.
Two basic approaches to quality control can be used=
The 0black bo( approach where the inputs and outputs from the product are
checked to ensure that they conform to specifications! if they do, the buyer is not
concerned with how the product works.
The 0white bo( approach where not only inputs and outputs are checked but also
what goes on within.
%n addition, the buyer may wish to see that the subcontractor works within and
conforms to some independent standard for quality management systems, such as
%6EHH+.
Chapter #0 4eadership
*s and As &age 3E of ,-
Q1 8efer back to the introduction and consider again the leadership challenge at the end
of the section. What kind of pro"ect management would you need to deliver to have people
volunteer to work on your pro"ects?
The leadership challenge is to assume that everyone working on your pro)ect is there
because they want to be. OOOOthey are volunteers.
There are four things that followers demand of their leaders. These are
Honesty $ they must act with integrity at all times
'ompetence $ they can do the )ob
Bision $ goals and ob)ectives are clear to everyone
%nspiration $ there is enthusiasm and passion for the )ob
To this we might add that the pro)ect manager maintains team spirit, considers
individual needs and sets high performance standards. Kife is a challenge and its fun.
Q 5ow can >aslow and 5erHberg theories of motivation help you to organise your
pro"ect team and the way work is allocated?
#e should assume that working in an % pro)ect team meets the first two levels of
need in Maslows hierarchy $ physiological and safety:security needs. ;y his or her
own actions, the pro)ect manager can address needs for
ocial interaction< is everyone part of the team. 1o one is left out.
tatus and recognition $ people are rewarded for their achievements, even if it
is a simple public 0thankyou"
Achievement and challenging )ob < team members are pushed to develop and
achieve greater and greater things.
Her4berg found that the things that motivated people were achievement, recognition,
the kind of work people were given, their responsibility and advancement. These are
all in the pro)ects managers gift. There is the opportunity to structure the work given
to team members to take advantage of the motivating forces in us all.
Q- 'hink of a situation at home% at work% at university or in a club to which you belong. 1t

is a situation that involves you. !ou want to change the present circumstances and set a
new basis for the future. Ising the behavioural commitments at the end of section 1J.-%
what could you do to change things?
'learly there isnt an 0answer to this question as the situation chosen determines what
youd actually do, but there are some general steps that you could follow=
'reate a climate for change. %s there a 0burning platform $ a situation that is
so bad that people want to move from it" 6r do you need to 0challenge the
*s and As &age ,H of ,-
process by constantly seeking out and proposing opportunities for
improvement"
'reate a vision for the future that you and everyone can share
2ncourage others to work together towards the new situation
how everyone what things could be like through the way you behave
'elebrate the successes $ big and small $ along the way.
Chapter #" Performance management
Q1 !ou are dissatisfied with the general level of performance of one of your team. 'he
<uality of work is below your e(pectations. 5ow will you deal with this?
/ou could take the following approach but remember that performance issues are
usually more comple( than a simple checklist might suggest.
Are your e(pectations about the quality of work clear and well understood by
this team member" %s s:he new to the team"
Are there reasons that you know about that might be influencing the level of
performance" Home, family, travel issues or unfamiliarity with the kind of
work. %s it a question of competence or commitment"
This is a problem solving or coaching opportunity and not a disciplinary
situation.
Having prepared, establish with the individual the level of performance
e(pected, and the gap between the e(pected and actual performance.
2(plore the reasons for the gap. Jet the individuals point of view first.
Agree actions to eliminate the gap.
ummarise with precision. 9i( a follow<up review.
Q A member of your team e(hibits disruptive behaviour. 5er work is good but she is not a
team player. 'he conse<uences are that she does not contribute to team effort and her
colleagues find her difficult to work withB the pro"ect team secretary has refused to work
with her at all. 5ow could this serious problem have arisen? What can be done now?
This has been allowed to go on too long and is now a real drag on pro)ect
performance. Two things need to be addressed immediately. 9irstly, it is not
acceptable for the pro)ect team secretary to refuse to work with her. /ou need to be
quite clear, in private, that this must stop. .ont get into a disciplinary frame of mind
however! you could usefully follow the process suggested for question +.
econdly, the disruptive team member needs to understand that the disruptive
behaviour that you have seen is unacceptable. The process already described could be
followed.
*s and As &age ,+ of ,-
There are two further points.
%s the 0disruptive person really disruptive or does she )ust work differently"
%s her preferred team role one that makes others uncomfortable with her" %s
she being made the scapegoat for other peoples discomfort"
Are you giving clear leadership, being open and encouraging openness with
others"
Q# )escribe the process of setting ob"ectives. What might be three ob"ectives for a newly
appointed "unior programmer?
A hierarchy of ob)ectives cascades down from the overall aim of the pro)ect down to
the ob)ectives for individual work packages.
They are agreed between the setter and the receiver of the ob)ectives and may be
sub)ect to negotiation.
>efer back to the use of MA>T ob)ectives.
9or a newly appointed )unior programmer they may include work that
>equires use of the competences s:he already has
%ncludes a measure of challenge 5this is where your e(pectations should be
made clear7
6ffers the opportunity to develop and for the achievement of this development
to be recognised and recorded.
Chapter ## Project teams
Q1 *repare an interview plan for the post of @usiness Analyst in your team.
+. #elcome:introductions:administrative things:agenda. 2stablish rapport.
3. 6pen questions about education and training received. &robe business
analysis qualifications $ sub)ects covered and level.
,. 6pen questions about previous )obs. How much was business analysis and
how much systems analysis. >easons for leaving.
8. 6pen questions about interests, personal circumstances.
-. 6ur company, the %:%T function, our )ob, our e(pectations, and challenges.
@. Anything youd like to ask me" Anything youd like to add"
A. #hat happens ne(t.
D. Thank you and goodbye.
Q When you first assemble your pro"ect team% what can you do to build team spirit? What
behaviours are the different individuals likely to e(hibit during this team0building process?
5ow do you demonstrate your leadership?
*s and As &age ,3 of ,-
ome team development activity is valuable. %t doesnt have to be building rafts out
of planks and string and getting wetL There are three aims.
9or people to get to know each other in a work conte(t and understand their
impact on each other
To establish some preliminary work processes and standards to get the team
started
9or everyone to understand the overall aims and ob)ectives of the pro)ect and
for the pro)ect manager to set his:her e(pectations, set the vision and set out
how the team will be managed.
>egular team meetings will emphasise your commitment to the team and enable you
to deal with team development issues as they arise.
Chapter #% Managing the project climate
Q1 +onsider a pro"ect manager with a team of 13 to $ peopleA a mi(ture of analysts%
designers% programmers and support staff. 'he pro"ect also uses some specialist staff on a
part0time basis. 5ow could the pro"ect manager influence the working environment of such
a team so as to get the best out of them?
This is a disparate pro)ect team made more comple( to manage by the use of part<time
specialists. The si4e of the team means that there will probably be three or four teams
in the pro)ect each managed by a team leader. This effectively creates a 0management
team for the pro)ect. The pro)ect manager will concentrate on making sure that the
teams are managed in a consistent and collaborative way.
The overall team is small enough for the pro)ect manager to know everyone and to be
encouraging and supportive or, when needed, firm and critical about work
performance.
The climate is established by the pro)ect managers own leadership and by modelling
the way in which people are e(pected to behave. A useful model is the Keadership
'hallenge model.
Q +onflict and stress arise naturally in 12 pro"ect teams. 2ome people argue that a little
of both is useful% but everyone agrees that too much is destructive. 5ow could you organise
your pro"ect team to minimise the destructive effect of conflict and stress?
&ro)ect teams dont run without some level of conflict and stress. .eveloping new
systems is a creative process that needs new ideas. 9rom time to time it may however
get out of hand. To resolve it, you need to give those involved the chance to present
their case without interruption before e(ploring the matter further yourself. %f the
conflicting parties cant then agree on a solution, you have to decide the issue
yourself.
*s and As &age ,, of ,-
/ou need to consider the circumstances that generated the conflict in the first place.
.o they include inbuilt confusion that will continue to generate conflict, or clearly
unfair or now outdated working practices"
1either can stress be eliminated entirely. 6ften a stressful pro)ect delivery can be
energising and e(citing with e(tra hours and weekend working accepted by everyone.
There is a limit to this however and at least one day a week should be work free.
ome stress relief activities can be organised on a team basis. 6n an individual basis,
take care not to let stress reduce performance. &rovide help to reduce it and get help
to enable the individual to manage it. Above all, dont take on other peoples stress
yourself. %f really big stress issues arise, get help from e(perts. %t is not acceptable
for organisations to deliberately ignore workplace stress or for people to be so
pressured that they fall ill.
9inally, take care not be a source of stress yourself. etting challenging ob)ectives is
fine! constantly interfering and harrying the team is notL
Chapter #' &he project manager
Q1 5ow does the .vision of the pro"ect manager/ in this chapter relate to the way you see
the "ob? Are there aspects of the "ob that do not appear in the vision? Why might that be?
The vision statement was written to define the feel of the )ob in a way that lets pro)ect
managers know what is e(pected of them in a qualitative way. %ts not a )ob
description view. %t is not a pedestrian step<by<step approach to the )ob. %t tries to
communicate the emotion of the )ob. %t is very personal.
The things missing are all related to the conte(t within which the )ob is done. %s it a
FP )ob, and American )ob, an international )ob, a 2uropean )ob $ it doesnt say.
%t does however imply a good deal about the culture within which the )ob e(ists. %t is
goal orientated, requiring personal commitment and risk. %t talks about challenge and
shaping events and winning through. %t is to some e(tent an heroic view of the pro)ect
manager and this tells something of the organisation for which the vision was created
and its view of the kind of pro)ect managers they wanted.
%t is neither everyones view of the pro)ect manager nor every organisations view but
it does illustrate how the spirit of the )ob can be captured in an unconventional way
and communicate the enthusiasm of pro)ect management.
Q +onsider the skills and <ualities of pro"ect managers described in the .developmental
approach/. +an you add to these? 5ow far do you see yourself being proficient in these
skills? 5ow could you develop further?
This is another question without an 0answer. /ou have to work it out for your self
and for your conte(t. The self<management dimension may, for e(ample, not always
*s and As &age ,8 of ,-
require the 0innovative risk taking component. %n the +=+ interactions, managing
client relations may not be part of the )ob where you work.
#hat the developmental approach offers is a template for you to assess your type of
pro)ect management and an opportunity to measure yourself against it.
*s and As &age ,- of ,-

BB

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BB

Încărcat de

Drepturi de autor:

Formate disponibile

Project Management for Information Systems

by James Cadle and Donald Yeates

Q- 'hink of a situation at home% at work% at university or in a club to which you belong. 1t

S-ar putea să vă placă și