Project Delivery Process D100

D100 - Prepare / review / agree IP / Topic descriptions and sign-offs

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.

SUMMARY

The key feature of Integrated Design Development and Implementation (IDDI) is the division of the overall work into logically discrete topics which can be worked upon in parallel.  Where a methodology has been followed throughout the project, these topics may already have been defined during the requirements, selection or “project model” segments (see Process R080 -Define Topics).

The project is divided into these topics for many purposes - each topic is treated as a separate aspect of the project with its own design, development, testing, training and implementation elements.

Each topic will normally be defined, designed and documented using an Implementation Paper (IP).  For this reason the term “IP” is often used to describe the entire design and prototyping concept although, strictly speaking, the IP is only the design document describing the topic.

At the outset of the delivery segment, the list of topics must be created and/or revised to define the precise breakdown of topics.  Responsibilities must be defined both for the conduct of the tasks and for the management “ownership” of the topic.  This list may evolve during the project as topics become further defined and give rise to further activities.

The definitions are recorded in two linked documents - the Definition of IPs/Topics (DoT) and the IP Control Log (IPCON).

The definitions should be formally agreed and accepted by the client organisation.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):

• (none)

Prerequisites (Finish-Finish):

• finalisation of the high level design architecture/scope of project

Dependent procedures (Finish-Start):

• all IP (or BIP) design tasks

RECEIVABLES

• Delivery Approach Definition (DAD) or equivalent statement of overall design architecture

DELIVERABLES

• Definition of IPs/Topics (DoT)
• IP Control Log (IPCON)

TOOLS

• sample lists of IPs per application area / industry
• IP control log template (IPCON)
• Definition of IPs/Topics Template (DoT)

DETAILED DESCRIPTION OF TASKS

Topics

A key feature of the approach is the division of the overall work into a number of discrete topics.  This allows rapid and effective progress with all aspects of the work - during requirements, selection and implementation segments.

Topics are the smallest practical subsets of the overall work that can be worked upon as independent aspects of the project.  By breaking the full complex requirements into manageable sizes, the team can cope with the workload more efficiently and more effectively.

Although this principle is used throughout the project lifecycle, the greatest advantages of this approach tend to be apparent during the Delivery work segments (design / prototype, develop/construct, testing, implementation, rollout etc)  where the principle of Integrated Design Development and Implementation (IDDI) is used to generate a better solution, in less time with less overall effort.

Distinguish between three types of topic:

• Functional - concerning the required functionality and how it will be achieved using the package solution
• Environmental - concerning the requirements and actions relating to the environment rather than the functionality of the system, for example security requirements and training needs
• Technical - concerning technical work required to implement the system, for example interfaces, conversion, and technical set up.

Initial lists may have been prepared during the Requirements and/or Selection segments (see Process R080 - Define Topics).  This process is intended to establish the final list of topics to be used for the design and development work.  This will dictate the actual breakdown of tasks and the individual Implementation Papers (IP) that will be used to investigate, prototype, and develop the topic.  The actual list of topics and Implementation Papers will be based upon the particular circumstances of the project, for example, the needs of the client organisation, the application area, the size of the project, the preferred technical architecture etc.

During the life of the project, conclusions in one topic may give rise to further areas requiring consideration.  It is common for one topic to lead to new or changed dependent topics.  For example, a topic such as the Data Conversion Strategy, would define the topics to be followed in designing and developing the manual processes or computer developments recommended in the strategy.  Where this represents a change from the original plans it should be reviewed and agreed and the Definition of Topics, IP Control Log and segment plan updated accordingly.

Definition of IPs/Topics  (DoT)

Sample lists of topics and IPs can be used as the starting point for most applications and industries.  The final list will always depend on the precise needs of the client and the definition and scope of the project.

The IPs will either be broken down by business process and/or functional area.  It is important that the IPs collectively cover all issues involved in the business solution, but break it down into manageable, discrete elements such that the full advantages of the IDDI concept can be exploited.  They should not be too small, nor too large.  Where there is a large amount of detailed parameter/table/configuration information involved, it is advisable to include the configuration information as attachments to the IP.

