La version française de cet article est disponible après le texte anglais.

Sorry, there are no secrets to fast-tracking the process of Canadian Army equipment procurement. After almost four years as Director of Land Requirements (DLR), one of longest serving in recent memory, Colonel Chris Renahan has acquired a sound understanding of how capability is delivered. If there is a secret formula, he hasn’t found it.

If you want to move a project forward quickly and efficiently, the fastest way is to follow the process. That’s a paraphrased quote from a former DLR coordinator, Greg Burton, that still holds true. “Every time you try to do something different you are rolling the dice,” Renahan noted.

He has described the pace of DLR’s work as the busiest he has ever seen, and on par with the efforts to support times of high paced operations. Despite two years of pandemic-related disruptions that limited in-person meetings with stakeholders, including industry, the directorate has progressed a sizeable portion of its projects through the identification and options analysis (OA) phases. It delivered the Headquarters Shelter System, started production on the Armoured Combat Support Vehicles, and saw the last of the Medium Support Vehicle System Standard Military Pattern trucks roll into service. While those and other projects have advanced through definition and into implementation, the bulk of the projects that were launched with the release of Strong, Secure, Engaged (SSE) – about half of around 40 projects – are working through or at the end of the OA phase.

So, finding success among projects that can take more than a decade to reach fruition requires a long view. “I need to find the job satisfaction in the little victories, like reaching key milestones that are invisible to most and don’t make headlines because they are almost 100 percent procedural,” Renahan admitted as he settled into a five-month course at the NATO Defense College in Rome, Italy that, with a few courses from the Canadian Forces College, will grant him the equivalency of the Canadian National Security Programme.

Between some grocery shopping in Rome and an evening of schoolwork, he reflected on the procurement process and the challenges posed by rapidly evolving technology.

I’m not sure if it is refreshing or disappointing to hear there are no shortcuts or novel methods for moving projects through the various gateways more quickly. What works and why?

I think we often hope for ways to fast track a given project, but oftentimes those solutions generate even more work when not everyone involved understands the intent or reasoning for deviating from the normal path. 

A key element is early, frequent, and close collaboration with the many stakeholders involved. This starts with Army project directors building a close relationship with their Materiel Group Project Management team, but also includes all the internal to National Defence (DND) contributors and overseers of the project, along with the other government departments that are needed to enable a project’s success. Involving this broad team of stakeholders early helps them to understand what it is we are trying to do and to have their input before critical decision points are reached.

I think the DND Project Approval Directive, our primary reference, does that well enough. I don’t think there are any secrets that I have found that would allow us to do things better or more quickly, while still addressing all the elements that are asked of us. The successful project will be one that follows the process, is well-prepared for each upcoming gateway or decision point, and has a cohesive and well-synchronized project team and stakeholders.

Have you learned a ‘best approach’ for developing requirements? Are there steps you take to ensure they are sound from the outset?

I think that the Army’s project directors do a good job of building a project based on sound and justifiable requirements. We start with critical, high-level requirements, which are refined and developed in more detail as a project progresses. At various stages we are required to explain and defend our choices, to a number of Canadian Armed Forces (CAF) as well as external oversight bodies. That helps us stay on track and resist the urge to reverse engineer a desired solution, or to ‘situate the estimate,’ as we like to say.

One of the key steps is to make sure that we are trying to solve the right problem. Some capabilities or objectives could be met many ways, or could encompass wide ranging capabilities or suites of equipment. So, when starting out, it is critical to ensure we have a good understanding of what it is we are trying to achieve, what is in the scope of a project and what is not. We can’t expect unlimited funding or significant changes to force structures or staffing unless the larger organization is aligned to do so.

All our projects need to find linkage to policy documents like SSE, as well as future force development requirements defined by the CAF and the Army. We rely heavily on this wider force development community to help us figure out what gap or deficiency we are trying to address with an equipment project.

The Ground Based Air Defence project is a good example. With the release of SSE, the project received the policy coverage required for us to start work in earnest. But our experience with air defence was based on our previous systems that were oriented towards the defence of airfields in Europe during the Cold War. So, before we decided what the project would focus on, we worked closely with the force development teams in the CAF, and in particular, the Canadian Army Land Warfare Centre, to help us narrow our focus. This ensured that we were pursuing the right capability to fit in the envisioned army of the future. Based on the high-profile nature of this project, we ensured that our planning assumptions were in alignment with the expectations of the leadership of the Army and the CAF, ahead of more formal project approval gateways. Once we had this endorsement and a conceptual idea of what kind of capability we were after, we could then go about the work of developing detailed technical requirements that are needed.

Members participate in the Combat Team Commander Course at 3rd Canadian Division Support Base Detachment Wainwright in October 2021. Photo: Cpl Djalma Vuong-De Ramos

Solving the right problem is no small task when you are acquiring technology that can change dramatically well before you have delivered the final solution.

Ideally, because we take those high-level mandatory requirements (HLMR) and refine them out in further detail, we still should be limiting ourselves to what it is we want the solution to be able to do. We tend to keep it requirements-based as opposed to solutions-based. Theoretically, if we were to replace the tank, the default would be another tank. We might be tempted to write a requirement to fit a tank when we should be talking about wanting something to project fire, defeat certain types of targets and cross certain types of terrain. And if industry comes to us with a solution that does everything we need it to do, but isn’t a tank, that should meet the requirement.

I think we try to define our requirements to describe what it is we need to do, and then leave it up to industry as to how to do it. But that is still us going down a specific path where we are setting these requirements down on paper. We are trying to find ways to be more iterative in our development and avoid writing requirements that only capture what is available today. But it’s a challenge because our process is driven by us nailing everything down to the nth detail. Our ability to go to a cloud network company and say, ‘provide us a service that lets us talk and have situational awareness, you tell us how to do it’ – we are probably not quite there yet.

Are you better able to challenge some of the assumptions about how technology will ultimately affect a future capability as a project is being analyzed and defined?

I think that’s where HLMRs and organizations like the Independent Review Panel for Defence Acquisition will help us. The HLMRs set out the capabilities we are trying to achieve: Our command and control (C2) system will have to be interoperable, provide awareness across the battlefield, allow us to communicate, and do all this while allowing us to be efficient with power. We shouldn’t be saying, it has to be done with lithium batteries or solar power. The problem is that at some point those HLMRs are refined into detailed requirements and if we don’t tell industry what we want, we might not get what we are looking for. It is a balancing act.

Maybe our next C2 system doesn’t need a bunch of radio towers and servers and Signals Operators plugging in wires every time we go somewhere. Maybe it can all be done through direct links with satellites and our phones. But some of that is going to be a service, and a different type of procurement strategy from a different implementer. I wonder if some of our projects need to move from a capital equipment focus to a different procurement strategy approach.

Is that even more problematic when you must factor in systems integration and interoperability very early in a project?

Interoperability and integration are key elements, and if there was an easy solution, I think we would have found it by now. In the past, we left it up to the individual project to make decisions about what level of interoperability would be acceptable, and where it might not be achievable, and what trade-offs would be in order. The approach today is that we are asking projects to ensure these considerations are included much earlier in the process. Interoperability is now oftentimes a high-level requirement, and not something to be done at a later stage.

It is a really challenging problem space. We have to decide what level of interoperability we are seeking.  Is it within the larger CAF joint force? With some key allies or all potential future partners? There is such a large number of references and standards that can be used to help align efforts, but not everyone adheres to the same ones. Which ones do we choose to focus on? So, we are working to prioritize interoperability, but similar to our requirements development, we need to clearly define our interoperability objectives and partners, and then work to build a system that works with them.

Do software-defined solutions make that easier or is there still a challenge in first understanding who you need to be interoperable with?

It is a challenge. In the past we defined a radio and then tried to talk to somebody, and you could do that because the frequency was the frequency. You now have to have the right crypto. Before we went to a software-defined radio, the waveform that provided the security was on a circuit card you couldn’t change. Now it is less of a hardware challenge and more a software challenge. But you still have to define who it is you want to talk to. The Army, Navy and Air Force have their own C2 systems. Even the American Army, I don’t think, is interoperable 100 percent as different regional commands prioritize interoperability with their different regional partners. So which part of the U.S. Army do you need to be interoperable with?

And that is only one ally. You can draw the circle larger with ABCANZ (America, Britain, Canada, Australia and New Zealand) armies or even bigger with NATO, which is 30 nations plus the partners. NATO is the gold standard, it has a comprehensive and broad standardization agreement (STANAGS) program, but not every nation follows those STANAGS. So, we have to figure out who it is we are trying to be interoperable with and that is not easy.

The fact that we will have a software-defined system should allow us to plug different systems together even if we need an adapter or a black box to do the translation between them, as opposed to a man in the loop who has to look at one screen and type stuff onto another because there is an air gap.

