Application Software Implementation Processes Summary
Blog: Biz-Performance, David Brown
2. Application Software Implementation Processes Processes
|
Model graphic:
|
2.1. Model graphic:
2.2. Objects
|
Objects
|
2.2.1. D010 – Preliminary Assessment
|
|
D010 – Preliminary Assessment
|
|
|
Description/Definition
|
An initial fact-finding study to establish in detail the scope of the project, work required, resource requirements, resource availability, timescale requirements, priorities etc.
|
|
2.2.2. D090 – Implement communications programme
|
|
D090 – Implement communications programme
|
|
|
Description/Definition
|
Undertake the communications activities per plan.
|
|
2.2.3. D100 – Prepare / review / agree design topics, IP descriptions and sign offs.
|
|
D100 – Prepare / review / agree design topics, IP descriptions and sign offs.
|
|
|
Description/Definition
|
Review or create the definitions of topics to be used in structuring the work into discrete logically independent parts. Work will be assigned, executed, controlled, documented, reviewed and signed-off within these divisions.
|
|
2.2.4. D110 – Review technical environment and plan installation
|
|
D110 – Review technical environment and plan installation
|
|
|
Description/Definition
|
Plan in detail the physical installation of the packaged software, additional systems software, hardware, communications equipment, servers, PCs etc. Note that increasingly this task is performed by the vendor.
|
|
2.2.5. D111 – Review technical environment and plan Software installation
|
|
D111 – Review technical environment and plan Software installation
|
|
|
Description/Definition
|
Plan in detail the physical installation of the application software, additional systems software, hardware, communications equipment, servers, PCs etc.
|
|
2.2.6. D115 – Team building and education
|
|
D115 – Team building and education
|
|
|
Description/Definition
|
General workshops and events for the project team may be used to ensure a common commitment to the project’s objectives and approach.
|
|
2.2.7. D120 – Plan, prepare and conduct project team training
|
|
D120 – Plan, prepare and conduct project team training
|
|
|
Description/Definition
|
Normally, team members need training before productive work can commence. Training may also be appropriate for management and other staff working with the project team.
|
|
2.2.8. D130 – Install hardware, communications equipment, system software, and applications software as required for development, implementation and live running.
|
|
D130 – Install hardware, communications equipment, system software, and applications software as required for development, implementation and live running.
|
|
|
Description/Definition
|
Install and commission items required for design, development, implementation and live running. This includes system environment requirements, eg log ons, access security, accounts, budgets etc. With medium systems this is often performed by the vendor.
|
|
2.2.9. D135 – Design and set up backup/recovery provisions (development & test environment)
|
|
D135 – Design and set up backup/recovery provisions (development & test environment)
|
|
|
Description/Definition
|
Ensure the development environment is adequately backed up.
|
|
2.2.10. D136 – Design and set up system security provisions
|
|
D136 – Design and set up system security provisions
|
|
|
Description/Definition
|
Ensure that adequate system security is in place for the development and testing of the system.
|
|
2.2.11. D140 – Define, agree and instigate change control procedures
|
|
D140 – Define, agree and instigate change control procedures
|
|
|
Description/Definition
|
Formal Change Control procedure must be in place and used. The baseline for controlling changes is the definition of requirements. Changes from the defined requirements, must be agreed before becoming firm in the design.
|
|
2.2.12. D150 – Define and instigate Project Team responsibilities and techniques for technical support, bug reporting, fixing, supplier liaison etc.
|
|
D150 – Define and instigate Project Team responsibilities and techniques for technical support, bug reporting, fixing, supplier liaison etc.
|
|
|
Description/Definition
|
During development there is a need for clear responsibilities to be defined for running and supporting the development system. For example, who applies bug fixes? Who runs the batch jobs? Who sets up the security access rights?
|
|
2.2.13. D160 – Consider, review and plan approach to interfacing and systems integration
|
|
D160 – Consider, review and plan approach to interfacing and systems integration
|
|
|
Description/Definition
|
This process looks at the issues which arise out of the desired levels of integration between separate elements of the overall project and with external systems. Plans and approaches will be modified accordingly.
|
|
2.2.14. D167 – Consider and review needs for custom development and modifications
|
|
D167 – Consider and review needs for custom development and modifications
|
|
|
Description/Definition
|
Where gaps in the available functionality have been identified, the use of custom development may be considered. This may involve the use of application software development tools, external report writers or programming languages. Normally such changes increase the costs and risks.
|
|
2.2.15. D170 – Build / maintain data dictionary / data model
|
|
D170 – Build / maintain data dictionary / data model
|
|
|
Description/Definition
|
Build or revise a data model for the system. Normally a formal approach would be used such as ARIS toolset, SSADM or Merise, depending on the organisation’s usual practice.
|
|
2.2.16. D180 – Data Conversion Strategy
|
|
D180 – Data Conversion Strategy
|
|
|
Description/Definition
|
A study should be made into the needs for data conversion. Data availability and integrity is often wrongly assumed during design work. Recommendations will be made for securing data as required.
|
|
2.2.17. D190 – Issues – control, escalate, resolve
|
|
D190 – Issues – control, escalate, resolve
|
|
|
Description/Definition
|
Issues that arise during the design work are noted, logged, controlled and resolved. Escalation and tie-breaking mechanisms are used where necessary.
|
|
2.2.18. D200 – Agree reviewers and sign-off authority / responsibility
|
|
D200 – Agree reviewers and sign-off authority / responsibility
|
|
|
Description/Definition
|
Agree a small, empowered group of authorisers and sign off responsibilities.
|
|
2.2.19. D211 – Plan & prepare prototyping approach
|
|
D211 – Plan & prepare prototyping approach
|
|
|
Description/Definition
|
Agree and set up the procedures and facilities for the iterative prototyping work. Make sure developers will not adversely impact upon the work of others.
|
|
2.2.20. D230 – Focus on delivery of benefits – Cost/Benefit Model
|
|
D230 – Focus on delivery of benefits – Cost/Benefit Model
|
|
|
Description/Definition
|
Throughout the delivery segment, various techniques are used to monitor that the desired business benefits will be delivered and to keep the team’s focus on delivering these benefits. These will include both financial and non-financial aspects.
|
|
2.2.21. D240 – Impose issues control and change control
|
|
D240 – Impose issues control and change control
|
|
|
Description/Definition
|
Issues Control and Change Control procedures must be in place and used. Changes from the defined requirements, must be agreed before becoming firm in the design.
|
|
2.2.22. D300 – Prepare discussion papers
|
|
D300 – Prepare discussion papers
|
|
|
Description/Definition
|
These are short papers covering a particular subject. They are not formally controlled, reviewed or signed off. Their purpose is to assist in the process of deciding an issue during the design work.
|
|
2.2.23. D322 – Define, agree and set up global parameters
|
|
D322 – Define, agree and set up global parameters
|
|
|
Description/Definition
|
Essential global parameters must be configured before the general prototyping work can be undertaken. These will often affect future phases or modules so it is important they are considered in detail for the full defined programme.
|
|
2.2.24. D324 Define, agree and set up Software Organisational Structures
|
|
D324 Define, agree and set up Software Organisational Structures
|
|
|
Description/Definition
|
The software organisation structures should be determined, set up and agreed.
|
|
2.2.25. D354 – Select Business Processes from Reference Model
|
|
D354 – Select Business Processes from Reference Model
|
|
|
Description/Definition
|
Select processes from the application software Reference Model. Examine any business process options which remain outstanding and agree the best practice to be adopted within the capabilities of the application software.
|
|
2.2.26. D364 – Configure initial prototyping model
|
|
D364 – Configure initial prototyping model
|
|
|
Description/Definition
|
Set up essential initial master data, transaction data, periodic data, procedures, reports etc (not organisational structure). Use preconfigured standard solutions where available.
|
|
2.2.27. D383 – Build core testing data for prototyping
|
|
D383 – Build core testing data for prototyping
|
|
|
Description/Definition
|
Build test data scenarios for use during the iterative prototyping process
|
|
2.2.28. D392 – Set up, execute & manage prototyping workshops
|
|
D392 – Set up, execute & manage prototyping workshops
|
|
|
Description/Definition
|
Identify detailed design & policy/procedure issues on differences between the base Application Software package functionality and business processes. Develop recommendations, eg modify the package or procedures, or elevate issue to senior management for policy decision.
|
|
2.2.29. D393 – Manage, control, refresh core data for prototyping
|
|
D393 – Manage, control, refresh core data for prototyping
|
|
|
Description/Definition
|
The test data bed should be proactively managed to ensure consistency during the iterative prototyping stages, to explore new areas and to correct earlier errors.
|
|
2.2.30. D400 – Design / Prototype by topic – Implementation Papers
|
|
D400 – Design / Prototype by topic – Implementation Papers
|
|
|
Description/Definition
|
Design or define each topic using prototyping techniques wherever appropriate, documenting the requirements, options, recommended approach and details in an Implementation Paper per topic.
|
|
2.2.31. D450 – Design/Prototype by topic – Brief Implementation Papers
|
|
D450 – Design/Prototype by topic – Brief Implementation Papers
|
|
|
Description/Definition
|
Design or define each topic within the project, using prototyping techniques wherever appropriate, documenting the recommended approach and details in a Brief Implementation Paper (BIP) per topic.
|
|
2.2.32. D466 – Users present model to client organisation in workshop
|
|
D466 – Users present model to client organisation in workshop
|
|
|
Description/Definition
|
“User” members of the project team present the model to a wider audience of management and users. This builds commitment and understanding, and helps to reinforce the team members’ understanding of both the needs and the prototype solution.
|
|
2.2.33. D471 – Consolidate prototyping results
|
|
D471 – Consolidate prototyping results
|
|
|
Description/Definition
|
Review the findings and conclusions from the iterative prototyping. Consider, in particular, what (if anything) needs to be refined further in future iterations.
|
|
2.2.34. D481 – Resolve outstanding policy issues
|
|
D481 – Resolve outstanding policy issues
|
|
|
Description/Definition
|
Identify outstanding detailed policy / procedure issues. Agree recommendations, eg modify the package or procedures, or elevate issue to senior management for policy decision.
|
|
2.2.35. D488 – Final Gap Analysis
|
|
D488 – Final Gap Analysis
|
|
|
Description/Definition
|
A final analysis of the business solution that evolved during the prototyping process in comparison with the originally stated business needs. Consequences of any shortfall will be analysed and agreed. Any appropriate action will be reviewed and agreed.
|
|
2.2.36. D600 – Create detailed specifications for IT development work
|
|
D600 – Create detailed specifications for IT development work
|
|
|
Description/Definition
|
Define the technical requirements to a sufficient level that they can be used in the detailed design, programming and construction of a component.
|
|
2.2.37. D602 – Finalise interface design
|
|
D602 – Finalise interface design
|
|
|
Description/Definition
|
Finalise the design of components of the interfaces based on specifications of design phase.
|
|
2.2.38. D604 – Finalise data conversion design
|
|
D604 – Finalise data conversion design
|
|
|
Description/Definition
|
Finalise the design of the extraction, validation, translation, control and input systems for data conversion.
|
|
2.2.39. D606 – Finalise design for functional modifications / additions / custom reports
|
|
D606 – Finalise design for functional modifications / additions / custom reports
|
|
|
Description/Definition
|
Finalise the design for functional modifications / additions / custom reports that will be custom developed to supplement the SAP system functionality.
|
|
2.2.40. D650 – Instigate parallel tasks
|
|
D650 – Instigate parallel tasks
|
|
|
Description/Definition
|
Non-software implementation and integration tasks should be instigated as appropriate. Typically these will be undertaken by a separate programming team. Controls may be set in place to monitor progress, to ensure adequate quality and to ensure delivery will be on time and within budget.
|
|
2.2.41. D656 – Build / modify existing application software
|
|
D656 – Build / modify existing application software
|
|
|
Description/Definition
|
Any software development work not based upon the Software Application Basis system is undertaken (but not necessarily by the Software Application project team).
|
|
2.2.42. D658 – Build / modify package software
|
|
D658 – Build / modify package software
|
|
|
Description/Definition
|
Produce and unit test application development tool software components of the system based on specifications. Create interface, new application/ conversion programs, plus modification of existing applications/system software, installation of supplementary software etc.
|
|
2.2.43. D662 – Implement ‘live’ client systems – hardware/software
|
|
D662 – Implement ‘live’ client systems – hardware/software
|
|
|
Description/Definition
|
Set up and test the application software client systems in terms of hardware and software.
|
|
2.2.44. D664 – Implement live communications & network
|
|
D664 – Implement live communications & network
|
|
|
Description/Definition
|
Set up and test the communications facilities: LANs, WANs, communications software etc
|
|
2.2.45. D666 – Implement ‘live’ server systems – hardware / software / database
|
|
D666 – Implement ‘live’ server systems – hardware / software / database
|
|
|
Description/Definition
|
Set up the basic Software Application server systems in terms of hardware, software etc
|
|
2.2.46. D668 – Set up, transport and verify live configuration
|
|
D668 – Set up, transport and verify live configuration
|
|
|
Description/Definition
|
Move the developed and tested Software Application configuration into the live environment. Verify that it has been correctly transported.
|
|
2.2.47. D700 – Set up system parameters, codes, structures, etc
|
|
D700 – Set up system parameters, codes, structures, etc
|
|
|
Description/Definition
|
Each aspect of the system’s basic configuration system should be set up in accordance with the agreed implementation papers. Most basic parameters will have been set during the prototyping. At this stage the full tables are populated.
|
|
2.2.48. D710 – Set up screens, queries & reports etc
|
|
D710 – Set up screens, queries & reports etc
|
|
|
Description/Definition
|
Each agreed optional customisation of the system should be set up in accordance with the agreed implementation papers. Many will have been set during the prototyping. At this stage the full tables are populated.
|
|
2.2.49. D711 – Set up Application screens, queries & report writer etc
|
|
D711 – Set up Application screens, queries & report writer etc
|
|
|
Description/Definition
|
Each agreed optional customisation of the system should be set up in accordance with the agreed implementation papers. Most basic parameters will have been set during the prototyping. At this stage the full tables are populated.
|
|
2.2.50. D720 Prepare and instigate operators’ instructions, procedures and manual
|
|
D720 Prepare and instigate operators’ instructions, procedures and manual
|
|
|
Description/Definition
|
Prepare detailed instructions for the technical operation of the system, including routine and abnormal running, eg security, disaster recovery. This will normally include operational-standard JCL and the definition of human/machine interactions.
|
|
2.2.51. D730 -Identify human and organisational issues
|
|
D730 -Identify human and organisational issues
|
|
|
Description/Definition
|
Assessment of the required change in terms of people and organisation. Identifies peoples’ skills and behaviours, their resistance to the change, lack of skills, willingness and abilities.
|
|
2.2.52. D740 – Implement change management programme
|
|
D740 – Implement change management programme
|
|
|
Description/Definition
|
Prepare and agree a plan for achieving the human and organisational change through communications, publicity, cascade sponsorship, policies, education etc. Instigate and act upon the plan.
|
|
2.2.53. D750 – Prepare and instigate User Procedures and User Manual / electronic information
|
|
D750 – Prepare and instigate User Procedures and User Manual / electronic information
|
|
|
Description/Definition
|
Human procedures should be defined and agreed as part of the functional design work. Manuals or electronic documentation of the procedures and how to use the system should be extracted from the implementation papers and expanded/supplemented as necessary.
|
|
2.2.54. D760 – Plan, prepare and conduct user and management training and education
|
|
D760 – Plan, prepare and conduct user and management training and education
|
|
|
Description/Definition
|
Full user training is vital both to the successful use of the system and also to its acceptance and successful take up. An effective programme should be developed based on the identified training needs of all users and management.
|
|
2.2.55. D770 – Plan, prepare and conduct operations training
|
|
D770 – Plan, prepare and conduct operations training
|
|
|
Description/Definition
|
Computer Operations staff must be trained in running the application. They must be familiar with the normal interactions that are required and what abnormal conditions they might be expected to handle.
|
|
2.2.56. D780 – Plan, prepare and conduct support staff training
|
|
D780 – Plan, prepare and conduct support staff training
|
|
|
Description/Definition
|
Specialised training is required for the staff who will be supporting the system, eg systems control, help desk, etc.
|
|
2.2.57. D784 – Establish testing environment
|
|
D784 – Establish testing environment
|
|
|
Description/Definition
|
Determine, agree and set up the testing infrastructure, eg clients, hardware, user IDs, test data base etc.
|
|
2.2.58. D788 – Set up, transport and verify configuration
|
|
D788 – Set up, transport and verify configuration
|
|
|
Description/Definition
|
Transport the development configuration onto the testing environment and check that it has been correctly set up. Proper change control procedures should be followed for each update.
|
|
2.2.59. D800 – Plan, prepare and conduct User / System / Acceptance and Integration testing
|
|
D800 – Plan, prepare and conduct User / System / Acceptance and Integration testing
|
|
|
Description/Definition
|
Formal testing must be performed to check significant aspects of the system are acceptable. Careful planning and preparation is required to make it complete and comprehensive. Definitions and results must be reviewed and signed off by responsible users.
|
|
2.2.60. D810 – Plan, prepare and conduct technical tuning and volume testing
|
|
D810 – Plan, prepare and conduct technical tuning and volume testing
|
|
|
Description/Definition
|
The system will need technical tuning to ensure acceptable performance. Volume testing ensures that full volumes of data and transactions can be accommodated. Testing should prove that normal loads can be sustained and peak loads can be accommodated.
|
|
2.2.61. D812 – Evaluate testing and report results
|
|
D812 – Evaluate testing and report results
|
|
|
Description/Definition
|
Evaluate, and review the testing results with the key user management. Obtain sign off or agree and schedule further work required.
|
|
2.2.62. D830 – Define, plan and agree handover / cutover
|
|
D830 – Define, plan and agree handover / cutover
|
|
|
Description/Definition
|
An analysis should be made of the logistical requirements for changing over to the new systems. Detailed timings must be considered and agreed.
|
|
2.2.63. D850 – Define and agree terms of reference for live user support activity
|
|
D850 – Define and agree terms of reference for live user support activity
|
|
|
Description/Definition
|
Analyse and agree the requirement and constitution of functional and technical user support for the live system, eg systems control, help desk, scheduling etc.
|
|
2.2.64. D860 – Define live support mechanisms
|
|
D860 – Define live support mechanisms
|
|
|
Description/Definition
|
Dictate responsibilities for support of the live system and liaison points with the vendor.
|
|
2.2.65. D870 – Plan and instigate phased transition to live operation and support / phasing out of Project Team support
|
|
D870 – Plan and instigate phased transition to live operation and support / phasing out of Project Team support
|
|
|
Description/Definition
|
A plan should be agreed and executed to pass control and support of the system from the project team to line departments. This should normally be done in a phased manner so that resistance is managed and there is no sudden change in levels of support.
|
|
2.2.66. D875 – Establish conversion environment
|
|
D875 – Establish conversion environment
|
|
|
Description/Definition
|
Set up the systems environment in which data conversion will take place. Transport and check the conversion software which will be used.
|
|
2.2.67. D880 – Load start up data
|
|
D880 – Load start up data
|
|
|
Description/Definition
|
All initial data should be loaded. Includes running of conversion suites and manual data entry.
|
|
2.2.68. D890 – Validate start up data
|
|
D890 – Validate start up data
|
|
|
Description/Definition
|
Complete loaded data should be validated and signed off by the responsible user managers.
|
|
2.2.69. D895 – Conduct final operations review
|
|
D895 – Conduct final operations review
|
|
|
Description/Definition
|
A final review that the operations staff are ready to take control of the system and that they accept the system as delivered to them.
|
|
2.2.70. D896 – Conduct final production / data control review
|
|
D896 – Conduct final production / data control review
|
|
|
Description/Definition
|
A final review that the production controls and data controls are adequate and ready for live operation.
|
|
2.2.71. D897 – Conduct final user review
|
|
D897 – Conduct final user review
|
|
|
Description/Definition
|
A final review that the users and user management are ready to take control of the system and that they accept the system as delivered to them.
|
|
2.2.72. D900 – Decision to go live
|
|
D900 – Decision to go live
|
|
|
Description/Definition
|
The ultimate governing body or manager for the project should take the definitive decision to go live. It must be certain that all vital pre-conditions have been satisfied to at least a minimum level, eg testing, data validation, training, organisation.
|
|
2.2.73. Delivery (D)
|
|
Delivery (D)
|
2.2.74. L010 – Review/confirm Scope and Objectives
|
|
L010 – Review/confirm Scope and Objectives
|
|
|
Description/Definition
|
The project requires a clear definition of its terms of reference, scope, and objectives. This is a mandate to operate within the client organisation. It allows work to be correctly focused and the outcome to be measured against the original goals.
|
|
2.2.75. L020 – Review / confirm business needs and anticipated benefits
|
|
L020 – Review / confirm business needs and anticipated benefits
|
|
|
Description/Definition
|
An initial statement is prepared and agreed to show what business needs and benefits are expected. This allows the project to keep a focus on achieving those benefits and provides an initial yardstick against which changes can be measured.
|
|
2.2.76. L030 – Select Path(s)
|
|
L030 – Select Path(s)
|
|
|
Description/Definition
|
The paths and processes most appropriate for this project are identified and agreed to provide a skeleton high-level management “Path Plan”. (nb The full Path Plan is developed in process L090.)
|
|
2.2.77. L040 – Define and agree Project Management techniques.
|
|
L040 – Define and agree Project Management techniques.
|
|
|
Description/Definition
|
Before work starts, the form of project management and control must be defined and agreed. Many clients have their own existing approaches or standards which may be followed if adequate and appropriate.
|
|
2.2.78. L050 – Define and agree change management approach (for organisational issues)
|
|
L050 – Define and agree change management approach (for organisational issues)
|
|
|
Description/Definition
|
Define which methodology will be used to manage the change within the organisational. This will provide the framework for managing employees’ expectations, addressing staff issues, education and training needs.
|
|
2.2.79. L060 – Set up / revise and agree communications plan
|
|
L060 – Set up / revise and agree communications plan
|
|
|
Description/Definition
|
An approach should be agreed for the project to communicate necessary messages to the overall organisation. Publicity and education are essential elements in a successful project.
|
|
2.2.80. L065 – Define and agree approach to Skills Transfer
|
|
L065 – Define and agree approach to Skills Transfer
|
|
|
Description/Definition
|
An important part of any project using external consultants is to pass knowledge and skills to the permanent staff. The way in which this should be achieved should be discussed and agreed.
|
|
2.2.81. L070 – Define and agree requirements for linkage with other methodologies.
|
|
L070 – Define and agree requirements for linkage with other methodologies.
|
|
|
Description/Definition
|
The client will frequently have in-house standards. It should be agreed which methodologies, techniques, and standards are appropriate.
|
|
2.2.82. L080 – Do Quality Plan
|
|
L080 – Do Quality Plan
|
|
|
Description/Definition
|
The quality management approach should be defined and agreed. Preferably this should follow a formal approach. It would define standards, approaches, methods, techniques, controls, review methods and the end-of-segment audit process.
|
|
2.2.83. L090 – Produce high-level “Path Plan”
|
|
L090 – Produce high-level “Path Plan”
|
|
|
Description/Definition
|
Produce and agree a high-level management “Path Plan” showing the overall plan for the project. This may include the list of software implementation processes with high-level timescales, sequencing, dependencies, deliverables resources requirements and responsibilities.
|
|
2.2.84. L100 – Define organisation, people and support requirements
|
|
L100 – Define organisation, people and support requirements
|
|
|
Description/Definition
|
Based on the Path Plan, the project’s organisation is defined and agreed. This includes both internal team composition and external needs such as management structure (eg Steering Committee / Project Director) and specialist support (eg Database Admin).
|
|
2.2.85. L110 – Agree Project Launch deliverables
|
|
L110 – Agree Project Launch deliverables
|
|
|
Description/Definition
|
All deliverables should be agreed formally and a mandate obtained to commence the project.
|
|
2.2.86. L120 – Detail the detailed “Segment Plan”
|
|
L120 – Detail the detailed “Segment Plan”
|
|
|
Description/Definition
|
Prepare and agree a detailed plan for the work segment. This may include tasks, milestones, timescales, dependencies and responsibilities.
|
|
2.2.87. L130 – Detail / revise staffing, team structure and organisation
|
|
L130 – Detail / revise staffing, team structure and organisation
|
|
|
Description/Definition
|
Based on the segment plan, the detailed project staffing and organisation may be reviewed and agreed. The required resources must be acquired.
|
|
2.2.88. L140 – Set up / review infrastructure
|
|
L140 – Set up / review infrastructure
|
|
|
Description/Definition
|
Ensure that the project’s infrastructure is in place. A checklist is provided for normal project needs, eg office space and facilities, secretarial support, security passes, access to computer, PCs printers etc.
|
|
2.2.89. L150 – Confirm or renegotiate Consultants contractual relationship
|
|
L150 – Confirm or renegotiate Consultants contractual relationship
|
|
|
Description/Definition
|
Ensure that agreements, understandings or contracts under which the Consultant is working are defined and appropriate given the results of the other project and segment launch activities such as detailed planning and definition of the project team organisation.
|
|
2.2.90. L160 – Mobilise resources
|
|
L160 – Mobilise resources
|
|
|
Description/Definition
|
Organise and confirm the start-up arrangements for each team member. Check that appropriate arrangements have been made with any third parties involved and that any contractual issues have been addressed by the client organisation.
|
|
2.2.91. L170 – Set up / review user involvement
|
|
L170 – Set up / review user involvement
|
|
|
Description/Definition
|
User participation is important in all parts of the project. Ensure all interested parties are involved. Set up formal and informal ways of involving user management. Ensure that the required input from user resources will be supplied.
|
|
2.2.92. L180 – Set up / review management organisation
|
|
L180 – Set up / review management organisation
|
|
|
Description/Definition
|
Make sure required sponsorship and responsibilities are agreed and understood. Make sure sponsors will be proactive. Initiate Steering Committee activities and ensure all management parties are involved and accepting their responsibilities.
|
|
2.2.93. L190 – Implement / re-implement project management and control techniques
|
|
L190 – Implement / re-implement project management and control techniques
|
|
|
Description/Definition
|
Project management, control, tracking and administration procedures should have been defined during the Project Launch. Start these procedures as soon as people are involved in project work – the procedures must be ready on day one or they will not work.
|
|
2.2.94. L200 – Present project / segment approach to user community and team
|
|
L200 – Present project / segment approach to user community and team
|
|
|
Description/Definition
|
Organise formal and informal events to brief all participants (whether or not part of the project team). They will need to understand the client organisation, scope and objectives, methods and approach, infrastructure, and management/control methods etc.
|
|
2.2.95. L310 – Reconfirm approach
|
|
L310 – Reconfirm approach
|
|
|
Description/Definition
|
Between the work segments, a review is made to ensure that the planned approach to the project remains in the best interests of the client organisation. Any issues are discussed and agreed with the client at a senior level.
|
|
2.2.96. L320 – Review / reconfirm / agree high-level “Path Plan”
|
|
L320 – Review / reconfirm / agree high-level “Path Plan”
|
|
|
Description/Definition
|
Review, and, if appropriate, revise and agree the high-level management “Path Plan” based on the results from the previous segments. Appropriate level of client sign off will be required. Equivalent changes may be required in other documentation.
|
|
2.2.97. P060 – Early care
|
|
P060 – Early care
|
|
|
Description/Definition
|
Special levels of care during the early live running of the system in terms of ensuring the live system is operating acceptably well.
|
|
2.2.98. Post Implementation (P)
|
|
Post Implementation (P)
|
2.2.99. ProcesS610 – Prepare, issue and agree selection validation reports
|
|
ProcesS610 – Prepare, issue and agree selection validation reports
|
|
|
Description/Definition
|
Discuss and agree findings with the client. Prepare an agreed selection validation report. If the chosen solution appears unable to meet the client’s mandatory requirements, implementation should not commence and there should be a review of the project.
|
|
2.2.100. Project Launch (L)
|
|
Project Launch (L)
|
2.2.101. Q100 – Check deliverables against Quality Audit checklist
|
|
Q100 – Check deliverables against Quality Audit checklist
|
|
|
Description/Definition
|
This is a formal review to ensure that all required deliverables have been produced, reviewed and accepted following the methods and quality controls stated in the pre-defined Quality Plan. It is not a review of the quality of the work or deliverables.
|
|
2.2.102. Q110 – Check required work against project tracking data
|
|
Q110 – Check required work against project tracking data
|
|
|
Description/Definition
|
Check that all planned tasks have been completed. Explain and document any discrepancies.
|
|
2.2.103. Q180 – Quality Audit signoff
|
|
Q180 – Quality Audit signoff
|
|
|
Description/Definition
|
Formal sign off on behalf of the client organisation and, where appropriate, other participating organisations.
|
|
2.2.104. Quality Audit Reviews (Q)
|
|
Quality Audit Reviews (Q)
|
|
|
Description/Definition
|
This is a formal review to ensure that all required deliverables have been produced, reviewed and accepted following the methods and quality controls stated in the pre-defined Quality Plan. It is not a review of the quality of the work or deliverables.
|
|
2.2.105. R010 – Foundation – “as-is” fact-find
|
|
R010 – Foundation – “as-is” fact-find
|
|
|
Description/Definition
|
An initial investigation to establish the current “starting point” for the work. It would record: – Current Business Processes, Current Data, and Current Organisation.
|
|
2.2.106. R020 – Business Vision / Objectives / Do-Wells
|
|
R020 – Business Vision / Objectives / Do-Wells
|
|
|
Description/Definition
|
Ideally there should be a firm, defined understanding of what the business is trying to achieve. What is this business trying to do and how? What must it do well? Hence – what are the main objectives and priorities for applications in the defined area?
|
|
2.2.107. R030 – External Business Review
|
|
R030 – External Business Review
|
|
|
Description/Definition
|
A review of what other people are doing in similar fields and what is available on the market. It is not intended to short cut the requirements process but to open the teams’ minds to wider possibilities. What are other people doing?
|
|
2.2.108. R040 – Constraints
|
|
R040 – Constraints
|
|
|
Description/Definition
|
Investigate and document all constraints on the eventual solution. Typically these will be: technical, organisational and financial
|
|
2.2.109. R050 – Needs for business process change and priorities
|
|
R050 – Needs for business process change and priorities
|
|
|
Description/Definition
|
Examine and state the areas where business processes would benefit from change or complete redesign. Likewise identify new processes. Business Process Redesign techniques should be used where appropriate.
|
|
2.2.110. R055 – Select package-specific base business model templates
|
|
R055 – Select package-specific base business model templates
|
|
|
Description/Definition
|
Choose from the package/industry specific business process model templates as a basis for a generic business process design.
|
|
2.2.111. R060 – External Technical Review
|
|
R060 – External Technical Review
|
|
|
Description/Definition
|
Review of what is currently technically feasible, eg by demos, literature, demo copies, etc. Helps to stimulate ideas for System Vision, but do not confuse technical feasibility with desirable functionality! Scope restricted per defined “Constraints”.
|
|
2.2.112. R065 – Create and maintain enterprise business model
|
|
R065 – Create and maintain enterprise business model
|
|
|
Description/Definition
|
Set up the initial starting enterprise business model and put in place maintenance procedures to ensure it remains up to date throughout the project.
|
|
2.2.113. R067 – Schedule process modelling workshops
|
|
R067 – Schedule process modelling workshops
|
|
|
Description/Definition
|
Plan the initial modelling workshops in terms of objectives, attendees, availability, preparatory materials, agenda, room bookings, etc
|
|
2.2.114. R068 – Conduct process modelling workshops
|
|
R068 – Conduct process modelling workshops
|
|
|
Description/Definition
|
Conduct the initial project model workshops.
|
|
2.2.115. R069 – Agree initial enterprise business model
|
|
R069 – Agree initial enterprise business model
|
|
|
Description/Definition
|
Consolidate, agree and sign off the results from the project modelling workshops.
|
|
2.2.116. R070 – System Vision: functions, data, volumes, performance, scope, objectives, boundaries / interfaces, technical goals, timescales
|
|
R070 – System Vision: functions, data, volumes, performance, scope, objectives, boundaries / interfaces, technical goals, timescales
|
|
|
Description/Definition
|
Initial view of what the system must be, based on the business needs, constraints, etc. It should state clearly the “functional shape” of the system, eg its scope, boundaries, objectives.
|
|
2.2.117. R080 – Define Topics / IPs
|
|
R080 – Define Topics / IPs
|
|
|
Description/Definition
|
Before cataloguing detailed requirements in the Requirements Matrix, the list of functional, technical, and environmental topics should be defined. This series of headings will be used as the basis to define topics and papers throughout the project.
|
|
2.2.118. R090 – Organisational Impact
|
|
R090 – Organisational Impact
|
|
|
Description/Definition
|
High level statement of organisational issues. A formal change management approach may be used.
|
|
2.2.119. R100 – Identify requirements
|
|
R100 – Identify requirements
|
|
|
Description/Definition
|
Identify and list the requirements in a format that is also suitable for subsequent use in the selection and design processes. In particular it should be suitable for sending to potential suppliers – no confidential information!
|
|
2.2.120. R110 – Interfacing review
|
|
R110 – Interfacing review
|
|
|
Description/Definition
|
Brief initial analysis of the issues and approximate work involved in establishing each of the anticipated interfaces or systems integrations.
|
|
2.2.121. R120 – Gap Analysis – existing systems vs requirements
|
|
R120 – Gap Analysis – existing systems vs requirements
|
|
|
Description/Definition
|
What value is the existing system in the new architecture? What could be kept? What should be replaced?
|
|
2.2.122. R125 – Gap Analysis – requirements vs target solution
|
|
R125 – Gap Analysis – requirements vs target solution
|
|
|
Description/Definition
|
On the basis of the identified business requirements, what aspects cannot be addressed by the Application solution.
|
|
2.2.123. R130 – Establish architectural options
|
|
R130 – Establish architectural options
|
|
|
Description/Definition
|
Establish and detail all reasonable technical architecture options, and, optionally, illustrate their feasibility by tentatively identifying packages matching the business critical requirements.
|
|
2.2.124. R140 – Estimate costs and benefits per option
|
|
R140 – Estimate costs and benefits per option
|
|
|
Description/Definition
|
For each option, prepare initial estimates of costs and benefits, sufficient to give an understanding of the likely costs and to allow comparisons to be made between options.
|
|
2.2.125. R150 – Collate and agree requirements report
|
|
R150 – Collate and agree requirements report
|
|
|
Description/Definition
|
Prepare, review and agree final Definition of Requirements report with the client. (nb in “Requirements – Validate” only appropriate sections will be prepared.)
|
|
2.2.126. R200 – Agree appropriate processes
|
|
R200 – Agree appropriate processes
|
|
|
Description/Definition
|
Agree what work was necessary in the preparation of the client’s own statement of requirements to give a complete picture of the business, process and technical needs. Process path templates can be used for guidance.
|
|
2.2.127. R210 – Agree appropriate deliverables
|
|
R210 – Agree appropriate deliverables
|
|
|
Description/Definition
|
Agree which deliverables should have been produced to document the requirements and what level of contents, detail, quality, review and sign off was required.
|
|
2.2.128. R220 – Review Client’s statement of requirements
|
|
R220 – Review Client’s statement of requirements
|
|
|
Description/Definition
|
Check that the work done by the client has addressed the correct areas to a suitable standard. Check that the documentation of these requirements covers all the necessary contents to a suitable standard. Discuss any issues that arise with the client.
|
|
2.2.129. R230 – Agree and conduct any further work required
|
|
R230 – Agree and conduct any further work required
|
|
|
Description/Definition
|
If there are any significant deficiencies in the work or documentation, remedial actions should be discussed and agreed with the client. This work should normally be performed prior to proceeding with the selection segment.
|
|
2.2.130. R900 Update materials
|
|
R900 Update materials
|
|
|
Description/Definition
|
At the end of the segment, results should be fed back to the support unit for inclusion in Implementation database where appropriate, and subject to any specific confidentiality agreements.
|
|
2.2.131. Requirements (R)
|
|
Requirements (R)
|
2.2.132. S010 – Market Review
|
|
S010 – Market Review
|
|
|
Description/Definition
|
An initial survey of methods and products available in the marketplace.
|
|
2.2.133. S020 – Advertise
|
|
S020 – Advertise
|
|
|
Description/Definition
|
A public advertisement of the client’s requirements, to invite potential vendors to register their interest and/or capability
|
|
2.2.134. S030 – Establish “Long List”
|
|
S030 – Establish “Long List”
|
|
|
Description/Definition
|
A list of appropriate vendors to consider is established using simple, non-controversial criteria such as platform, price etc, and using the team’s experience, research etc as appropriate.
|
|
2.2.135. S040 – Format Requirements Matrix
|
|
S040 – Format Requirements Matrix
|
|
|
Description/Definition
|
Invitation to potential vendors to state their capability to meet the client’s basic requirements and state a number of other key facts from which the list of vendors to be invited to tender in full can be determined.
|
|
2.2.136. S045 – Format Requirements Matrix (Hardware Selection)
|
|
S045 – Format Requirements Matrix (Hardware Selection)
|
|
|
Description/Definition
|
Normal practice. Based on the standard S040 process, but taking into account those specific requirements that are relevant to hardware and IT issues.
|
|
2.2.137. S050 – Design, issue and agree pre-qualification criteria and invitation
|
|
S050 – Design, issue and agree pre-qualification criteria and invitation
|
|
|
Description/Definition
|
Optional – only used where a formal pre-qualification process is needed to select vendors for full evaluation
|
|
2.2.138. S060 Define and agree selection scoring scheme
|
|
S060 Define and agree selection scoring scheme
|
|
|
Description/Definition
|
Agree with the client the basis upon which tenders will be assessed. This will normally be based on a standard approach
|
|
2.2.139. S070 Prioritise Requirements Matrix by criticality
|
|
S070 Prioritise Requirements Matrix by criticality
|
|
|
Description/Definition
|
Categorise and agree priorities per detailed question in terms of criticality, eg Knockouts, Business Critical and Desirable requirements. Identify and discount superfluous requirements. Focus on key differentiating factors.
|
|
2.2.140. S080 – Prepare, review, agree and issue Invitation to Tender
|
|
S080 – Prepare, review, agree and issue Invitation to Tender
|
|
|
Description/Definition
|
Prepare full ITT document containing, background, tendering rules, explanation of overall requirement and detailed requirements in Requirement Matrix “question and answer” format.
|
|
2.2.141. S090 Prioritise Requirements Matrix by weights
|
|
S090 Prioritise Requirements Matrix by weights
|
|
|
Description/Definition
|
Agree importance weightings per detailed question in the Requirements Matrix (according to the agreed scoring scheme
|
|
2.2.142. S100 – Automatic weighting
|
|
S100 – Automatic weighting
|
|
|
Description/Definition
|
Importance weightings are calculated automatically based directly on the agreed “criticality” categorisation of each question (as established in process S070).
|
|
2.2.143. S110 – Short List for ITT
|
|
S110 – Short List for ITT
|
|
|
Description/Definition
|
Identify final list of vendors to receive the ITT.
|
|
2.2.144. S170 – Vendor Conference
|
|
S170 – Vendor Conference
|
|
|
Description/Definition
|
After the issue of the ITT and before responses are required, all vendors are invited to a meeting to exchange views on the requirements, the tendering process and their responses.
|
|
2.2.145. S180 – Package Fit Study
|
|
S180 – Package Fit Study
|
|
|
Description/Definition
|
User driven and controlled testing using evaluation copies of software or existing external facilities (eg vendor, consultants, bureau, other user) to gain a “hands-on” appreciation of the suitability of a likely solution.
|
|
2.2.146. S190 – Mark Responses
|
|
S190 – Mark Responses
|
|
|
Description/Definition
|
Log and acknowledge responses received. Evaluate responses in terms of: compliance with critical requirements, and quantify extent to which responses meet the detailed questions.
|
|
2.2.147. S200 – Identify Issues
|
|
S200 – Identify Issues
|
|
|
Description/Definition
|
Initial evaluation of responses. All business critical areas where zero scores were achieved are listed. Any other issues or doubts arising from the response are also listed.
|
|
2.2.148. S210 – Confer with Vendors
|
|
S210 – Confer with Vendors
|
|
|
Description/Definition
|
Vendor visits, demonstrations, telephone conversations etc aimed at examining the responses and issues in further detail.
|
|
2.2.149. S220 – Consult with reference users
|
|
S220 – Consult with reference users
|
|
|
Description/Definition
|
Visits, demonstrations, telephone conversations etc with other users or user groups aimed at obtaining independent opinions regarding the vendor’s proposed solution.
|
|
2.2.150. S230 – Agree final marks and issues
|
|
S230 – Agree final marks and issues
|
|
|
Description/Definition
|
Based on the vendors’ responses and further investigations with the vendor, other users, user groups, and general discussion amongst the evaluation team, the final scores and issues are agreed.
|
|
2.2.151. S240 – Benchmark
|
|
S240 – Benchmark
|
|
|
Description/Definition
|
A scientific test showing how well the proposed solution will work and/or measurement of its capability to meet the workloads.
|
|
2.2.152. S250 – Prepare and agree selection report
|
|
S250 – Prepare and agree selection report
|
|
|
Description/Definition
|
Produce and agree a report comparing the vendors in both quantitative and qualitative terms, concentrating on key differences.
|
|
2.2.153. S300 – Negotiate terms with vendor(s)
|
|
S300 – Negotiate terms with vendor(s)
|
|
|
Description/Definition
|
The best available contractual terms (eg price, training and services) are sought with the likely vendor(s).
|
|
2.2.154. S310 – Prepare and agree contract(s)
|
|
S310 – Prepare and agree contract(s)
|
|
|
Description/Definition
|
Advise the client regarding IT issues in the proposed formal contract with the vendor(s).
|
|
2.2.155. S400 – Feasibility prototype
|
|
S400 – Feasibility prototype
|
|
|
Description/Definition
|
A prototype of the proposed solution, produced to demonstrate its viability and/or cost effectiveness, benefit etc. It would be completed before agreeing to contract for the full solution.
|
|
2.2.156. S500 – Interview client / customise requirements matrix
|
|
S500 – Interview client / customise requirements matrix
|
|
|
Description/Definition
|
Use standard Requirements Matrices as input to client interview. Should attempt to collect all required information in a single interview per application.
|
|
2.2.157. S510 – Assess potential vendors
|
|
S510 – Assess potential vendors
|
|
|
Description/Definition
|
The Consultant uses own/corporate knowledge to identify 2 to 6 possible vendors based on requirements
|
|
2.2.158. S520 – Get vendors to respond to Requirements Matrices
|
|
S520 – Get vendors to respond to Requirements Matrices
|
|
|
Description/Definition
|
Vendors are dealt with directly by the team. They are made aware of the urgency and that they are on a small short list. They are asked to co-operate with the Fast Track approach by responding very quickly to the Requirements Matrix.
|
|
2.2.159. S530 – Evaluate responses
|
|
S530 – Evaluate responses
|
|
|
Description/Definition
|
Assess the vendors’ responses. This is normally performed in a spreadsheet against the original Resource Matrix questions.
|
|
2.2.160. S540 – Confer with vendors
|
|
S540 – Confer with vendors
|
|
|
Description/Definition
|
Where required, conduct conversations with the vendor(s) by telephone, discussions, demonstrations, correspondence by telefax etc to help finalise the team’s assessment of the responses.
|
|
2.2.161. S550 – Confer with reference users
|
|
S550 – Confer with reference users
|
|
|
Description/Definition
|
Where appropriate, follow up references (normally by telephone calls) to confirm other users’ views about the vendor and the proposed software solution.
|
|
2.2.162. S560 – Identify and agree preferred vendor
|
|
S560 – Identify and agree preferred vendor
|
|
|
Description/Definition
|
Discuss and agree the preferred solution with the client’s decision maker(s).
|
|
2.2.163. S600 – Check business critical requirements against package
|
|
S600 – Check business critical requirements against package
|
|
|
Description/Definition
|
Desk check against documentation, and/or demo/installed system, other users (within client’s related companies or external), or reference sites, user groups. If appropriate, issue full requirements matrix for official response from supplier.
|
|
2.2.164. S700 – Implementation Strategy and Architecture
|
|
S700 – Implementation Strategy and Architecture
|
|
|
Description/Definition
|
Following the detailed investigation of requirements and the evaluation of potential vendors and solutions, the recommended approach is determined. This includes the conceptual design of the overall business solution and the implementation strategy.
|
|
2.2.165. S710 – Define Implementation Strategy
|
|
S710 – Define Implementation Strategy
|
|
|
Description/Definition
|
Following the evaluation of potential vendors and solutions, the overall recommended approach to the implementation is agreed and documented.
|
|
2.2.166. S900 – Update materials
|
|
S900 – Update materials
|
|
|
Description/Definition
|
Subject to any agreed confidentiality requirements, information gathered during the selection exercise is fed back to the Global Support Unit for use in future evaluations.
|
|
2.2.167. Selection (S)
|
|
Selection (S)
|
2.2.168. Software Implementation Processes
|
|
Software Implementation Processes
|
2.2.169. T100 – Identify / confirm new roles for all project staff
|
|
T100 – Identify / confirm new roles for all project staff
|
|
|
Description/Definition
|
Ensure that appropriate arrangements are made for all staff. Staff may be going back to line positions, retained in new support roles, be part of the team providing temporary support and maintenance, part of a phase 2 team, or simply not wanted anywhere.
|
|
2.2.170. T810 – File / archive materials, correspondence etc
|
|
T810 – File / archive materials, correspondence etc
|
|
|
Description/Definition
|
All records must be archived. In some cases, documents may need to be duplicated as both the new owner plus implementation team may require copies. Ensure electronic copies are kept of documents which may be useful in the future.
|
|
2.2.171. T820 – Return / redeploy accommodation and equipment etc
|
|
T820 – Return / redeploy accommodation and equipment etc
|
|
|
Description/Definition
|
Agree what is to happen with all the team’s accommodation and equipment. Accommodation, terminals, PCs and printers etc may be of use to the support and maintenance staff for the new system or redeployed for end users. Take action as required.
|
|
2.2.172. T840 – Prepare Project Completion Report
|
|
T840 – Prepare Project Completion Report
|
|
|
Description/Definition
|
A document should be prepared and agreed listing the achievements of the project in comparison to its goals, and noting further work required or recommended.
|
|
2.2.173. T850 – Collate / prepare Work Books and Owner’s Manual
|
|
T850 – Collate / prepare Work Books and Owner’s Manual
|
|
|
Description/Definition
|
The project’s main documentation is grouped into a Work Book holding all key working documents for the project, and an Owner’s Manual holding all permanent design documents to be held for future reference when enhancing the system.
|
|
2.2.174. T900 Update materials
|
|
T900 Update materials
|
|
|
Description/Definition
|
Subject to any agreed confidentiality requirements, information gathered during the project is fed back to the Application Software Implementation Processes Global Support Unit for use in future Application Software Implementation Processes engagements.
|
|
2.2.175. Terminate Project (T)
|
|
Terminate Project (T)
|
Leave a Comment
You must be logged in to post a comment.