For each paper identified, the following information may be described in the Definition of IPs/Topics (DoT):

Topic	Definition / comments
Reference	An identifying code for control and cross-reference purposes
Title of the IP
Scope/Objectives	Brief text to describe the scope and objectives of the paper
Type	Type of paper, eg Implementation Paper, Brief Implementation Paper, Discussion Paper
Permanent / Temporary	Permanent papers document design issues or other aspects of the system that have a permanent value - these will be filed in the system’s “Owners Manual”; Temporary Papers are only of value during the project and will be filed in the project’s “Workbook”
Responsible Manager	This is the manager within the client organisation who it is agreed will have prime responsibility for defining, agreeing and signing off matters relating to this topic
Overlapping Papers/Topics	This is used to note any particular other topics which are expected to overlap or to impinge upon this topic
Notes on anticipated or known issues	Used to note any issues known or anticipated prior to the writing of the IP
Other notes / comments	As required

The DoT template document can be set up as a spreadsheet.  Although it is a single table, it prints in two parts - scoping information and issues/comments information.

IP Control Log (IPCON)

The IP Control Log is used to control progress and issues relating to the Implementation Papers (IP).  It has a similar format to the Definition of IPs/Topics (DoT).  It can be started by cutting and pasting the Categories, References, Titles and Responsible Manager information from the DoT.

Other control information may be stated on the IP Control Log.  In particular, it can be used to define other responsibilities such as the prime author and other required signatories.  The following information may be included:

Topic	Definition / comments
Reference	An identifying code for control and cross-reference purposes
Title of the IP
Responsible Author	The prime member of the Project Team responsible for investigating the topic and preparing the paper
Date(s) signed + status	Sign-off by the author - status shows whether this is “in principle” ie the reviewer requires no further change but the topic is open, or “final” ie the paper is now finalised and should not be amended further (other than through the formal change control process)
Responsible Manager	This is the manager within the client organisation who it is agreed will have prime responsibility for defining, agreeing and signing off matters relating to this topic.
Date(s) signed + status	Sign off by the Responsible Manager provides a definitive acceptance by the organisation.  Sign off may be “in principle” or “final”
Other required signatories	These are other personnel within or outside the Project Team who it is agreed should review and sign-off matters relating to this topic
Date(s) signed + status	Sign-off by other signatories “in principle” or “final”
Other circulation	Other agreed recipients of the paper.  Further notes may be added to show whether this is for review or information only etc and whether draft copies or only final copies should be supplied
Document Status	This shows the current status of the document, eg draft, signed “in principle” or finalised
Version Number	The current version number of the document
Planned Publication Date
Included in Management Summary	Shows whether the contents of this paper should be/have been included in the overall Management Summary design document (if applicable)
Document location	Where the document is located or stored - normally a reference to its electronic library and filename
Other comments	as appropriate

The IPCON template document is set up as a spreadsheet.  Although it is a single table, it prints in two parts - signoff/responsibilities information and status information.

Review and agree

Individuals’ involvement, powers and responsibilities should normally be discussed and agreed with the personnel concerned.  Care should be taken to ensure that appropriate participants are chosen.  In particular, Responsible Managers should have sufficient time, interest and sponsorship to perform their role - they should be involved, responsible, accountable and committed.  They should also have the requisite knowledge and expertise to comment authoritatively on the topic and they should have an understanding of all the related business areas.

It is not uncommon for there to be political problems in defining responsibilities.  These may be addressed by the use of multiple sign offs, but it is desirable for a single person or body to be acknowledged as having the ultimate decision in case there is a deadlock.

The definition of the topics and, in particular, the sign off responsibilities form a crucial part of the project’s mandate.  It is important that the powers and responsibilities are formally agreed by the project’s executive body - eg a steering committee or the sponsor.

Any effect on the high-level “Path Plan” or detailed “Segment Plan” should be addressed and agreed.