MCpl Hellen Liu, Water, Fuel and Environmental Technician, records data on the Reverse Osmosis Water Purification Unit during Operation Lentus in Iqaluit, Nunavut in November 2021. Photo: MCpl Jax Kennedy

Are more projects moving toward cycles or spirals to introduce and upgrade technology over time?

This is definitely something we have been working towards, and the project approval process does have a cyclical model that allows us to take a more iterative approach in some cases. But it is still a model that is defined by a limited timeframe, and formal approval gateways, so it is not necessarily a completely agile or open-ended system of continuous upgrades.

In general, I think our process was developed for an industrial age, where we can spend a lot of time and effort to develop a well-justified and researched solution, and then field a reliable piece of machinery or equipment that can be used for 20 plus years. We obviously can’t do that with our C2 systems, and in many cases, even more traditional capabilities like vehicles that are dependent on that highly perishable high technology.

So, yes, we are looking at ways to provide a more agile or iterative process to capability development, and then capability lifecycle management, to ensure we aren’t investing time, effort, and funds into a capability that will be obsolete before it delivers. It is something we talk about often, and I think all involved understand the challenge, and are working on finding solutions.

Are you seeing value with early experimentation and buy-and-try with troops to develop requirements?

 We will take any input, experience, and opportunity we can get to help us improve our final product. Trials or buy and try give us the chance to get a close look at what kind of solutions are available now, get feedback from operators or experts, and then use the results to inform our requirements development. Army project directors don’t write a statement of operational requirements in isolation, and there is a significant amount of consultation, research, and analysis that goes into the process.  Being able to add a more hands-on or substantive perspective of what works and what doesn’t, can only help. When we can do this with more developmental or pre-production equipment, that helps us ensure we have a good understanding of what the state of technology might be by the time it comes to develop or deliver a new capability, and then we can use that insight to better develop our requirements.

Suivre le processus

Désolé, mais il n’y a pas de secret pour accélérer le processus d’approvisionnement en équipement de l’Armée canadienne. Après presque quatre années comme Directeur – Besoins en ressources terrestres (DBRT), l’un de ceux comptant le plus d’années de service de récente mémoire, le colonel Chris Renahan a acquis une bonne compréhension de la façon dont la capacité est produite. S’il y a une formule secrète, il ne l’a pas trouvée.

Si vous voulez faire avancer un projet vite et efficacement, le moyen le plus rapide est de suivre le processus. C’est une citation paraphrasée d’un ancien coordonnateur du DBRT, Greg Burton, qui demeure vraie. « Chaque fois que vous essayez de faire quelque chose différemment, c’est un coup de dés », souligne le col Renahan.

Il a décrit le rythme du travail à la DBRT comme étant le plus intense qu’il ait connu et comparable aux efforts d’appui lors des périodes d’opérations à rythme élevé. Malgré deux années de perturbations liées à la pandémie qui ont limité les réunions en personne avec les intervenants, y compris ceux de l’industrie, la direction a fait avancer une partie non négligeable de ses projets aux étapes d’identification et d’analyse des options (AO). Elle a livré la système d’abri pour le quartier général, entrepris la production des véhicules blindés de soutien au combat et a mis en service les derniers camions du système de véhicule de soutien moyen de modèle militaire normalisé. Bien que ces projets et d’autres aient passé l’étape de la définition et jusqu’à la mise en œuvre, le gros des projets qui ont été lancés avec la publication de Protection, Sécurité, Engagement (PSE) – soit environ la moitié de quelque 40 projets – est en cours ou à la fin de l’étape d’AO.

Alors, pour trouver la réussite parmi des projets qui peuvent prendre plus d’une décennie à porter des fruits, ça exige de voir loin. « Ma satisfaction au travail, je dois la trouver dans les petites victoires, comme l’atteinte d’un jalon clé, qui sont invisibles pour la plupart des gens et ne font pas les gros titres parce qu’elles sont presque en totalité d’ordre procédural », admet le col Renahan, qui s’installe pour un cours de cinq mois au Collège de défense de l’OTAN à Rome (Italie) qui, avec quelques cours du Collège des Forces canadiennes, lui donneront l’équivalent du Programme de sécurité nationale du Canada.

Entre les courses à l’épicerie à Rome et les travaux scolaires le soir, il a réfléchi au processus d’approvisionnement et aux défis posés par la technologie qui évolue rapidement.

Je ne suis pas certain si c’est rafraîchissant ou décourageant d’apprendre qu’il n’y a pas de raccourcis ni de nouvelle méthode pour faire avancer les projets plus rapidement à travers les divers points de passage. Qu’est‑ce qui fonctionne, et pourquoi?

