Figure CDefine target domain

We have already suggested above that EM has a model where an IS development project is seen as an adaptation or re-engineering of an existing information system (and its embedded computer system where relevant). In the terminology employed by EM, the part of the business process that is to be changed is called the target domain and, as the first task in the acquisition process this needs to be carefully delineated. One outcome of this could be the identification of a number of more manageable sub-domains.

Figure C.5 Acquisition goat definition. Refine definition of acquisition goals.

Deciding which parts of the current business are to be re-engineered might well lead to a better definition of what precisely the customer hopes to achieve and what systems they need to acquire.

Cost benefit analysis and stakeholder analysis

The refined definition of the acquisition goals can be used to estimate what the practical benefits and cost of the final system are likely to be and to pinpoint all those who are likely to be affected by the proposed changes.

The main steps in acquisition planning are listed in Figure C.6.

C.5 Acquisition planning

Identify plan scenarios

The information gathered above will be used for acquisition planning. To a certain extent, this can go on in parallel with the goal definition. F;or example, consideration of what is involved in obtaining the components of the projected information system will give a belter idea of its costs. In the light of this, it might be decided that the projected information system is not in fact financially viable. The requirements gathered by the acquisition goal definition can now be broken dow n into packages and the best order for the delivery' of those packages can be judged. These details are called in KM terminology a plan scenario. This process is rather like Gilb's Incremental Delivery Plan in relation to intentional incremental delivery. As in that case, the order in which increments have to be delivered will be driven initially by technical constraints - for example, hardware might have to be installed before software can be loaded. Once these technical considerations have been satisfied, then customer preferences about which parts of the system should be delivered first can be taken into account.

Acquisition planning

Acquisition planning

Figure C.6 Acquisition planning. Analyse risks

Hav ing produced one or more plan scenarios, these can be examined to see what risks they might involve. The EM approach to risk analysis and management is explored in greater detail in the section on adaptation planning. Needless to say, this risk analysis is a major influence on the acquisition strategy to be adopted.

The risks that are detected can be countered in a number of ways. One way is for the source of the risk to be removed. It could be. for example, that one risk deriv es from the lack of experience of the IS dev elopers in a particular technology. This risk could be removed by using a technology w ith which they were familiar. Another way this particular risk could be overcome might be to contract work out to an organization that did have the required skills.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment