An interview with Mr. Joaquín Luzón, INSIKT Intelligence, Spain, published in CounteR newsletter #2.
Dear Joaquín, why is the completion of the requirements phase considered a milestone?
Simply put, the requirements-gathering phase is one of the most crucial steps for the development of the project as a whole and, at the same time, one of the hardest to achieve – it is the process of translating the project’s initial on-paper guidelines into explicit action items that respond to the specific needs of the partner Law Enforcement Agencies and Internet Service Providers. Attaining this milestone is the result of a substantial amount of multilateral work and coordination conducted over an extended period of time with the contribution of virtually all partners, since the technical, legal and commercial requirements are also established during this period. Besides setting this initial blueprint, the requirements phase also sets the bar and specific expectations against which the success of the project will be measured, and outlines how the work will be carried out.
As an end user, when asked “what do you need to make your fight against extremism more efficient?”, a very natural answer would be “considering the stakes, give me everything”. If everything is not an option (unfortunately), what is the process to determine what requirements/user needs will be prioritised for the development of the prototype?
It is indeed a very tricky exercise and a balancing act. We leverage every single technology and resource available and try to include as many features as possible to fulfil user needs in the most comprehensive way achievable. However, we need to do this within the parameters set in the Grant Agreement (namely scope, time, and resources) and the viability assessment performed by the technical partners, without forgetting about privacy and other legal tenets. The prioritisation of the requirements has been done following a MoSCoW approach (i.e. Must, Should, Could, Won’t have). At this moment of the project, CounteR is committed to developing the “MUST have” requirements; the “SHOULD have” ones will be systematically revisited during the project’s lifetime to see if their inclusion is in any way feasible; while the “COULD” ones can represent a very advanced list of additional capabilities to be built in future additional projects or operational settings.
What profiles play a bigger role in this process?
End users, end users, end users, end users, end users! Even though other types of requirements are also established in this initial phase (commercial, legal and technical), the lion’s share of the requirements setting revolves around LEA’s and ISP’s needs – the project’s overall goal is to develop a prototype of a tool, specifically tailored to their needs. Additional roles are also required to make the process more efficient: Project/Product Managers, who help design and implement a proper plan for the correct specification gathering; coordinators, who ensure the most productive approach is being followed and that User Requirements are aligned with the DoA/GA, and finally technical partners, who validate and assess the requirements’ technical feasibility.
What were the main challenges encountered during this process?
Firstly, the LEAs and ISPs participating in the projects come from different countries and have very different expectations and needs. They understandably are very busy organisations, therefore the requirements gathering has to be as effective as possible. The solution we found to this obstacle was putting in place an iterative process to progress in an incremental way, each iteration building off the advances of the previous one. Another challenge has to do with how different in nature the types of requirements are. While all of them are important, the constraints inherent to each gathering process are heterogeneous: when it comes to the legal requirements, for instance, the sources determining the limitations and compliance obligations are the national and international bodies of law regulating these aspects, i.e., an external framework the consortium has to comply with. On the other hand, when agreeing on the user requirements, the challenge remains purely intra-consortium and require achieving consensus between a large number of participants. There are also differences when it comes to the possibility of revisiting these requirements further down the line of the project timeline: the initial commercial requirements, for example, can (and should!) be revisited with updated market data when the exploitation and commercialisation phases start, whereas the legal requirements set a much more unyielding foundation to be observed. This sliding scale of “definitiveness” represents an added layer of variation that needs to be kept in mind when compiling the different kinds of requirements.
So, how was consensus finally achieved amongst so many partners?
Well, let me tell you – it has not been easy! We conducted a series of meetings and workshops, some of them with all the LEA partners, others were bilateral between the project coordination, technical partners, and the end users. We complemented the interactive meetings with asynchronous work and questionnaires, and put in place several reviews and pit stops along the way. This process required a high level of involvement and active discussions amongst all consortium partners. In that regard, we are very satisfied with the final outcome of this phase.
Finally, how do you plan to track the progress of the specifications being accomplished? Are you planning to review the requirements prioritisation anytime in the project?
The project has a number of built-in mechanisms to monitor the pace at which these specifications are being developed and attained, and ascertain whether additional requirements can be finally incorporated to the roadmap, or if any course correction is needed. The best way to make sure the project as a whole is a success is, once again, to iterate and plan a number of checkpoints along the way. To make sure this process is conducted in a structured manner, a series of deliverables to come will concentrate on this prioritisation monitoring, analysis and review. In fact, one of the main objectives of WP8 – Training, Knowledge Empowerment and Pilots, is to ensure the correct validation of the solution. This would imply conducting a thorough assessment of how the project specifications have been met.
Joaquín Luzón
Joaquín Luzón is a telecommunications engineer with multidisciplinary experience in project management, particularly in the fields of Technical Innovation, Research and Development, among others.
Joaquín has coordinated projects under a number of national and international research instruments, such as the European Commission (H2020), MINECO, MINETUR and the Centre for the Development of Industrial Technology of Spain (CDTI).
