Project Management For Information Systems by James Cadle and Donald Yeates End of Chapter Questions and Answers Chapter 1 Managing Change

Project Management for Information Systems by James Cadle and Donald Yeates End of chapter Questions and 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?
ns!ers
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 ,-
Project Management for Information Systems by James Cadle and Donald Yeates End of chapter Questions and ns!ers
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 'A 2 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 ,-
Project Management for Information Systems by James Cadle and Donald Yeates End of chapter Questions and
ns!ers
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.
ns!ers
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 ,-
ns!ers
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.

ns!ers
&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 ,-
Project Management for Information Systems by James Cadle and Donald Yeates End of chapter Questions and ns!ers 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 ,-

ns!ers
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 ,-

Project Management For Information Systems by James Cadle and Donald Yeates End of Chapter Questions and Answers Chapter 1 Managing Change

Uploaded by

Copyright:

Available Formats

Project Management For Information Systems by James Cadle and Donald Yeates End of Chapter Questions and Answers Chapter 1 Managing Change

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management For Information Systems by James Cadle and Donald Yeates End of Chapter Questions and Answers Chapter 1 Managing Change

Uploaded by

Copyright:

Available Formats

Project Management for Information Systems by James Cadle and Donald Yeates End of chapter Questions and Chapter

" Managing change

Chapter # $usiness strategy and information systems

Chapter % &he business case

Chapter ' &he organisational frame!or(

Chapter ) &he programme and project support office

Chapter * De+elopment lifecycles and approaches

Chapter , &he profile of a project

Chapter - Project planning. understanding the !or(

Chapter / Project planning. estimating

Chapter "0 Scheduling and resourcing

Chapter "" Monitoring progress

Chapter "# E1ercising control

Chapter "% 2eporting progress

Chapter "' Quality

Chapter ") 2is( management

Chapter ", Selling the project

Chapter "- Managing sta(eholders

Chapter #" Performance management

Chapter ## Project teams

Chapter #% Managing the project climate

Chapter #' &he project manager

You might also like