Design & Planning
Importance of the phase for democratic dialogue
Design/planning is an important phase for democratic dialogue, in that needs will be largely determined at this stage and then translated into models that cannot be easily modified during subsequent phases.
It is therefore essential that democratic dialogue be practised throughout this phase.
Standard presentation of the phase
APIDOR’s advice
Note: Agile approaches (see Iterative and Incremental Model and Agile approaches) eliminate the ‘Design’ phase (and sometimes also the ‘Initiation’ phase), in the sense that it is integrated into the iterative cycle.
Other names: design, detailed study, business architecture, roadmap/project milestones.
- Please note
Most of the APIDOR advice given for the Initiation phase is relevant to the Design/Planning phase. With a few exceptions, it will not be repeated here.
Phase objectives
The overall objective of this phase is to eliminate as much as possible the unexpected and the unknown by refining the requirements expressed in the Initiation phase in order to remove all ambiguities.
- Define what the project’s target application must do by refining the requirements expressed in the previous phase (functional and non-functional requirements).
- In line with the refined requirements, model the business objects and their properties (data), processes, states, etc.
- Produce specifications for development.
- Divide the project into lots and draw up a detailed plan.
- Decide on the production method: purchase, have it developed, or develop it yourself (with possible subcontracted lots).
- Determine the composition of teams and committees.
- Democratic dialogue procedures
The principle of representing those who will express the needs related to well-being and citizenship at work in various committees must be formalised.
A specific body may be considered for the formalisation, validation and verification of the consideration of needs expressed in terms of well-being and citizenship at work.
If such a body is not established, a Users’ Committee must be set up.
Note: challenges for senior management
The Design must accurately reflect requirements.
If senior management has new expectations (compared to the Initiation), these must become requirements in order to be taken into account.
- Key point for senior management
Senior management must promote the requirements related to well-being and citizenship at work.
Phase inputs and outputs
Input
Initiation note.
Outputs
The specifications for implementation, including general functional specifications (business requirements) and various models: data (business objects), processes, reports, etc., formalised using modelling tools (e.g. in UML: use case diagrams, sequence diagrams, activity diagrams, class diagrams, etc.).
The detailed schedule for the various lots (macro lot division).
The detailed provisional budget.
The refined risk analysis.
The composition of the teams (project management organisation).
The list and composition of the committees.
- Point to note: specifications
The specifications are an essential document, on which the software to be developed will largely depend. They must be analysed in light of well-being and citizenship needs in the workplace.
- Training required (duty) for those responsible for expressing requirements in wellbeing and citizenship at work
Training in reading/understanding diagrams (data modelling, process modelling, etc.).
- Reminder: risks related to working conditions
Risks related to wellbeing and citizenship at work must be included in the risks to be assessed and addressed.
Actors and bodies involved
The project team is defined according to technical requirements. External service providers may be part of the team (or even represent the bulk of it in the case of subcontracting).
Design involves expert roles: these may include the project manager, one or more architects, and developers.
The project owner (PO), and in particular the project owner’s assistants (POAs). These individuals have business knowledge, but also design knowledge. They assist business analysts when they do not have the time.
- Reminder: participants in democratic dialogue
Those responsible for bearing needs in well-being and citizenship at work, as well as specialised PO assistants, must be involved in this phase.
Content and sequence of the phase
In principle, it is the project owner who writes the detailed functional specifications based on interviews with users (often key users) and business managers, but in some cases this may be done by the project manager.
The Design & Planning phase allows the functional and non-functional requirements to be refined (but also, following the interviews, new requirements to be identified), the HMIs (at a still relatively general level) and the digital paths in the application to be described, the processes (in sufficient detail to remove any functional ambiguities), the output states and, where applicable, the dashboards (reporting, statistics) .
On this basis, the specifications for implementation are drawn up.
The Design & Planning phase produces an overall logical vision.
User profiles are defined: who has the right to do what, to see what (depending on visibility contexts)?
Basic rights are thus distributed: CRUD (create, read, update, delete) for each user profile, by business object.
If the common glossary was not created during the Initiation phase, it must be created during the Design & Planning phase.
With regard to project organisation, the project team and various committees (steering committee, project committee, user committee, etc.) are formed.
A general plan for the project and its various stages is drawn up, along with a detailed provisional budget.
The decision to purchase off-the-shelf software (software package), to have it developed, or to develop it in-house is made towards the end of the phase, once the essentials have been worked out. This choice depends on several criteria, including the size of the project.
At the end of the Design & Planning phase, there is a period of negotiation between designers and developers to define the technical skills required and a schedule that is as consensual as possible. The team is defined according to technical development needs.
If a problem appears insurmountable in technical or scheduling terms, the project leader (sponsor) is consulted to negotiate changes to the requirements and/or schedule.
- Point to note: check the functional specifications
The functional specifications must be checked to ensure that well-being and citizenship at work requirements are properly taken into account.
- Point to note: database structure
If a database is to be built for the application to be developed, those responsible for well-being and citizenship at work requirements must be able to participate in or be consulted on its design.
This is because the structure of the database cannot be changed quickly or easily. It is important that the data necessary to meet the expressed needs in terms of well-being and citizenship at work is included.
- Proposals to be made: HMI
The design of HMIs must guarantee individuals and groups sufficient autonomy in their work. See the category ‘Autonomy’ in the proposed requirements.
- ISIDOR help
For a list of points to check on HMIs with regard to autonomy, see ISIDOR, Autonomy analysis grid
- Proposals to be made: dashboards
The content of dashboards must be subject to democratic dialogue.
See the requirements in ‘Decision-making & management system’.
- ISIDOR help
For a list of points to check on dashboards, see ISIDOR, Management system & Decision-making analysis grid.
- Elements that absolutely require clarification
The conventions used to calculate data (particularly indicators in dashboards) must be clarified and known to all stakeholders.
They must be open to debate. See the ‘Clarification requirement’ category in the table of categories of requirements.
- Point to note: automation of decisions that were previously made by humans
The decision to automate decisions previously made by humans must be agreed upon by consensus among the stakeholders concerned.
- Proposals to be made: user categories
Existing/predefined user categories should be reviewed. Democratic dialogue should make it possible to define new user categories based on actual working conditions.
- Reminder: point of vigilance glossary
In the project glossary, particular attention must be paid to the definitions of terms expressing values and indicators.
- Democratic dialogue procedures: choice of off-the-shelf software
The decision to purchase off-the-shelf software must be the subject of democratic dialogue (see Implementation phase).
Information usually disseminated/processed
All documents, and in particular all diagrams, are stored in shared directories for authorised persons.
- Reminder: training required for participants in democratic dialogue
Training in reading/understanding diagrams (data modelling, process modelling, etc.).