From Geostandards

Contents 1 Proof of Concept and Action Plan 1.1 Requirements 1.2 Details 1.3 Failure factors

Proof of Concept and Action Plan

Proof of Concept (PoC)

The advisor from the bureau Xpert is asked to design a plan for the implementation of SOA in the IngClub and to include a more detailed budget of the costs. After some time the Xpert advisor draws up an Action Plan which consists of three steps:

1.Work out a Schedule of Requirements in detail and create solutions for them. 2. Set up a pilot project to illustrate how the designs meet the requirements. It is the intention that the software designers should modify their design after feedback from the pilot project while, at the same time, the users are given the opportunity to change their wishes. This is an iterative process, with a limited amount of space for feedback and a limited amount of time. 3. If the MT is happy with the results from the pilot project, the real implementation process in the organisation can begin. That is the next stage. In order to arrive at this stage, the MT of IngClub has to take a GO / NO GO decision.

The steps are given in the figure below.

PILOT PROJECT contains a number of components: The people working in the organisation hear about the pilot project that has been created to implement the SOA, they also receive a description of the goal, the method of work being used and a list of people that each department and the board can liaise with. This is important for the basis of the project. In the pilot project, the working process of a carefully selected representative case is imitated. Working through this case should reveal the symptoms of the problems that were signalled before. In this way it can be shown whether or not these same problems occur in the pilot project. Any bottlenecks might also occur that were not mentioned or even thought of before. Specific software is recommended. The choice should be based on a reasoned consideration of all the aspects of a functional, financial, and management nature, and should include the knowledge level of the users. The time required to construct the application(s) must also be considered. A 'Quick and Dirty' prototype of the SOA production environment is made using the selected software. The selected case can then be tested and random questions can be asked by the employees. This prototype will be removed when the pilot project is disassembled.

Action Plan (AP) and Budget

Xpert then draws up a plan of the most beneficial order for the technical applications to be applied, and moderates this with any organisational, personnel and training requirements which are ongoing at the time. This creates a tight schedule, subdivided into a number of stages. This is then combined with a budget of the expected cost of each part of the implementation and a plan of how this budget can be spread over time.

The first version of the AP will be send to the Internal Project Manager a week before he is due to report to the MT.

Reporting to the MT

The Project Manager keeps track of what is happening in the pilot project; the choice of software and the cost of the construction of the application are his responsibility. The Project Manager feeds back any information about these concerns to the MT when the project period is over. Based on this, the MT decides: adapt one part, stop (NO GO) or carry on (GO) the implementation in the production environment.

Extra budget needed

The presentation of Xpert has convinced the MT who gives it a GO vote. However the costs that Xpert has budgeted for are in excess of budget that the MT has. The Representative of the Board of the MT, the Financial Director, and the Chair of the Board, succeed in modifying the budget for the SOA project. The decisive arguments which were used are:

• Internal: the importance of SOA going beyond the departments due to the collaboration between departments. SOA has to lead to a decrease in the number of difficulties.
• External: the introduction of SOA makes the processing of incoming files easier and also simplifies the production process for clients.

Conditions

The Board agrees that extra financial lee-way should be created, under the following conditions:

• Well structured ‘phasing in’ (a sequence of modifications based on dependency, give the employees time to deal with it);
• Keep monitoring how the improvements work out; for example, using the pilot case as reference material;
• Formulate criteria (this should be discussed with Xpert) in order to be able to decide if the project to implement SOA could better be stopped, based on monitoring results, as the improvements predicted are not being achieved in the working processes.

GO

Because of this larger budget, the MT of the IngClub can give Xpert the task of implementing the SOA.

Requirements

The following requirement must be met for the Proof of Concept and Action Plan to be successful:

• Management, ICT and all departments involved have to collaborate.

Details

The following details are important for the success of the Proof of Concept and Action Plan:

• The Management and others involved have to be convinced of the value of SOA;
• Completing and changing software tools have to be taken into account;
• Adapting datasets and databases has to be considered;
• Modifying the organisation has to be taken into account;
• Replacing and training the entire personnel group has to be taken into account.

Failure factors

The following factors will impact negatively on the Proof of Concept and the Action Plan:

• Requirements and scope are not set;
• The reproduction of the business process is not realistic enough in the PoC;
• The form and content of the PoC’s final presentation are not fine-tuned with the field of knowledge and the sphere of interests of the public in mind;
• There is no representative of the ICT department in the higher levels of management in the organisation;
• The economic value of the suggested modifications is not made visible;
• If the speed that the PoC is produced is not fast enough, then it does not stimulate;
• Dependency on providers of commercial software to adapt their software;
• Expectations of the concept are too high (= the broad technical development);
• Too little attention is paid to the human factors (control, creativity, social);
• No greater priority is given to the core applications over the satellite ones;
• No risk assessment is made;
• No measurements to limit risks are thought of.

← previous

Proof of Concept and Action Plan

next →