Project Management for Information Systems
by James Cadle and Donald Yeates
Chapter 1 Managing change
Q1 Figure 1.7 shows how bad an implementation can become. Action needs to be taken to prevent this kind of situation. What would you recommend should be done?
This model is about how badly wrong the development and implementation can become, but it applies equally to the imposition of change. The secret lies in preventing this situation from arising by
Q2 You are the project manager for a new management accounting system that will provide monthly profit and loss accounts to a chain of 30 computer dealerships, each of which is franchised to its local owner/manager. They have all done their own accounting before. What change issues would you expect to encounter? Does the fact that they are PC dealerships make any difference? Why might they have joined together in the chain?
Several change issues will arise;
In principle, the fact that they are PC 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 existing systems.
The dealers probably joined 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 adjustments by the franchisees.
Q3 Consider 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? Given 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. Identify your organisation’s culture using these models. Work with others if you can. The culture may be the result of deliberate choice or may have arisen by accident. The key 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. Do 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. You do? Then an Apollo culture may not suit you. The is no inherently ‘good’ or ‘bad’ culture just different ones, so choosing one that suits you is a personal choice that doesn’t come with value judgements attached.
Q4 You 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 book-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. If 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.
Next, make a stakeholder analysis and assess the impact of the new system on the different stakeholders. Involve the stakeholders in planning for implementation and think about getting key ‘change agents’ from the publisher and the book trade to work with you.
Ensure that everyone knows what’s happening and that people are properly trained and supported. Create a forum for the identification and speedy solution of issues.
Chapter 2 Business strategy and information systems
Q1 Why is it important for project managers to understand the strategy of the organisation that uses their services?
It enables the project to be seen in the context of what the business is trying to achieve. It means that links between this system and others under development or in operation can be better understood and managed. It enables the project manager to see how the project delivers value and how further value could come through the identification of new opportunities.
Q2 If you knew about an organisation’s strategy, could you suggest IS applications that would support it? For example, how could a large supermarket chain use information systems for cost reduction, or for a strategy based on differentiation?
Systems 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. Differentiation strategies might call for TQM applications, the launch of new systems in customer care or in symbiotic applications such as personal banking, loans and insurance.
Q3 If you had to develop a strategy for a small software house employing 50 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 size 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. You could take it in stages as follows;
To test the soundness of the strategy you could ask someone else to assess it for
Chapter 3 The business case
Q1 At what point in the project lifecycle should the business case be prepared?
The short answer to this is ‘before any serious work has been done and before major resources are committed to the project’. Many projects are preceded by a feasibility study, the aim of which is to see whether there is a prima facie case for undertaking the project and a business case is often a major output from such a study.
In addition, IS studies often start with some form of requirements analysis and specification. Where 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.
In fact, the business case should be revisited at each stage of a project, to make sure that the project is still on target to achieve the business benefits for which the project has been initiated.
Q2 What should be the role of the project manager in relation to the business case?
Ideally, the project 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 very least, someone with a project management background should be asked to review the business case to make sure that the approach proposed is realistic.
If the project manager has not contributed to the creation of the business case, then one of his or her first jobs after appointment should be examine it and to satisfy themselves that they are happy to take responsibility for the project. If they think that the scope, budget or timescale is unfeasible, they should raise their objections with the project sponsor and endeavour to negotiate a more realistic programme.
Once the project is underway, the project manager needs to keep a watchful eye on the business case to make sure that the way the project is going is not going to compromise the achievement of the benefits outlined in the business case.
Q3 Explain the term ‘cost/benefit analysis’
Cost/benefit analysis is the process of identifying, and as far as possible quantifying, the costs of undertaking a project and contrasting these with the benefits expected to flow from it. For a project to be approved, senior managers will have to be convinced that the benefits outweigh the costs.
Q4 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. Intangible costs or benefits are those where it is not practical to calculate a quantitative value.
In theory, almost anything can be quantified, given enough time and the right resources to do the analysis. For example, ‘improved 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 expert 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. It is generally better, therefore, when dealing with intangible costs and benefits to explain in the business case what they are and to let the decision makers put their own (subjective) value on what they might be worth.
Q5 What is meant by the term ‘benefits realisation’ and why is it important?
Benefits realisation is the process of managing a project – and the post-project operation of, for example, a new information system – so as to maximise the chances of getting the benefits claimed in the business case. All projects should be followed, after a suitable interval, by a post-project review, the main aim of which should be to find out whether the expected benefits have been realised or not.
Chapter 4 The organisational framework
Q1 How many different types of customer may there be for a systems development project? Who are they? What kind of relationship and reporting arrangements should the project manager have with the sponsor?
Depending on the specific project, the ‘customers’ could include some or all of the following:
The sponsor of a project represents the management of the organisation that commissioned it. Thus, she or he is THE customer for the project manager and it is important that they have a good, frank and effective working relationship. The sponsor and project 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 size and timescale of the project; one with a total duration of a month or so will probably require weekly reports but, for a project spanning several months, a monthly reporting cycle may be sufficient.
Q2 Describe the roles of (a) the sponsor and (b) the project manager
(a) The sponsor’s role is to represent the organisation commissioning the project and to make the major business decisions concerning it. The sponsor should approve the original project initiation document and decide on any subsequent changes of scope. The sponsor is also the ‘internal champion’ of the project and may, on occasion, have to ‘knock heads together’ where various users cannot agree on the project’s direction. At the end of the project, it is the sponsor who must accept from the project teams the various deliverables specified.
(b) The project manager is responsible for the day-to-day management of the project within constraints laid down by the sponsor. It is a good idea for the project manager to be given some tolerances within which to operate – for example, a completion deadline of 1st March with permission to delay until 1st April if necessary. Essentially, it is the project manager’s job to ensure that the defined scope of the project is delivered within timescale and budget.
Q3 What are the principal problems of managing projects within a completely functional organisation structure?
The main problems of functional organisations are to do with what may be termed a ‘silo mentality’, whereby people pursue functional, rather than organisational, objectives. In addition, people may have little knowledge of – or interest in – things outside of their functional specialism.
The problem with managing a project in this environment is that, if the project is run from within one function, people from other functions may not cooperate fully with it, or may even work to frustrate it. If the project is cross-functional, the project manager may face interference from line managers in the various functions.
Q4 What are the pros and cons of a ‘pure’ project organisation compared with a project operating within a matrix structure
A ‘pure’ project organisation contains within itself all of the resources needed to complete the project’s objectives. Thus, the project manager has the whole project under his or her direct control. However, the project 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 job for that person. In addition, project team members often suffer from a feeling of insecurity, not knowing what will happen to them at the end of the project. Finally, the project may become somewhat detached from – and possibly resented by – the rest of the organisation.
A project operating within a matrix 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 ‘home’ functions. The main problems with matrix structures stem from people having more than one manager, leading to difficulties in prioritisation of effort and time management.
Q5 In a PRINCE2® project structure there are formal committees, a project board and specific roles. What is your opinion about the value of this kind of arrangement? How do you see it working in large and small projects? Could it be useful for projects outside IT?
The use of established roles within the PRINCE2® environment usually smoothes setting up a project, since people get to understand what is required of, for example, the ‘executive’ on a project board. The project board itself provides an excellent forum for the various stakeholders and customers (see question 1) to come together to make decisions about the project. Part of the design brief for PRINCE2® was to make it suitable for non-IT projects. PRINCE2® has been proven in practice over a large number of large projects.
Smaller projects often have some difficulty with the PRINCE2® approach, since it can feel somewhat bureaucratic and top-heavy in these circumstances. But it is a tailorable approach and, for example, the project board can be reduced to two people executive/senior user and senior supplier) if that seems appropriate. The reporting regime between the project manager and project board can also be streamlined and abbreviated for smaller projects.
Chapter 5 The programme and project support office
Q1 Explain why the concept of PPSO arose in the first place.
The origins of the PPSO lie in the provision of administrative support for project managers, to take care of some of the routine tasks such as writing meeting minutes and updating plans. In time, it was realised that this sort of support was required for all projects and could be most efficiently supplied by having a PPSO that supports a number of projects. This also enables PPSO personnel to develop a good understanding of the basic issues of project management, which can be placed at the disposal of many project managers.
Q2 What are the advantages to an organisation of having a PPSO?
The main advantages to an organisation from having a PPSO include:
Q3 What conflicts are likely to arise between project managers and PPSO staff?
PPSO staff can, if they are not careful – or if they are not properly managed – begin to think that they are actually running projects, rather than acting as a support function. The management of the project remains the responsibility of the project manager.
In addition, in pursuit of consistency, PPSO staff may try to impose on all projects the same ‘one size fits all’ methods and standards, where specific projects require a more tailored approach.
Finally, where senior management ask a PPSO to audit the various projects that they support, the PPSO can come to be seen by project managers as a ‘police force’, rather than as a support organisation.
Q4 What skills are useful when working in PPSO?
The skills that are most useful probably include:
Chapter 6 Development lifecycles and approaches
Q1 You have been asked to take charge of a system development where the customer requires about 50 per cent of the functionality very urgently to meet a business opportunity but where the remaining functions can be delivered over the next few years. Which of the various development lifecycles do you think would be most suitable for this project and why?
Either the incremental or the spiral model would provide a good approach in this situation. With 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. Which 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.
Q2 What would you say are the principal advantages and disadvantages of the sequential approach to system development offered by the waterfall and ‘V’ lifecycle models?
The waterfall approach and its ‘V’ 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 project manager as – in theory at any rate – each stage should be complete and signed off by the project sponsor before proceeding to the next. 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 ‘V’ model has the additional advantage that it shows explicitly the connections between the earlier and later project stages – between requirements specification and user acceptance for example.
The main disadvantages of these approaches are that projects 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. With the linear approaches, changes that arise later in the project are difficult to accommodate as the earlier stages should be revisited to reflect the changes. Finally, 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 example, where a system is needed to meet an unprecedented business situation – this is very far from being the case. Where such uncertainty exists, an evolutionary lifecycle (the spiral) is probably more suitable.
Q3 Some critics have said that the use of structured methods, such as SSADM, increases both delivery time and bureaucracy. Do you think these criticisms are justified and what are the claimed advantages in the use of structured methods?
It is true that structured methods require more work to be done ‘up front’ in a project, 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 ‘traditional’ methods. The upside of this, of course, is that there is greater clarity about what the users want which should (a) reduce the actual work of system construction, since programmers do not have to keep going back to the users with questions and (b) result in a system that better meets the users' 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. Bearing in mind that most of the costs of an information system are incurred after initial delivery, this can be of considerable benefit.
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 extent, the benefits of the structured approach are only apparent to people who have worked in the IS field for some time, especially those involved in maintenance and support.
Structured methods are, nevertheless, open to the charge of bureaucracy. Because everything is documented very thoroughly, projects 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 project 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 CASE (computer-aided software engineering) tool.
Q4 Increasing interest is being taken in the use of rapid application development. Why is this, and are there any dangers associated with the RAD approach?
RAD 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. Often, it is more important to get some sort of solution quickly than the best solution in a couple of years. In addition, the advocates of RAD, for example the DSDM Consortium, contend that, because of the close working relationship between users and developers that is inherent in the RAD approach, the users are more likely to get a system that meets their real needs than with a more conventional approach. Indeed, in recent years, RAD’s proponents have been stressing fitness to purpose over speed of development.
The main dangers associated with RAD are to do with its very speed in that it leaves little time for reflection and, if not managed tightly, less still for documentation. Some critics have described RAD as a ‘licence 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 ‘skewed’ as a result.
Q5 Consider how you would organise your project team for a RAD-type project. What leadership practices would it require from the project leader and what would the team members have to do? How, and at which points, would you involve the users?
RAD 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 example:
A major issue for project leaders in a RAD environment is what may be called ‘expectation management’. The users – and also the developers – must be kept focused on the (limited) objectives of the stage in hand and must also be encouraged to keep to the often-tight timescales for the stage. Users 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 ‘coal-face’ users of the system and the project leader must make sure that the views of both constituencies are considered and managed.
Users must be involved at all stages of a RAD project, from initial definition of requirements – however generalised – through the development of prototypes to the testing of the finished system increments.
Q6 What have RAD and extreme programming got in common? What are the claimed advantages of these approaches?
Both RAD and XP 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 RAD is about the development of entire systems, XP seems more concerned with adding individual features. Both approaches involve developers working closely with users to define the need (by using ‘stories’ in the case of XP, by developing prototypes in RAD) and the advocates of both also stress the need for proper documentation of the results.
Q7 Why are approaches such as the Soft Systems Methodology, the Socio-Technical Approach and Business Process Reengineering relevant to IS project managers?
The development of information systems does not take place in a vacuum and is not solely a technical exercise. Information 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 Soft Systems Methodology takes a holistic view of ‘systems’, regarding a business system (‘human activity system’ in the SSM terminology) as something that takes place within a cultural and structural context. Similarly, the Socio-Technical approach recognises that systems cannot be simply regarded as inanimate things, and offers concepts for placing systems in their human and organisational context. Finally, Business Process Reengineering 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 BPR solutions involve the use of information and communications technology to promote and support these improvements.
Chapter 7 The profile of a project
Q1 What work goes on prior to project start-up?
Before project start-up, work is needed to establish the objectives and scope of the project. It is necessary to establish the dimensions of the ‘triple constraint’ of time, cost and scope/product/quality. Where the development work is to be undertaken by an external supplier, there may also be a process of tendering and negotiating a suitable form of contract for the project.
In addition, the project may be preceded by a feasibility study, which is designed to establish the business case for the project and perhaps to explore alternative methods of meeting the perceived business need.
Q2 Describe the products that typically result from the following project stages: Project Start-up; Analysis of Requirements; Design Integration and Testing.
Typical products include:
Q3 Explain the incremental approach to testing represented by the sequence: unit (module) test; integration test; system test; acceptance test.
With the incremental approach to testing, each unit (module or program) 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 ‘peer review’ approach is used instead.
The integration test seeks to find out whether the modules, when fitted together, operate as expected and interact without problems. The baseline here is provided by the Technical Design and by the Requirements Specification. Integration testing is often the responsibility of a specialist testing team.
In system testing, the developers are checking that the system provides the functionality defined by the users in the Requirements Specification. 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.
Finally, the users are invited to conduct an acceptance test to check that what they have asked for in the Requirements Specification has been provided. Often, the users require help from the business or systems analysts in performing these tests and the project manager may also become involved to manage the process; to ensure, for example, that the users do not introduce into the tests any criteria that were not mentioned in the Requirements Specification.
Sometimes, 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 ‘bugs’ will not have been eliminated before the system testing (that, after all, is the point of it) and too many problems can undermine the users’ confidence in their new system.
Q4 From what product should the acceptance criteria for a project be derived and why?
The acceptance criteria should be derived from the Requirements Specification, which is where the users’ stated needs are documented. The actual acceptance criteria may not necessarily be defined in the Requirements Specification, 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 example, ‘a response time of less than 2 seconds for 90% of transactions’ is a lot more precise than ‘a fast response time’. Since the acceptance criteria are based on the Requirements Specification, this emphasises the importance of that document.
Q5 Why is it important that the project team and the users develop and agree a process model for a project?
Any project 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. It also highlights the important milestones in the project and enables the stakeholders to plan their time so as to be available when they are required.
Chapter 8 Project planning: understanding the work
Q1 Give three reasons why it is essential to plan an IS project in detail before starting work on it.
Only the simplest projects – which probably means one developer working for one user – can get away without having a proper plan of work. Even 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 IS projects, however, are much more complicated than this and, as complexity and the number of stakeholders increases, it becomes more and more important to plan the project in detail. Without having a detailed plan:
It is probably true that, important though a good project plan is, a lot of the value in planning is that it requires the project manager to think through how they want to approach the project and thereby end up with a much clearer idea of the approach they are going to take.
Q2 Ideally, the requirement for an IS project would be specified in some detail before planning begins. If the requirement is not detailed enough, what steps can the project manager take to improve the likelihood of the project’s success?
If the requirements are not specified in enough detail, the project manager may need to make some assumptions in order to get started. If so, these assumptions needed to be clearly documented, preferably in the Project Initiation Document, 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 ‘baseline’ for the project and, should the work later prove more extensive or time-consuming than assumed, the project manager will have a good case for approaching the sponsor for more time, budget or resources to complete it.
Q3 In essence there are two basic ways of breaking down a project into plannable chunks: the use of a work breakdown structure or a product breakdown structure. Contrast the advantages and disadvantages of these approaches.
The work breakdown structure (WBS) concentrates on tasks and the product breakdown structure (PBS) on deliverables from tasks. Both methods are used and, in fact, they can be combined so that, at the top levels, the project is broken down by product and then, once individual products have been identified, a work breakdown is created.
The WBS is the more traditional approach, and is the basis for most of the readily-available project planning software, which makes it easy to adopt and to represent on a computer. The advantage of the PBS 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. In 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.
Q4 What do you understand by the term dependency? How can project dependencies be represented for planning purposes?
Dependency occurs when, for example, task or deliverable ‘A’ must be completed before task or deliverable ‘B can be started. In a complex project, the analysis of dependencies helps to identify streams of work that can be performed in parallel, thus shortening the overall duration of the project. The normal way that dependencies are represented is on a dependency diagram, also known as a network diagram or a PERT chart. Microsoft® Project also shows dependencies on the bar/Gantt chart by vertical connections between task bars but this can get somewhat confusing on a large or complex project.
Q5 Define the terms “product” and “work package” and explain how these are related to each other.
A product is an individual deliverable from a project 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.
Q6 Network diagrams and bar charts have different parts to play in planning a project. 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 project 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 example in analysing the potential effect of slippages and risks on the achievement of the project’s deadlines.
Chapter 9 Project planning: estimating
Q1 Explain three reasons why estimating for IS projects 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:
Q2 The analogy method of estimating is often used to produce broad-brush estimates at the start of a project. Why is this method particularly suited to this application?
Finding an analogous project 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 project when the decision-makers are probable more interested in knowing what ‘ballpark’ they are in, rather than having an exact calculation of costs and timescales.
Q3 The analysis effort and programming methods both rest on the principle of extrapolating the total development effort from detailed estimates of one phase of the project. Describe the approach taken in each of these methods and show in what circumstances each might best be employed.
With the analysis effort method, the stage of the project that forms the basis for the estimates is the analysis of requirements. Estimates for this can be arrived at by considering the stakeholders to be involved, the methods to be used (interviews or workshops for example) 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 complex, moderate or simple. Clearly, this method is most relevant where a Requirements Specification – perhaps received as part of an invitation to tender – is available that gives a good general idea of the programs likely to be needed.
Q4 The Delphi technique aims to achieve a consensus estimate from the efforts of a number of estimators. How is this achieved and what is the advantage of the Delphi technique over, for example, a round-table 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. People may feel forced to defend their estimates – high or low – because to do otherwise would be seen to involve a loss of ‘face’ with respected technical colleagues. The Delphi technique involves asking for estimates from a number of people and then circulating the results anonymously for all to see. Because 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 Delphi 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. Barry Boehm (see earlier) found that a combination of the Delphi technique with well-run workshops tended to produce good results.
Q5 Describe how you would go about estimating for the following supporting project activities and why you would take your chosen approach to each.
Q6 State three factors that could influence the estimates for an IS project and how you would attempt to adjust the estimates for these factors.
Relevant factors include:
Chapter 10 Scheduling and resourcing
Q1 Explain the difference between effort and elapsed time. What is the significance of this difference for project planning purposes?
Effort 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. Elapsed 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 external dependencies are involved. (Creating and correcting an interview report may, for instance, involve half a day’s effort but take two weeks’ elapsed time because the interviewee is slow to review the document and send back corrections.) In planning, estimates usually (and rightly) focus on effort but, when transferring the estimates to the schedules (the dependency network and bar chart), elapsed time also has to be considered. In particular, issues like fixed ‘lead times’ for obtaining equipment have to be taken into account.
Q2 Scheduling a project involves understanding the degree to which project tasks can be partitioned. What is meant by this term and what effect does partitioning have on the scheduling process?
‘Partitioning’ means that a task can be split between more than one person. If, 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 other’s 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 example.
Q3 In long-term project planning, it is wise to assume that staff will be available for project work for less than 100 per cent of the total available time. What factors will reduce staff availability and what adjustments should be made for them?
Staff will be unavailable for project work due to:
The normal way of allowing for this is to schedule people for only four, rather than five, days’ work over the duration of a project. For shorter-term planning, where holidays and training courses are known about, slightly more than four days per week may be planned for.
Q4 What do you understand by the term project milestone? How would you decide how many milestones to show on your project plan?
A milestone is a point at which progress on the project can be measured. To be useful, milestones should be attached to the completion of significant deliverables, such as the acceptance of a Requirements Specification. There need to be sufficient milestones on a project plan to allow for adequate control but not so many that their significance is reduced.
Q5 The PRINCE2® project management method envisages a hierarchy of plans. Describe this hierarchy.
At the top level, there would be a Project Plan that covers the main aspects of the project but at a high level of aggregation. Each project stage should then be the subject of a more detailed Stage Plan. Where different teams are involved in the project, each may have a very detailed Team Plan for its activities.
Where it becomes evident to a manager in a PRINCE2® project that their part of the work is likely to go outside its agreed tolerances, they need to complete an exception report to explain the position and an Exception Plan showing how they propose to adjust the work to deal with the situation. An Exception Plan can exist at any or all of project, stage or team levels and, if approved, takes the place of the relevant Project, Stage or Team Plan.
Chapter 11 Monitoring progress
Q1 How is effort monitored on a project? It is important that the effort to be spent on activities is reassessed on a regular basis – why is this so vital?
Effort is best measured by asking team members to keep timesheets, showing where exactly – on which tasks – work has been done. This is important so that the project manager can keep track of effort and re-evaluate what the final outturn of the project is likely to be. In addition, the effort figures will provide valuable data for people who may be trying to estimate similar projects in the future.
Q2 Staff time is usually the principal cost component of an IS project. Describe five other areas where project costs could arise.
Project costs also arise from:
Q3 Describe three methods than could be used to exercise quality control and explain the advantages and disadvantages of each.
Methods include:
Q4 In what circumstances might you consider increasing the volume and/or frequency of quality control checks? When might you decrease their volume or frequency?
Where a team member is inexperienced, or just unknown, the project manager may increase the volume and/or frequency of quality control checks until they are satisfied that the work is of a sufficient standard. Similarly, checks may be increased where problems have been uncovered with a particular individual or area of work.
Where the existing 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.
Q5 What does the term ‘earned value analysis’ mean? What additional insights into the dynamics of a project is afforded by the use of EVA.
Earned value means, in effect, the proportion of a project’s total planned deliverable that has been produced by a given point. Conventional measurement techniques have tended to concentrate on effort, or other resources, expended, without considering what has been achieved for that expenditure, whereas EVA takes into account both expenditure and achievement.
Q6 Explain these terms: actual cost of work performed (ACWP); budgeted cost of work performed (BCWP); budgeted cost of work scheduled (BCWS).
Chapter 12 Exercising 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 exercising control over a project?
The term ‘triple constraint’ refers to the fact that any project takes place within the envelope of the time it is expected to take, the budget available and some understanding of what has to be delivered, expressed as scope, product or quality.
It is important for a project manager to understand the balance between the three triple constraint elements in her project and this will affect the choices she makes in taking control actions. Would it, for example, 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?
Q2 Your project is behind schedule and you are considering adding extra staff to the team. What would be the potential advantages and disadvantages of this approach?
Provided that the slippage is spotted early enough, adding extra staff may be a feasible strategy as there will be time for them to be trained and become familiar with the project. Otherwise, adding extra people may actually be counterproductive, as training them and/or bringing them up to speed on the project may distract the existing staff from getting on with their work. However, if the slippage is diagnosed as being due to a lack of expertise or experience within the project team, bringing in a few experts may well enable the project to recover.
Q3 In what circumstances might you (a) increase or (b) decrease the amount of supervision given to a team member?
Where a quality problem has been detected in an individual’s work, or where they seem inexperienced or unsure of themselves, it may be advisable for them to be supervised more closely. However, this can prove demoralising to experienced and capable people and the correct approach here may be to give them a lot of latitude to exercise their professional judgement in how they go about their work.
Q4 Changes often bedevil IS projects. What steps are required to ensure that proper change control is exercised on a project?
An effective change control system includes the following steps:
Q5 Explain the difference between change control and configuration management and the relationship between them.
Change control is the management of the scope of a project. Configuration management is the control of the versions of its deliverables and how they fit together. Good configuration management records enable a project manager to assess the extent of the impact of a proposed change, in other words to see which deliverables are likely to be affected and how.
Chapter 13 Reporting progress
Q1 What factors would you consider when deciding on the frequency with which you would report progress to (a) senior IS management, and (b) customer management?
A major factor to consider when deciding the frequency of reporting to anyone is how long the actual project is; obviously, if the project takes only two weeks, a monthly reporting cycle is not going to be of much use!
Assuming a slightly longer project duration, however, then reports ought at the least to be provided at the key milestones, when important deliverables should be finished.
For reports to the customers – internal or external – reports at key milestones may be sufficient. However, the project manager will want to have a regular forum for meeting customer management and raising any issues that have arisen on the project so, if the milestones are a long way apart, perhaps a monthly reporting cycle may be appropriate. For a very fast-moving project, it may be better to have a brief meeting once a week just to concentrate on the main issues.
IS 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 next one.
Q2 What is meant by the term exception reporting? What are the benefits and the disadvantages of this type of reporting?
Exception 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 exception reporting is that it makes for short, succinct reports that focus management’s attention where it should be – on what is going wrong. However, because of this, pure exception 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 about! So, most managers tend to depart from the pure exception format to emphasise the achievements, as well as the problems, of their team.
Q3 What are the benefits to the project manager in providing regular progress reports to the project team members?
People working on a project like to have an understanding of how it’s doing and where what they do fits in to the overall picture. On a large project, in particular, team members can feel ‘buried’ in their own work with little visibility of the ‘big picture’. Also, where bad news – such as delays and technical problems – gets known all too readily on the ‘grapevine’, better news about deliverables successfully achieved or how pleased the clients are with progress often gets overlooked. In 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.
Q4 Explain the following terms used in the PRINCE2® project management method:
Chapter 14 Quality
Q1 How could the quality culture behaviours described in section 14.3 be applied in a hospital?
The total quality management approach and culture are very readily applied to a hospital. In 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. Resources 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.
Q2 Why do you suppose there are an increasing number of organisations concerned with the development of quality practices for IS development?
Information systems often represent considerable expenditure for organisations and this has been coupled with increasing scepticism about the value obtained for the funds spent. At the same time, IS is often central to an organisation’s operations and key to its growth and development. In these circumstances, managers will want to ensure that the development and maintenance of the IS investment is carried out in the most efficient and effective manner and that the resultant systems are fully ‘fit for purpose’. Apart from these considerations, many organisations have to satisfy their customers that their working practices conform to standards such as ISO9001 and this will often include the information systems that support these practices.
Q3 What is the purpose of a Quality Plan? Who should create it?
The Quality Plan essentially defines how the work is to be carried out and it is complementary to the Project Plan which is concerned with what is to be done, when and by whom. The Quality Plan 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 project team to tell them how they should be approaching their work. The Quality Plan should be created by the project manager and provides him or her with an opportunity to really think through what methods are most appropriate to this particular project.
Q4 Do you agree with what Dick Brandon said about sex in section 14.10? Do not take this question too seriously!
Although the quotation had a humorous intent, it does highlight a serious issue. One 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. With very old systems, it can become a case of ‘one 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. On 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 15 Risk management
Q1 Why is the use of risk management techniques becoming increasingly important in IS projects?
IS projects – like projects in many other disciplines – are becoming increasingly complex, with new technologies, demanding business goals and multi-party contractual arrangements. As complexity increases, so does risk and the need to manage it in a more formal and structured way. In addition to this, for projects undertaken by external suppliers, there has been a gradual movement towards fixed-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.
Q2 Describe a five-stage process for project risk management.
The main stages in project risk management are:
Q3 Three factors that need to be assessed when considering risks are likelihood, impact and urgency. Explain what is meant by each of these terms and show how each might be assessed.
Likelihood refers to the probability of the risk occurring. It can be expressed in percentage terms or, more practically, as either high, medium or low.
Impact (strictly, scale of impact) refers to the size of the ‘hit’ the project would take if the risk occurred. It can be assessed numerically (for example, a 10% increase in cost or timescale) or as either large, moderate or small.
Urgency has two aspects, referring to the time when the risk will occur (if it does) and the ‘window of opportunity’ available to deal with it. Urgency can be expressed in time terms (one month, for example) or simply as ‘very urgent’, ‘urgent’, ‘less urgent’.
Q4 Risk actions are of two types: avoidance actions and mitigation actions. Describe 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 zero 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.
In practice, both types of risk action are usually required as, even if avoidance actions are available (which sometimes they are not), they may fail and a fallback response is required.
It 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.
Q5 Describe the characteristics needed in a risk owner.
To be effective in their role, a risk owner needs:
Chapter 16 Value engineering and value management
Q1 Explain the difference between value management and value engineering.
Value engineering is concerned with finding the cheapest method of achieving a previously agreed objective. Value management is broader and also encompasses trying to get an agreed value for the objectives themselves.
Q2 What is meant by the term value tree?
A value tree progressively decomposes the overall goals of a project into more specific objectives that can be agreed by the project’s stakeholders. These more detailed objectives can then be used to identify and assess possible system solutions.
Q3 How can value management be used to compare different possible design solutions?
Once the bottom-level objectives for a project have been identified through such techniques as a value tree (see above), each can be assigned a value, perhaps on a scale from 1 to 10. The probable effectiveness of the possible solutions in achieving these objectives can then be assessed and summed to find out which solution offers the greatest value.
Q4 Once a project is under way, how can value management be used to evaluate proposed changes?
When potential changes to a project 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 17 Selling the project
Q1 How would you assess the importance of sales skills to a project manager? Are they, in your view, increasing or decreasing in importance? Why do you think there is this change? Is it more important to understand selling or buying?
Opportunities arise all of the time for project managers to ‘sell’. This might be winning some new business for which the client will pay – with ‘real’ money or with an internal cross charge to the IS department. It might not be new business at all but the constant sale of customer satisfaction throughout the project. Whichever it is, it’s valuable. To put it in perspective however, it’s not the project manager’s main task; being a good salesman but a poor deliverer ‘on time, on budget and to quality’ is not a good solution.
Being able to take a commercial view is increasingly important. Selling is part of this. Technology is increasingly taken for granted and the ability to sell solutions often distinguishes good from average performance.
Selling versus buying? These are the two faces of the commercial coin. It is not realistic to expect to sell unless you know why and how people buy.
Q2 Persuading someone to buy is a complex process. Why is this? Is the process inherently complex, or is it because so many people are involved?
Persuading is an influencing skill where you seek to get someone to agree with your proposition by demonstrating that it is what is needed. It is complex because there is never usually just one buyer. Typically a buying decision for something as significant as a systems project will involve finance people, technical authorities, the ultimate user and the project 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 complex and it involves many people.
Q3 If selling is an ‘asking process’, how could you use it to help you sell some extra functionality to a system under development?
If we use the buying cycle as a guide, we’d be asking questions about whether or not the proposed project – without the extra functionality – meets all the needs. Is everyone satisfied? Was the original functionality a safe option that we could now improve, now that it is seen more clearly? Can the unsatisfied people articulate the implications of not getting this extra functionality?
In short we’d ask about
Chapter 18 Managing stakeholders
Q1 Stakeholders have different interests or ‘stakes’ in a project. How can you determine where to put your management effort?
Ideally, all stakeholders will have closely similar criteria for judging the success of the project, but this won’t always be the case. To identify where to put stakeholder management effort you should
Q2 What is meant by the term managing expectations? Why is expectation management an important part of the project manager’s job? What influences a customer’s expectations?
We all have different expectations about the outcomes of a project or a change at work. Some are very personal and secret – “I want to get a desk by the window and a new PC”, whereas some are business related – “I want to be able to satisfy customer queries in full over the phone”. The declared expectations will all be business related or have some non-personal aspect to them. Managing expectations means managing theses declared expectations towards the goals of the project and trying to ensure that your most powerful stakeholders get their personal expectations met as well.
Q3 Why is it important for the project manager to establish a network of contacts within the IS organisation and also within the user organisation? In what circumstances can these networks be useful?
Networking is the skill of knowing and building rapport with people who can help you in the management of your project but who are not part of the project 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. You’d certainly want to make sure that you had connections into all of the stakeholder groups and into Finance and HR if they were not identified as stakeholders.
Chapter 19 Managing suppliers
Q1 Describe three situations in which an IS project may need or wish to use subcontractors.
Reasons for using subcontractors include:
Q2 It is important that the contracts between the main contractor and the customer and between the main contractor and subcontractors are back-to-back; what is meant by this term?
The phrase ‘back to back’ means that any contract terms applied to the prime contractor are ‘flowed 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 subcontractor’s failings.
Q3 Subcontracts 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?
Penalty 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 supplier’s failure – like business loss or public damaged as the result of late delivery or poor performance of a system.
Q4 Describe four methods that can be used to monitor supplier performance.
Methods include:
Q5 Explain how quality control can be applied to a subcontractor’s work.
Quality control of a subcontractor’s work starts with a clear, detailed and precise specification of the goods required or the services to be performed. Detailed acceptance criteria should also be agreed between the parties.
Two basic approaches to quality control can be used:
In addition, the buyer may wish to see that the subcontractor works within and conforms to some independent standard for quality management systems, such as ISO9001.
Chapter 20 Leadership
Q1 Refer back to the introduction and consider again the leadership challenge at the end of the section. What kind of project management would you need to deliver to have people volunteer to work on your projects?
The leadership challenge is to assume that everyone working on your project is there because they want to be. …………they are volunteers.
There are four things that followers demand of their leaders. These are
To this we might add that the project manager maintains team spirit, considers individual needs and sets high performance standards. Life is a challenge and it’s fun.
Q2 How can Maslow and Herzberg theories of motivation help you to organise your project team and the way work is allocated?
We should assume that working in an IS project team meets the first two levels of need in Maslow’s hierarchy – physiological and safety/security needs. By his or her own actions, the project manager can address needs for
Herzberg 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 projects manager’s gift. There is the opportunity to structure the work given to team members to take advantage of the motivating forces in us all.
Q4 Think of a situation at home, at work, at university or in a club to which you belong. It is a situation that involves you. You want to change the present circumstances and set a new basis for the future. Using the behavioural commitments at the end of section 18.4, what could you do to change things?
Clearly there isn’t an ‘answer’ to this question as the situation chosen determines what you’d actually do, but there are some general steps that you could follow:
Chapter 21 Performance management
Q1 You are dissatisfied with the general level of performance of one of your team. The quality of work is below your expectations. How will you deal with this?
You could take the following approach but remember that performance issues are usually more complex than a simple checklist might suggest.
Q2 A member of your team exhibits disruptive behaviour. Her work is good but she is not a team player. The consequences are that she does not contribute to team effort and her colleagues find her difficult to work with; the project team secretary has refused to work with her at all. How 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 project performance. Two things need to be addressed immediately. Firstly, it is not acceptable for the project team secretary to refuse to work with her. You need to be quite clear, in private, that this must stop. Don’t get into a disciplinary frame of mind however; you could usefully follow the process suggested for question 1.
Secondly, the disruptive team member needs to understand that the disruptive behaviour that you have seen is unacceptable. The process already described could be followed.
There are two further points.
Q3 Describe the process of setting objectives. What might be three objectives for a newly appointed junior programmer?
A hierarchy of objectives cascades down from the overall aim of the project down to the objectives for individual work packages.
They are agreed between the setter and the receiver of the objectives and may be subject to negotiation.
Refer back to the use of SMART objectives.
For a newly appointed junior programmer they may include work that
Chapter 22 Project teams
Q1 Prepare an interview plan for the post of Business Analyst in your team.
Q2 When you first assemble your project team, what can you do to build team spirit? What behaviours are the different individuals likely to exhibit during this team-building process? How do you demonstrate your leadership?
Some team development activity is valuable. It doesn’t have to be building rafts out of planks and string and getting wet! There are three aims.
Regular team meetings will emphasise your commitment to the team and enable you to deal with team development issues as they arise.
Chapter 23 Managing the project climate
Q1 Consider a project manager with a team of 15 to 20 people: a mixture of analysts, designers, programmers and support staff. The project also uses some specialist staff on a part-time basis. How could the project manager influence the working environment of such a team so as to get the best out of them?
This is a disparate project team made more complex to manage by the use of part-time specialists. The size of the team means that there will probably be three or four teams in the project each managed by a team leader. This effectively creates a ‘management team’ for the project. The project 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 project 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 project manager’s own leadership and by modelling the way in which people are expected to behave. A useful model is the Leadership Challenge model.
Q2 Conflict and stress arise naturally in IS project teams. Some people argue that a little of both is useful, but everyone agrees that too much is destructive. How could you organise your project team to minimise the destructive effect of conflict and stress?
Project teams don’t run without some level of conflict and stress. Developing new systems is a creative process that needs new ideas. From 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 exploring the matter further yourself. If the conflicting parties can’t then agree on a solution, you have to decide the issue yourself.
You need to consider the circumstances that generated the conflict in the first place. Do they include inbuilt confusion that will continue to generate conflict, or clearly unfair or now outdated working practices?
Neither can stress be eliminated entirely. Often a stressful project delivery can be energising and exciting with extra 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.
Some stress relief activities can be organised on a team basis. On an individual basis, take care not to let stress reduce performance. Provide help to reduce it and get help to enable the individual to manage it. Above all, don’t take on other people’s stress yourself. If really big stress issues arise, get help from experts. It is not acceptable for organisations to deliberately ignore workplace stress or for people to be so pressured that they fall ill.
Finally, take care not be a source of stress yourself. Setting challenging objectives is fine; constantly interfering and harrying the team is not!
Chapter 24 The project manager
Q1 How does the ‘vision of the project manager’ in this chapter relate to the way you see the job? Are there aspects of the job that do not appear in the vision? Why might that be?
The vision statement was written to define the feel of the job in a way that lets project managers know what is expected of them in a qualitative way. It’s not a job description view. It is not a pedestrian step-by-step approach to the job. It tries to communicate the emotion of the job. It is very personal.
The things missing are all related to the context within which the job is done. Is it a UK job, and American job, an international job, a European job – it doesn’t say.
It does however imply a good deal about the culture within which the job exists. It is goal orientated, requiring personal commitment and risk. It talks about challenge and shaping events and winning through. It is to some extent an heroic view of the project manager and this tells something of the organisation for which the vision was created and its view of the kind of project managers they wanted.
It is neither everyone’s view of the project manager nor every organisation’s view but it does illustrate how the spirit of the job can be captured in an unconventional way and communicate the enthusiasm of project management.
Q2 Consider the skills and qualities of project managers described in the ‘developmental approach’. Can you add to these? How far do you see yourself being proficient in these skills? How could you develop further?
This is another question without an ‘answer’. You have to work it out for your self and for your context. The self-management dimension may, for example, not always require the ‘innovative risk taking’ component. In the 1:1 interactions, managing client relations may not be part of the job where you work.
What the developmental approach offers is a template for you to assess your type of project management and an opportunity to measure yourself against it.
Source: http://www.booksites.net/download/cadle/student_files/eoc_ans.doc
Web site to visit: http://www.booksites.net
Author of the text: indicated on the source document of the above text
If you are the author of the text above and you not agree to share your knowledge for teaching, research, scholarship (for fair use as indicated in the United States copyrigh low) please send us an e-mail and we will remove your text quickly. Fair use is a limitation and exception to the exclusive right granted by copyright law to the author of a creative work. In United States copyright law, fair use is a doctrine that permits limited use of copyrighted material without acquiring permission from the rights holders. Examples of fair use include commentary, search engines, criticism, news reporting, research, teaching, library archiving and scholarship. It provides for the legal, unlicensed citation or incorporation of copyrighted material in another author's work under a four-factor balancing test. (source: http://en.wikipedia.org/wiki/Fair_use)
The information of medicine and health contained in the site are of a general nature and purpose which is purely informative and for this reason may not replace in any case, the council of a doctor or a qualified entity legally to the profession.
The following texts are the property of their respective authors and we thank them for giving us the opportunity to share for free to students, teachers and users of the Web their texts will used only for illustrative educational and scientific purposes only.
All the information in our site are given for nonprofit educational purposes
The information of medicine and health contained in the site are of a general nature and purpose which is purely informative and for this reason may not replace in any case, the council of a doctor or a qualified entity legally to the profession.
www.riassuntini.com