Je crois que nous espérons souvent trouver des moyens d’accélérer un projet donné, mais souvent, ces solutions entraînent davantage de travail lorsque ce ne sont pas toutes les personnes concernées qui comprennent l’intention ou le raisonnement d’une déviation de la voie normale. 

Un élément clé est la collaboration précoce, fréquente et étroite avec les nombreux intervenants concernés. Ça commence par les directeurs de projet de l’Armée qui établissent une relation étroite avec leur équipe de gestion de projets du Groupe des matériels, mais ça comprend aussi tous les contributeurs internes de la Défense nationale (MDN) et les superviseurs du projet, ainsi que les autres ministères qui sont nécessaires pour permettre au projet de réussir. Intégrer tôt cette vaste équipe d’intervenants aide ceux-ci à comprendre ce que nous essayons de faire et d’obtenir leurs observations avant qu’on ait atteint les points de décision cruciaux.

Je crois que Ia Directive d’approbation des projets du MDN, notre référence principale, le fait assez bien. Je ne pense pas qu’il y ait des secrets que j’aurais trouvés qui nous permettraient de faire les choses mieux et plus rapidement, tout en nous attaquant à tous les éléments qui nous sont demandés. Le projet qui réussit est celui qui suit le processus, qui est bien préparé pour chaque point de passage à venir ou point de décision, et a une équipe de projet et des intervenants cohésifs et bien synchronisés.

Avez-vous appris une « approche exemplaire » pour élaborer les exigences? Y a‑t‑il des étapes à franchir pour garantir qu’elles soient fondées d’entrée de jeu?

Je crois que les directeurs de projet de l’Armée font un bon travail lorsqu’il s’agit de monter un projet reposant sur des exigences solides et justifiables. Nous commençons par des exigences essentielles de haut niveau, qui sont raffinées et élaborées plus en détail au fil de l’évolution du projet. À diverses étapes, nous devons expliquer et faire valoir nos choix à un certain nombre d’organismes de supervision des Forces armées canadiennes (FAC) et de l’extérieur. Cela nous aide à garder le cap et à résister à l’envie de déconstruire une solution souhaitée ou de « situer l’estimation », comme on dit.

L’une des étapes clés pour faire en sorte d’essayer de régler le bon problème. Certaines capacités ou certains objectifs pourraient être atteints de bien des façons ou pourraient englober des capacités à grande portée ou des suites d’équipement. Alors quand on commence, il est essentiel de veiller à avoir une bonne compréhension de ce que nous tentons d’atteindre, de ce que comporte la portée du projet et ce qu’elle ne comporte pas. Nous ne pouvons pas nous attendre à des fonds illimités ou à d’importants changements à la structure de la force ou à la dotation, à moins que la plus grande organisation soit orientée en ce sens.

Tous nos projets doivent avoir des liens avec des documents politiques, comme PSE, ainsi qu’aux exigences futures en matière de développement de la force définies par les FAC et l’Armée. Nous nous fions largement à la grande collectivité du développement de la force pour nous aider à cerner quelle lacune ou déficience nous tentons de combler avec un projet d’équipement.

Le projet de défense aérienne basée au sol est un bon exemple. Grâce à la publication de PSE, le projet a reçu la couverture politique requise pour nous permettre de commencer les travaux sérieusement. Mais notre expérience avec la défense aérienne reposait sur nos systèmes antérieurs qui étaient orientés vers la défense des aérodromes en Europe durant la guerre froide. Alors, avant de décider sur quel projet nous concentrer, nous travaillions avec les équipes de développement de la force dans les FAC et, en particulier, le Centre de guerre terrestre de l’Armée canadienne, pour nous aider à préciser notre analyse. Cela garantissait que nous recherchions la bonne capacité à intégrer à l’armée de l’avenir qu’on concevait. Selon la nature très médiatisée du projet, nous veillions à ce que nos hypothèses de planification concordaient avec les attentes de la direction de l’Armée et des FAC, en avance des points de passage plus officiels de l’approbation du projet. Une fois que nous avions cet aval et une idée du genre de capacités que nous recherchions, nous pouvions ensuite nous attaquer aux travaux d’élaboration des exigences techniques détaillées qui sont nécessaires.

The Army’s new medium range radar.

Régler le bon problème n’est pas une mince affaire lorsqu’on acquiert de la technologie qui peut changer dramatiquement, bien avant qu’on ait livré la solution finale.

Idéalement, parce que nous prenons ces exigences obligatoires de haut niveau (EOHN) et nous les précisons plus en détail, nous devrions encore nous limiter à ce que nous voulons que la capacité puisse faire. Nous avons tendance à demeurer axés sur les exigences plutôt que sur les solutions. En théorie, si nous devions remplacer le char, la capacité acquise serait un autre char. Nous pourrions être tentés de rédiger une exigence pour correspondre à un char, alors que nous devrions dire que nous voulons quelque chose pour effectuer des tirs, vaincre certains types de cibles et franchir certains types de terrain. Et si l’industrie nous présente une solution qui fait tout ce qu’on demande, mais que ce n’est pas un char, cela devrait satisfaire à l’exigence.

Je crois que nous tentons de définir nos exigences pour décrire ce que nous avons besoin de faire, puis laissons l’industrie décider comment le faire. Mais c’est quand même nous qui empruntons une voie spécifique lorsque nous consignons ces exigences sur papier. Nous essayons de trouver des moyens d’être plus itératifs lors de l’élaboration et d’éviter de rédiger des exigences qui ne tiennent compte que de ce qui est disponible actuellement. Mais c’est un défi, parce que notre processus dépend de ce que nous établissions tout jusqu’au moindre détail. Notre capacité à nous tourner vers une entreprise de réseau infonuagique et dire « fournissez‑nous un service qui nous permet de parler et d’avoir une connaissance de la situation, vous nous direz comment faire » – nous ne sommes probablement pas encore rendus là.

Êtes-vous mieux en mesure de remettre en question certaines hypothèses quant à la façon dont la technologie compromettra ultimement une capacité future lorsqu’un projet est analysé et défini?

Je crois que c’est là que les EOHN et les organisations comme la Commission indépendante d’examen des acquisitions de la Défense nous aideront. Les EOHN établissent les capacités que nous tentons d’atteindre : notre système de commandement et contrôle (C2) devra être capable d’interopérabilité, fournir une connaissance de la situation à l’échelle du champ de bataille, nous permettre de communiquer, et de faire tout ça tout en nous permettant d’être efficaces sur le plan de la puissance. Nous ne devrions pas dire qu’il faut que ce soit fait avec des piles au lithium ou à l’énergie solaire. Le problème, c’est qu’à un moment donné, les EOHN sont précisés dans des exigences détaillées, et si nous ne disons pas à l’industrie ce que nous voulons, il se peut que nous n’obtenions ce que nous cherchons. C’est une question d’équilibre.

Peut‑être que nos prochains systèmes de C2 n’ont pas besoin de beaucoup de tours radios et de serveurs et que les opérateurs des transmissions branchent des fils chaque fois qu’on va quelque part. Ça pourrait peut‑être passer par des liens directs avec des satellites et nos téléphones. Mais une partie de cela sera un service, et un type de stratégie d’approvisionnement différent d’un autre exécutant. Je me demande si certains de nos projets doivent passer d’une orientation sur les biens d’équipement à une démarche différente en matière de stratégie d’approvisionnement.

Est-ce encore plus problématique lorsque vous devez tenir compte de l’intégration et de l’interopérabilité des systèmes très tôt durant le projet?

L’interopérabilité et l’intégration sont des éléments clés, et s’il y avait une solution facile, je crois que nous l’aurions déjà trouvée. Dans le passé, nous laissions aux gens du projet la prise de décisions concernant le degré d’interopérabilité qui serait acceptable, et ce qui pourrait ne pas être réalisable, et quels compromis s’imposeraient. Aujourd’hui, la démarche consiste à demander aux responsables des projets de veiller à ce que ces considérations soient incluses beaucoup plus tôt dans le processus. Maintenant, l’interopérabilité est souvent une exigence de haut niveau, et non quelque chose qui peut être traité à un stade ultérieur.

C’est réellement un espace de problème difficile. Nous devons décider du degré d’interopérabilité que nous recherchons. Est-ce au sein de l’ensemble de la force interarmées des FAC? Avec certains alliés clés ou tous les éventuels partenaires futurs? Il y a un si grand nombre de références et de normes dont on peut se servir pour aider à harmoniser les efforts, mais tout le monde n’adhère pas aux mêmes. Quels sont ceux sur lesquels nous choisissons de nous concentrer? Alors, nous nous efforçons de prioriser l’interopérabilité, mais comme pour l’élaboration des exigences, nous devons clairement définir nos objectifs et partenaires d’interopérabilité, puis créer un système qui fonctionne avec eux.

