Blog Posts Process Analysis

Delivery – Brief Delivery Process Path

Blog: Biz-Performance, David Brown

Delivery – Brief Delivery

An accelerated form of delivery relying upon a simple approach.  This can be appropriate where there is a small scope, a non-adversarial organisational environment, and relatively straightforward technical options.  Typical criteria for adopting this approach might be:
  • the scope of the project should be small (e.g. one business area, one business line),
  • a small group of empowered people is available within the client organisation who can make the decisions in the project,
  • there is strong pressure to meet deadlines that could not be met with a full approach as in Delivery – IDDI.
In many cases, the same processes are involved, but they are conducted in a simpler way.  For example, Brief Implementation Papers are used in place of Implementation Papers – these require substantially less evidence of detailed evaluation and consultation.  The availability of empowered managers to agree and sign off designs and activities generally leads to rapid progression through the processes.

Agree reviewers and sign-off authority / responsibility
Normal practice
Agree a small, empowered group of authorisers and sign off responsibilities.
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.
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.
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, e.g. log ons, access security, accounts, budgets etc.  With medium systems this is often performed by the vendor.
Impose issues control and change control
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.)
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.
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 and the vendor is not represented.
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?
Consider, review and plan approach to interfacing and systems integration
Optional – used where there will be significant interfacing or integration.
his 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.
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.
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.
Design/Prototype – Brief Implementation Papers
Normal practice
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.
Create detailed specifications for non-Integrated Application Software IT development work
Optional – used where non-Integrated Application Software 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.
Instigate non-Integrated Application Software IT development parallel tasks
Optional – used where non-Integrated Application Software IT development tasks are required in the overall technical solution
non-Integrated Application Software IT development 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.
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.
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.
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.
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.
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.
Plan, prepare and conduct User / System / Acceptance and Integration testing
Formal testing must be performed to ensure that all significant aspects of the system are acceptable.  Careful planning and preparation is required to ensure it is complete and comprehensive.  Results must be reviewed and signed off by responsible users.
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.
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.
Define live support mechanisms
Normal practice
Dictate responsibilities for support of the live system and liaison points with the vendor.
Load start up data
Normal practice
All initial data should be loaded.  Includes running of conversion suites and manual data entry.
Validate start up data
Normal practice
Complete loaded data should be validated and signed off by the responsible user managers.
Decision to go live
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.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples