Path Template: Delivery – IDDI (Integrated Design Development)

Blog: Biz-Performance, David Brown

Integrated Design Development (IDDI) assumes that package components are technically reliable and coherent such that the project team do not need to take a serial approach to the design work.

By relying on the technical coherence of the solution, it is possible to work on different functional or environmental aspects of the system independently in parallel. This leads to substantial savings in elapsed time, in effort and in scheduling staff resources.

Each individual aspect of the system will undergo its own cycle of design, delivery and implementation with appropriate sign offs in between. The key differences are:

these are small manageable amounts of work that encourage good full review by user management with a minimum drain on their time and the avoidance of bottlenecks caused by large volumes of paper to review in a short time,
when little work can be performed on one aspect, the team can be concentrating on others, thus making the best use of their time.

Ref	Process		Optionality	Definition

D100		Prepare / review / agree design topics / IP descriptions and sign offs.	Normal practice	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.
D110		Review technical environment and plan installation	Optional – usually required when insufficient detail was included in the Delivery Approach documentation and segment plan	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.
D120		Plan, prepare and conduct project team training	Optional – usually required unless whole team have requisite experience in all aspects of the solution.	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.
D130		Install hardware, communications equipment, system software, and applications software as required for development, implementation and live running.	Optional – required when insufficient provision is already available for the project.	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.
D140		Define, agree and instigate change control procedures	Optional – normal practice where there are several key users and/or several people on the team. (When no formal mechanism is in use – all changes must still be documented and agreed in writing.)	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.
D150		Define and instigate Project Team responsibilities and techniques for technical support, bug reporting, fixing, supplier liaison etc.	Optional – normal practice where there are several people in the team.	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?
D230		Focus on delivery of benefits – Cost/Benefit Model	Optional	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.
D160		Consider, review and plan approach to interfacing and systems integration	Optional – used where there will be significant interfacing or integration.	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.
D170		Build / maintain data dictionary / data model	Optional – used where required by the client, or where the technical solution is part of a larger database, or where an enterprise data model is in use	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.
D180		Data Conversion Strategy	Optional – used where existing data will be brought into the new system	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.
D300		Prepare discussion papers	Optional – discussion papers may have been identified in the segment plan or may be used to explore any particular issue that arises as the team see fit.	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.
D400		Design / Prototype – Implementation Papers	Normal practice	Design or define each topic using prototyping techniques wherever appropriate, documenting the requirements, options, recommended approach and details in an Implementation Paper per topic.
D190		Issues – control, escalate, resolve	Optional – used where there are several people involved in the project	Issues that arise during the design work are noted, logged, controlled and resolved. Escalation and tie-breaking mechanisms are used where necessary.
D600		Create detailed specifications for IT development work	Optional – used where IT development tasks are involved in the overall technical solution	Define the technical requirements to a sufficient level that they can be used in the detailed design, programming and construction of a component.
D650		Instigate parallel tasks	Optional – used where tasks are required in the overall technical solution	Tasks should be instigated as appropriate. Controls may be set in place to monitor progress, to ensure adequate quality and to ensure delivery will be on time and within budget.
D700		Set up system parameters, codes, structures, etc	Normal Practice	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.
D710		Set up screens, queries & reports etc	Optional – as required	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.
D720		Prepare and instigate operators’ instructions, procedures and manual	Optional – depending on suitability of vendor’s standard materials available	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.
D730		Identify human and organisational issues	Optional – used where there are several users affected by the project.	Assessment of the required organisational change, and resistance to such a change. A formal Consulting approach may be used.
D740		Implement change management programme	Optional – used where organisational change is necessary	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.
D750		Prepare and instigate User Procedures and User Manual / electronic information	Normal practice	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.
D760		Plan, prepare and conduct user and management training and education	Optional – used where user and/or management training is required	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.
D770		Plan, prepare and conduct operations training	Optional – used where operations staff require training	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.
D800		Plan, prepare and conduct User / System / Acceptance and Integration testing	Mandatory	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.
D810		Plan, prepare and conduct technical tuning and volume testing	Normal practice	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.
D830		Define, plan and agree handover / cutover	Normal practice	An analysis should be made of the logistical requirements for changing over to the new systems. Detailed timings must be considered and agreed.
D850		Define and agree terms of reference for live user support activity	Optional – used where post live support will be required	Analyse and agree the requirement and constitution of functional and technical user support for the live system, eg systems control, help desk, scheduling etc.
D780		Plan, prepare and conduct support staff training	Optional – used where support staff need training	Specialised training is required for the staff who will be supporting the system, eg systems control, help desk, etc.
D870		Plan and instigate phased transition to live operation and support / phasing out of Project Team support	Normal practice	A plan should be agreed and executed to pass control and support of the system from the project team to the line departments with responsibility. This should normally be done in a phased manner so that there is no sudden change in levels of support.
D880		Load start up data	Normal practice	All initial data should be loaded. Includes running of conversion suites and manual data entry.
D890		Validate start up data	Normal practice	Complete loaded data should be validated and signed off by the responsible user managers.
D900		Decision to go live	Mandatory	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.

Path Template: Delivery – IDDI (Integrated Design Development)

Blog: Biz-Performance, David Brown

Leave a Comment Cancel reply