Les solutions définies par logiciel facilitent-elles les choses ou est‑il encore difficile de comprendre d’abord avec qui vous devez atteindre l’interopérabilité?

C’est difficile. Dans le passé, nous définissions une radio, puis nous entions de parler à quelqu’un, et nous pouvions faire ça parce qu’une fréquence, c’est une fréquence. Maintenant, vous devez avoir la bonne crypto. Avant, nous allions vers une radio définie par logiciel, la forme d’ondes qui assurait la sécurité était sur une carte de circuit qu’on ne pouvait pas changer. Maintenant, c’est moins difficile sur le plan matériel et plus difficile sur le plan logiciel. Mais vous devez encore définir à qui vous voulez parler. L’Armée, la Marine et l’Aviation ont leurs propres systèmes de C2. Je crois que même l’Armée des États‑Unis n’est pas interopérable à 100 pour cent, puisque différents commandements régionaux priorisent l’interopérabilité avec leurs différents partenaires régionaux. Alors, avec quelle partie de l’Armée des É.‑U. devez-vous être interopérable?

Et ce n’est qu’un seul allié. Vous pouvez tracer un plus grand cercle avec les armées de l’ABCANZ (États‑Unis, Grande‑Bretagne, Canada, Australie et Nouvelle‑Zélande) ou même plus grand avec l’OTAN, qui compte 30 pays, plus les partenaires. L’OTAN est la norme de référence, elle a un programme exhaustif et vaste d’accords de normalisation (STANAG), mais ce ne sont pas tous les pays qui respectent ces STANAG. Alors, nous devons trouver avec qui nous devons être interopérables et ce n’est pas simple.

Le fait que nous aurons un système défini par logiciel devrait nous permettre de brancher différents systèmes ensemble, même si nous avons besoin d’un adaptateur ou d’une boîte noire pour effectuer la translation vers eux, par opposition à une personne dans la boucle qui doit regarder un écran et taper des informations sur un autre ordinateur parce qu’il y a un isolement physique.

Y a‑t‑il davantage de projets qui vont vers les cycles ou les spirales pour introduire et moderniser la technologie au fil du temps?

Nous avons certainement travaillé en ce sens, et le processus d’approbation de projet a, de fait, un modèle cyclique qui nous permet d’avoir une approche plus itérative dans certains cas. Mais ça demeure un modèle qui est défini par un délai restreint et des points d’approbation officiels, alors ce n’est pas nécessairement un système de modernisation continue totalement agile ou extensible.

En général, je crois que notre processus a été créé pour une ère industrielle, où l’on peut consacrer beaucoup de temps et d’effort à développer une solution bien étayée et documentée, puis mettre en service une pièce de machinerie ou d’équipement qui peut servir pendant 20 ans et plus. Nous ne pouvons manifestement pas faire ça avec nos systèmes de C2, et dans bien des cas, avec des capacités encore plus traditionnelles, comme les véhicules qui dépendent de cette haute technologie très périssable.

Alors oui, nous cherchons des moyens de produire un processus plus agile ou itératif pour développer les capacités, puis de gérer leur cycle de vie, afin de garantir que nous n’investissons pas du temps, des efforts et des fonds dans une capacité qui sera obsolète avant d’avoir été livrée. Nous en parlons souvent, et je crois que toutes les parties concernées comprennent la difficulté et qu’elles s’efforcent de trouver des solutions.

Voyez‑vous l’utilité d’une expérimentation précoce et d’un achat et essai avec les soldats pour élaborer les exigences?

Nous prenons toutes les observations, expériences et occasions qui s’offrent à nous pour améliorer notre produit final. Les essais ou les achats et essais nous donnent la chance de voir de près le genre de solutions qui sont offertes actuellement, d’obtenir de la rétroaction des opérateurs ou experts, puis d’utiliser les résultats pour nous éclairer lors de l’élaboration des exigences. Les directeurs de projet de l’Armée ne rédigent pas un énoncé des besoins opérationnels en vase clos; le processus compte beaucoup de consultations, de recherches et d’analyses. Le fait de pouvoir ajouter une perspective plus pratique ou fondamentale de ce qui fonctionne et ne fonctionne pas ne peut qu’être utile. Quand nous pouvons faire cela avec de l’équipement davantage en cours de développement ou en préproduction, cela nous aide à avoir une bonne compréhension de ce que peut être l’état de la technologie au moment où on en vient à développer ou livrer une nouvelle capacité, et puis nous pouvons utiliser cet éclairage pour mieux élaborer nos exigences.