Development
Importance of the phase for democratic dialogue
This phase mainly concerns the development team (PM), but the digital translation of the overall logical vision produced in the Design & Planning phase inevitably leads to interpretations and adaptations in response to constraints (technical, budgetary, scheduling, etc.) that may impact the responses given to the needs expressed, particularly those concerning well-being and citizenship at work.
The involvement of those bearing the needs in terms of well-being and citizenship at work must therefore remain constant throughout the phase.
Standard presentation of the phase
APIDOR’s advice
In the case of purchasing off-the-shelf software (software package), a specific cycle is followed (see below).
The phase described here corresponds to the development of specific software (or its evolution).
This phase mainly concerns project management.
Other names: technical study and implementation (which are sometimes two separate phases), development, execution.
- Agile approaches
If the entire project is not managed using an agile approach, it may be decided at the beginning of this phase to continue using agile methods.
It is therefore important that those responsible for requests relating to well-being and citizenship at work are aware of the specific features of agile approaches: see Agile approaches.
Phase objectives
Produce the software (project deliverable) in a version that has been technically tested by the development team.
If purchasing software, configure it with the service provider’s team.
- Case of purchasing software
See details below.
Note: the challenges for senior management.
Focus primarily on costs and deadlines, which must remain within the budget.
Phase inputs and outputs
Inputs
Specifications for implementation, including all modeling
Outputs
The application that is the project deliverable tested (by the development team) to verify its compliance with technical specifications (internal project management team).
Technical acceptance report.
Technical integration of the software into a tested general architecture (internal project management team).
Internal project management team documentation.
External documentation
Actors and bodies involved
The project manager.
One or more business analysts (equivalent to project owner assistants).
Developers, including one or more technical testing specialists (= test-oriented developers), with possibly a test manager (depending on the size of the project).
- Point of vigilance: PO assistants
Project owner assistants (and/or business stakeholders) specializing in workplace well-being and citizenship issues must be consulted during this phase.
Content and sequence of the phase
Two sub-phases: technical study and development.
Technical study (only concerns the project management team): optimization of the physical structure of data and volumes. Preparation for development: development of processing procedures (program files), definition of technical standards.
Development: programming, internal testing, integration testing, development of test sets for the acceptance phase.
- Point of vigilance: HMIs
The concrete implementation of HMIs will enable their content to be detailed in very concrete terms. Furthermore, certain unforeseen technical constraints may lead to modifications to the HMIs as planned in the Design & Planning phase.
Those responsible for requests relating to well-being and citizenship at work must be informed of the details of the HMIs and any changes, and must assess whether the needs expressed have been met (see in particular the proposed requirements in Autonomy).
- Point to note: decision support (including dashboards)
Same comment as above regarding HMIs (see in particular the proposed requirements in Decision & Management System).
Information usually disseminated/processed
Mainly project monitoring indicators (KPIs) on costs and deadlines.
Possibly a data dictionary.
Note on data dictionaries1: “centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format.”
They may be subject to standards (e.g., ISO 20022 for financial institutions2), but in some areas, they may not exist, as business objects are not defined precisely enough.
-
Information to be received
The data dictionary or dictionaries must be available for consultation by those submitting requests relating to well-being and citizenship at work.
- Point to note: risks in the absence of a data dictionary
The absence of a data dictionary can be problematic, particularly for decision-making tools (including dashboards).
In such cases, it is difficult to assess the quality of the data and indicators, exposing the organization and its employees to the risk of decisions being made on the basis of highly unreliable or even false data.
Case study: purchasing off-the-shelf software (software package)
Reminder: the purchase decision is made either at the end of the Design and Planning phase or at the end of the Initiation phase.
The purchase of off-the-shelf software generally follows the organization’s purchasing procedures (e.g., requirement for at least three quotes, transparent selection criteria, public procurement regulations, etc.).
The first step is to research the software available on the market that is likely to meet the expressed need. We look at what exists in the macro business sector, then we research the specific features of the software in the sector, the functionalities that are provided and those that are not.
This research allows us to select an initial set of offers and potential partners.
The Initiation and, where applicable, the Design and Planning phase have made it possible to define a set of requirements ranked according to their essential or optional nature. An analysis grid for the proposals can thus be established, supplemented by criteria relating to the partner (financial strength of the company, proven skills, experience, known customers, etc.). A shorter list of partners is drawn up on the basis of these criteria. The call for tenders is sent to these service providers, and one of the proposals is selected based on the defined criteria.
Once a service provider has been chosen, the actual Implementation phase will focus on:
- refining requirements and, in general, adjusting them to the capabilities of the chosen software
- selecting the specific modules (and features) to be included in the order
- in general, customizing functions, data structures, HMIs, output reports, etc.
- in general, transferring existing data.
It should be noted that the Delivery & User testing and Deployment phases are comparable to those for custom-developed software.
- Information to be received: purchase of off-the-shelf software
The procedure for selecting off-the-shelf software must be transparent and known to those responsible for requirements in well-being and citizenship at work.
- Democratic dialogue procedures: purchase of off-the-shelf software
The criteria for selecting the software and, where applicable, the integrator must be subject to democratic dialogue.
These criteria must be consistent with the needs expressed in terms of well-being and citizenship at work.
- Information to be received: software package features
Those responsible for needs in well-being and citizenship at work must have a precise description of the features offered by each of the software packages selected.
They must compare them with the needs expressed in terms of well-being and citizenship at work.
- Information to be received: modification of work processes
The degree and type of modification of current work processes by each of the off-the-shelf software packages under consideration must be analyzed and evaluated.
They must be one of the criteria for choosing which software to purchase.
- Point of vigilance: HMIs, dashboards, etc.
The customization of HMIs, dashboards, etc. must meet the needs expressed in terms of well-being and citizenship at work (see the need categories Autonomy and Decision & Management System in the proposed requirements table).
- ISIDOR help
For a list of questions to ask yourself about HMIs, see ISIDOR, Autonomy Analysis Grid.
For a list of questions to ask yourself about dashboards, see ISIDOR, Management System & Decision Analysis Grid.