High Volume Transport

Vital transport research to ensure accessible, affordable and climate friendly transport for all.

Component B: Update and extend the December 2020 Business Plan for HDM‐4 – Final Report


This report is the Final Business Plan Report for the study “Component B: Update and extend the December 2020 Business Plan for HDM-4”. The document is the final deliverable in the study and builds upon the D3: Draft Business Plan Report, with updates reflecting further findings from research undertaken by Hodos on the parallel Component A User Survey study, and any feedback from the HDM-4 Steering Committee members on the previous study deliverables.


Publications with the same themes

View all


Publications with the same study countries

View all

PDF content (text-only)

Component B: Update and extend the December 2020 Business Plan for HDM ‐ 4 Final Business Plan Report March 202 3 Contract: HVT051 - Comp B Services Agreement final This research was funded by UKAID through the UK Foreign, Commonwealth & Development Office under the High Volume Transport Applied Research Programme, managed by DT Global UK . The views expressed in this report do not necessarily reflect the UK government’s official policies . Reference No. HVT/ 051 Lead Organisation/ Consultant Hodos Media Limited Partner Organisation(s)/ Consultant(s) NA Title Final Business Plan Report Type of document Project Report Theme Technology and Innovation Sub - theme HDM - 4 Author(s) Mick Sear, Kevin Prescott (Hodos Media Limited) , Graham Hutchins NCL Ventures Ltd. Lead contact Kevin Prescott Geographical Location(s) Global Abstract This report is the Final Business Plan Report for the study “ Component B : Update and extend the December 2020 Business Plan for HDM-4 ”. The document is the final deliverable in the study an d builds upon the D 3 : Draft Business Plan Report, with updates reflecting further findings from research undertaken by Hodos on the parallel Component A User Survey study, and any feedback from the HDM - 4 Steering Committee members on the previous study deliverables. Keywords HDM - 4, Business Plan, Strategic Plan, Cloud Migration, Strategy, Operational Planning Funding The Foreign, Commonwealth & Development Office (FCDO) Acknowledgements Cover i mage courtesy HDMGlobal , HDM - 4 sales data courtesy of HDMGlobal Issue Status Author(s) Reviewed By Approved By Issue Date 1 Final Mick Sear / Graham Hutchins Kevin Prescott Kevin Prescott 24 March 202 3 1 Final Mick Sear/ Graham Hutchins Kevin Prescott Kevin Prescott 28 March 202 3 i FINAL BUSINESS PLAN REPORT CONTENTS Executive Summary i i 1. Introduction 10 2. Background 11 3. Product Outline 12 4. Mission, Objectives, Strategy and Tactics (MOST) 14 4.1 Mission 14 4.2 Objective 14 4.3 Strategy 14 4.4 Tactics 14 5. Market Analysis 15 5.1 Current Market 15 5.2 Market Growth 18 5.3 Market Profitability 18 5.4 Market Trends 18 5.5 Target Market 19 6. Competitor Analysis 21 6.1 Competitor Identification & Comparison 21 6.2 Key Findings 23 7. Sales & Marketing Plan 25 7.1 Branding 25 7.2 Sales Plan 25 7.2.1 Sales Pipeline Creation 25 7.3 Marketing 26 7.4 Product Marketing 26 7.5 Pricing 27 7.6 Getting to the First Purchase Order 27 7.7 Building the Sales Pipeline 28 7.8 Target Launch Date 28 8. Organisational Plan 29 8.1 Organisation Form 29 8.1.1 Technical Advisory Group 30 8.2 Business Legal Form and Ownership 30 8.3 Critical Success Factors and Key Performance Indicators 31 8.4 Key External Contacts 32 8.5 Office Locations 32 9. Operating Plan 33 9.1 Production Process 33 9.2 Defining the Minimal Viable Product 33 9.3 Testing 35 9.4 Software development and scale up plan 35 9.5 Cloud Migration Plan 36 9.5.1 Current Codebase 36 ii FINAL BUSINESS PLAN REPORT 9.5.2 Data Sovereignty, Security, and Connectivity in a Cloud - based HDM - 4 Deployment 36 9.5.3 System Value 37 9.6 Scope 37 9.6.1 Roadmap to a Centrally Managed Codebase 38 9.6.2 Lightweight RAMS System 39 9.6.3 Overall Project Delivery Approach 39 9.6.4 Development Team & Costs 40 9.6.5 Solution Design Overview 42 9.6.6 Indicative Pricing for Operational Running 45 9.7 Legal and IP Strategy 47 9.8 Overseas Market Access 47 9.9 Supply Chain Management 47 9.10 SWOT Analysis 47 10. Alternative Revenue Streams 48 10.1 Upselling and cross - selling 48 10.2 Partnering with Other Companies 49 10.3 Licensing HDM Technology 49 10.3.1 API Fee Structure 50 10.3.2 API Revenue Model 51 10.4 HDM Training Provision 51 10.4.1 Training Fee Structure 53 10.4.2 Training Revenue Model 53 10.5 Accreditation Revenue 54 10.5.1 Training Accreditation 54 10.5.2 Consultant Accreditation 55 10.5.3 Academic Accreditation 56 10.5.4 Accreditation Fee Structure 56 10.5.5 Accreditation Revenue Models 57 11. Risks, Assumptions, Issues and Dependencies 58 11.1 Risks 58 11.2 Assumptions 59 11.3 Issues 60 11.4 Dependencies 60 12. Financials 62 12.1 Assumptions 62 12.2 Revenue & Earnings 63 12.3 Cashflow Analysis 64 12.4 Cashflow Forecast 65 12.5 Profit & Loss 66 12.6 Balance Sheet Analysis 67 12.7 Employee Costs 68 iii FINAL BUSINESS PLAN REPORT TABLES Table 6 - 1 RAM systems that claim to interface with HDM - 4 ................................ ................................ .............. 21 Table 6 - 2 Systems that have functions similar to HDM - 4 ................................ ................................ ................... 21 Table 6 - 3 Systems that explicitly mention operation in developing countries ................................ ................... 22 Table 6 - 4 Systems Used by End Users ................................ ................................ ................................ ................ 23 Table 8 - 1 Roles & Responsibilities ................................ ................................ ................................ ...................... 29 Table 9 - 1 Expected Roles and Market Rates ................................ ................................ ................................ ....... 40 Table 9 - 2 System Components Key ................................ ................................ ................................ .................... 43 Table 9 - 3 Interface Components Key ................................ ................................ ................................ .................. 44 Table 9 - 4 Indicative Pricing by Architecture Component ................................ ................................ ................... 46 Table 11 - 1 Risk Log ................................ ................................ ................................ ................................ ............. 58 Table 11 - 2 Assumptions Log ................................ ................................ ................................ ............................... 59 Table 11 - 3 Issues Log ................................ ................................ ................................ ................................ .......... 60 Table 11 - 4 Dependencies Log ................................ ................................ ................................ ............................. 60 FIGURES Figure 5 - 1 Historic HDM - 4 Sales by Region 15 Figure 5 - 2 Historic HDM - 4 Sales by Type 16 Figure 5 - 3 Country wise Breakdown of Recent HDM - 4 Licenses Sold 16 Figure 5 - 4 Cumulative Sales by Country type 17 Figure 5 - 5 Recent HDM - 4 Sales by Type 17 Figure 5 - 6 Number of HDM - 4 License Sales over the HDMGlobal Concession Period 19 Figure 5 - 7 HDM - 4 TAM, SAM, SOM 20 Figure 7 - 1 Launch Milestones 28 Figure 8 - 1 Organisation Plan 29 Figure 8 - 2 Key Perspectives 31 Figure 8 - 3 Key Performance Indicators 31 Figure 9 - 1 Standard Software Development Lifecycle 33 Figure 9 - 2: Clustering of User Requirements 34 Figure 9 - 3 Software Testing Phases 35 Figure 9 - 4 DevOps Approach to Software Improvement 35 Figure 9 - 5 High Level System Architecture 42 Figure 9 - 6 HDM - 4 SWOT Analysis 47 Figure 11 - 1 HDM - 4 Risks, Assumptions, Issues and Dependencies 61 Figure 12 - 1 Revenue and Earnings 63 Figure 12 - 2 Cashflow Analysis 64 Figure 12 - 3 Cashflow Forecast 65 iv FINAL BUSINESS PLAN REPORT Figure 12 - 4 Profit & Loss 66 Figure 12 - 5 Balance Sheet Analysis 67 Figure 12 - 6 Employee Costs 68 v FINAL BUSINESS PLAN REPORT ABBREVIATIONS /ACRONYMS ADB Asian Development Bank AfDB African Development Bank API Application Programming Interfaces ARRB Australian Roads Research Board BIM Building Information Modelling CAGR Compound Annual Growth Rate CRRI Central Road Research Institute CSF C ritical S uccess F actors DFID Department for International Development DoD Department of Defence dTIMS Deighton Total Infrastructure Management System EIRR Economic Internal Rate of Return FCDO Foreign, Commonwealth and Development Office FISITA Fédération Internationale des Sociétés d'Ingénieurs des Techniques de l'Automobile FUT Friendly User Trials GDP Gross Domestic Product GFDT Global Facility to Decarbonise Transport GHG Green House Gas GNSS Global Navigation Satellite Systems HDM Highway Development and Management Model HVT High Volume Transport ICH Institute of Cement and Concrete (Instituto del Cemento y del Hormigón) IDB Inter - American Development Bank IFI International Financial Institutions IRF International Road Federation IoT Internet of Things vi FINAL BUSINESS PLAN REPORT IP Intellectual Property IPR Intellectual Property Rights IT Information Technology KOL Key Opinion Leader KPI Key Performance Indicator M&R Maintenance and Rehabilitation MDB Multilateral Development Bank MLB Multi - Lateral Bank NMT Non - motorised Transport MTBF Mean T ime B etween F ailures MTTR Mean T ime to R epair NPR Net Present Value PA Per Annum P&L Profit and Loss PCI Pavement Condition Index PFC Ponts Formation Conseil PIARC World Road Association PMS Pavement Management System PMT Project Management Team PMU Project Management Unit PPP Public Private Partnership R&D Research & Development RA Road Administration RAM Road Asset Management RED Roads Economic Decision RFP Request for Proposals ROI Return On Investment S/W Software vii FINAL BUSINESS PLAN REPORT SaaS Software as a Service SANRAL South African National Road Agency Limited SAM S erviceable A ddressable M arket SRE Service Reliability Engineer SC Steering Committee SDLC Software Development Life Cycle SLA Service Level Agreement SPADE Systematic PAving DEcision SOM S erviceable O btainable M arket SPV Special Purpose Vehicle TAM Total Addressable Market TRL Transport Research Laboratory USP Unique Selling Point VOC Vehicle Operating Costs WBS Work Breakdown Structure viii FINAL BUSINESS PLAN REPORT EXECUTIVE SUMMARY This updated business plan provides a firm foundation for the sustainable provision of the HDM concept. The objective of this Business Plan is to highlight operational and strategic issues, to mitigate risk, and therefore increases the likelihood of raising the correct amount of fund s required to keep HDM - 4 going. It is not meant to be a prescriptive methodology to be followed precisely by a future management team, rather it provides a range of guidance, tools and supporting data to allow investors, tender ers , senior management, and other stakeholders to make informed decisions as to how to fund, scale and operate the proposed new business. The HDM concept has a long and chequered past and every decade or so the same problems arise regarding IP ownership and requests for redevelopment costs. The only way to break this cycle is to build a new approach to allow the ownership, ongoing development, and management of an entirely new version of HDM - 4 software. The business plan considers expected market penetration levels, the development of new product offerings, the ownership and operational structure of the business as well as offering a view of current market trends, competition, potential risks and suggeste d approaches to sales and marketing. To be clear, there is an opportunity here for a sustainable business, perhaps not of interest to a traditional equity investor, but if HDM - 4 were gone, it would undoubtably be missed by the thriving eco - system it sustai ns. The social good that has been achieved through the use of the HDM - 4 p roduct is difficult to fully quantify. It is endorsed and recommended by the World Bank and other Multilateral Development Banks as the go - to product for appraising road investment in developing countries and has been used to assess over 200 projects since 2008, with an estimated tot al infrastructure value of more than £35 billion. From our discussions with the stakeholders across the HDM - 4 ecosystem, it is apparent that the social value of HDM - 4 is very high, and the brand of HDM - 4 is also held in high esteem, but that the software itself is dated, and there are expectations that it should be further developed and maintained. Furt hermore, it is encouraging that HDM - 4 has generated revenue over its long history , and from an international client base, as these would otherwise be important valuation inflection points in any other busine ss or start - up. In the current climate in early 202 3 , the value of the H DM - 4 application is in the logic rather than the user interface. T here is possibly a market for a combined R oad A sset M anagement S ystem ( RAMS ) and evaluation system, based on our recent survey findings, with many customers using different RAMS alongside HDM - 4 (or none at all) with HDM - 4 providing a regulatory and analytical function that is complementary and parallel to the RAMS in use. We would argue that encouraging this , or at the very least reducing obstacles to future activities in this area, should be the focus of efforts since the modelling and logic component is what drives continued usage of what is an ageing and complex system. In terms of a system design, we should be separating responsibilities to facilitate not only integration opportunities but also to simplify ongoing development compartmentalisation. To achieve this, our recommended approach would be encapsulating the models in an API (application programming interface) which can be monetised externally (e.g., per - use, monthly , etc.) and used for any future RAM system created (or integrated with an existing) as a value - add, rather than sinking funds into an outdated interface where users are required to repeatedly enter data that they may already be managing in their existing RAM S. The future opportunity here is to leverage the HDM brand across lower income countries and use the redevelopment of HDM - 4 as a way to introduce best practice and begin to deploy features associated with RAMS , in the future. However, the most pressing priority is to redevelop HDM - 4 and ensure clean interfaces with existing RAM systems. Our suggestion is that the redesign should allow for the storage of each configuration processed against the HDM algorithms as a discrete data log. These data can be stored in the cloud for future reuse, and accessible to the user via some kind of export method for reuse elsewhere . The log files can also be linked (and shared) to the output report for better accountability and cross referencing. This data facility is included as part of the annual subscription package, but access to the data will eventually be lost if the end user does not continue with their subscription, making the service sticky, and forecast recurring revenues more likely. Assuming the necessary data sharing agreements, which we recognise as non - trivial, can be put in place with the End Users, we see a lot of value in the aggregation of these user log files over time, especially for the World Bank and other Donor organisations. ix FINAL BUSINESS PLAN REPORT It is envisaged now with intellectual property rights secured and with access to adequate funding, then a quality product can be developed over a period of 36 months and be available for launch by end of 202 6 . This is suggested as the target launch date and to offer the opportunity to present the new product, raise awareness and gain momentum in sales. We also envisage a soft launch by mid - 2025 , to iron out any bugs and support legacy user migration. Furthermore, this date should coincide with the end of the next concession extension with the incumbent operator (HDMGlobal). The accompanying financial model has several projections relating to price points, discount structures, market adoption rates and the licensing structure s . T he historic arrangement to give 30% of revenues to PIARC is not sustainable and has been removed. In accordance with our historic work on HDM - 4, our preference remains that HDM - 4 be spun off inside a new Special Purpose Vehicle, operated as a wholly independent entity, free of future obligations. F unding practicalities means that it is likely the project will be tendered out by the World Bank with contractual agreement s put in place to set boundaries, governance , milestones and manage the concept going forward. The arrangement around targets and future revenues/profitability /reinvestment needs to be ca refully considered, with the success ful bidder being both rewarded and incentivised appropriately. A major deviation from the past is to recommend that an annual license fee is charged at £1,500 per annum, per licensed user. Discounts are available based on volumes and commitment. The current perpetual license approach does not offer the ongoing revenue streams required to make this a sustainable product and we continue to advise against this. The business plan is based on a commercially successful software platform hosted as a Software as a Service (SaaS) proposition within the cloud. Operating costs are kept low, and revisions and updates to the software can be undertaken in real time and freq uently, allowing it to evolve. The scope for new modules to address the growing need for other socio - economic transport factors, that can be modelled and incorporated is also supported , however they have not been include d in the business plan , as we expect them to be funded as regional side projects, and/or from future revenues. By moving from an 18 - month to a 36 - month development period with a smaller team, the capital required to create a sustainable business and to reach minimum viable product , increases by half a million pounds, to at least £3 .3 million ($3. 927 m) although a sophisticated tender response from an established entity with pre - existing staff, could undoubtably find cost savings in our budget despite our use of lower end estimates for salaries . This figure allows for solid corporate governance, a development and management team to be recruited , covers working capital, Opex costs and the launch of the software before forecast recurring revenues lead to break - even. This extended development period also provides extra time to incorporate other more advance d models, for example Low Carbon Policies (GHG) have been identified as a priority by our parallel HDM - 4 User Requirements study, as the Multilateral Development Banks have an agreement to only fund projects that are aligned with the Paris Agreement. A further addition to the business plan was a thorough analysis of a lternatives r evenue approaches and models. In line with our recommendations from our research in 2020 we did not anticipate large financial contributions from any of the alternative revenue approaches, and we maintain that the best tactic is to explore in more detail only those that have strategic value and contribute back to the core HDM - 4 sales by better supporting customers, as well as best practice in the sector . Therefore, in the final analysis, licensing the HDM Intellectual Property through APIs, training provision, and accreditation (both for HDM - 4 trainers and consultants) were the three alternative revenue streams that were analysed in more detail , and included in the updated financial model ling . They do not prov ide much in term of revenues, but they do help build critical mass, and the activities contribute to the sales and improved customer loyalty of the core software product. To avoid any confusion the business plan currency is in UK Sterling , with many of the cost estimates based upon a UK location and in sterling, and then the amount requested converted using the exchange rate of 1. 19 USD . We suggest the money is invested upfront, to reduce risk, and give confidence to staff and suppliers, but realise this might not be suitable for some donors, so we have modelled three milestone investments on £1m in years one, two and three, with a final payment of £300k in year four. 10 FINAL BUSINESS PLAN REPORT 1. Introduction HDM - 4 is a Highway Development and Management (HDM) ( version 4 ) software application which serves as a primary tool for the analysis, planning, management and appraisal of road maintenance, improvements, and investment decisions. It is a decision - making tool for assessing the engineering and economic viability of road infrastructure investments, before a large capital commitment is made. The market for a redeveloped HDM - 4 includes national and regional public bodies as well as private organisations from sometimes developed but mostly developing countries. To continue to offer features that make it competitive within the road investment market, and to allow its continued use for appraisal of investment for the purposes of obtaining Multi lateral Development Bank ( MDB ) funding, it is necessary to develop and greatly improve the capabilities, support, and socio - economic relevance of the application. Developed countries consider HDM - 4 and its predecessors as tools intended principally for the developing world. Furthermore, for more than 60 years, most of these countries have produced their own tools, including deterioration models, optimisation algorit hms and analysis procedures that are suitable for their specific needs. Of course, this does not necessarily imply that all the current tools on the market are appropriate to support best practice . They are often expensive and also require extensive consul tant support to use. Many developing countries have adopted the HDM products because its use has been historically a prerequisite of transnational institutions to provide financial support for road projects. At the same time, during the same 60 years, the formal implementation of road management methods in general, and of modern asset mana gement approach es (such as ISO : 55001 1 ) have been quite scarce in these countries. The HDM brand has gained a reputation as a “commercially independent” tool upon which road administrations and Multi - Lateral Banks ( MDB s ) can trust to provide the necessary outputs required to validate substantial funding for road infrastructure programmes. 1 https://www.iso.org/standard/55089.html 11 FINAL BUSINESS PLAN REPORT 2. Background The research is funded by the UK Foreign, Commonwealth & Development Office (FCDO) through the High Volume Transport (HVT) applied research programme, which is managed by DT Global UK. Historically, the management of HDM - 4 was run on a not for profit and best - efforts basis by a small number of dedicated professionals . This is no longer sustainable as demands on the application and its operation have grown substantially. Hodos Media conducted the HVT015 “Preparation of a Business Case for HDM - 4” study between August 2019 and November 2020. The primary objective of that study was to produce a “bankable business plan” for the future of the Highway Development and Management (HDM - 4) software product and exploring all the possible options for putting the ownership, management, and maintenance on a more sustainable and commercial basi s. The updated business plan has now been further amended as the third deliverable (this document) of the study to review and extend the HDM - 4 December 2020 business plan , with additional chapters and an investigat ion into the potential for further lines of revenue . A major change incorporated into the financial modelling and assumptions is a smaller development team resource spread out over a 36 month, rather than a more intensive 18 month development period originally envisage d , at the direction of the Worl d Bank. These studies and discussions have been used to formulate the options, and inform the views expressed, analysed, and presented in this business plan. Finally, whilst we have conducted stress testing of the logic behind this business plan from HDM - 4 stakeholders and the study experts , we must accept that some of the decisions may well be proved wrong in the future, or a new management team will refine, alter, or reject our strategy altogether, as often happens when executing a business plan. However, the approach documented in this bu siness plan is based on our expert opinion, considering all the previous work across all our HDM - 4 stud ies , which we feel w ill likely lead to the most success. 12 FINAL BUSINESS PLAN REPORT 3. Product Outline HDM - 4 is designed to support three main functions of the highway management process, namely planning programming, and preparation. The HDM - 4 analytical framework is based around the concepts of pavement life cycle analysis. This is applied to predict the f ollowing over the life cycle of a road pavement: • Road deterioration . • Road work effects . • Road user effects . • Socio - economic and environmental effects . The rate of pavement deterioration is directly affected by the standards of maintenance applied to repair defects on the pavement surface or to preserve the structural integrity of the pavement, thereby permitting the road to carry traffic in accordance wi th its design function. The long - term condition of road pavements directly depends on the maintenance or improvement standards applied to the road. In addition to the capital costs of road construction, the total costs that are incurred by road agencies will depend on the standards of maintenance and improvement applied to road networks. The accuracy of the predicted pavement performance depends on th e extent of calibration applied to adapt the default HDM - 4 models to local conditions. There are three levels of calibration in HDM - 4: • Level 1 - Basic: This calibration level should be performed for all HDM - 4 analyses and addresses the most critical parameters, while assuming that most of the HDM - 4 default values are appropriate. It is based on secondary sources and is being done through “desk” studies with best estimates and therefore requires minimal field surveys and the time required is low (weeks) . • Level 2 - Verification: It requires moderate data collection or availability with moderate precision and seeks to verify and adjust HDM - 4 predictions to the local observed conditions. This may require field surveys and data collection to obtain the necessa ry data and typically would be refined in subsequent years as the data history builds. This level of calibration requires more resources and time (months) . • Level 3 - Adaptation: This level comprises structured research (medium - term) and advanced data collection over a long time period (years) and may lead to the development of new relationships and models and the need to refine the HDM - 4 software. The impacts of the road condition, as well the road design standards, on road users are measured in terms of road user costs, and other social and environmental effects. Road user costs comprise vehicle operations costs, costs of travel time (for passenger s and cargo) and costs to the economy of road accidents. The social and environmental effects comprise vehicle emissions, energy consumption and other welfare benefits to the population served by the roads. Although the social and environmental effects are often difficult to quantify in monetary terms, they can be incorporated within HDM - 4 economic analyses if quantified exogenously. Road user effects can be calculated for both motorised transport and non - motorised transport. Road User Costs in HDM - 4 are calculated by predicting physical quantities of resource consumption and then multiplying these quantities by the corresponding user specified unit costs. Economic benefits from road investments are determined by comparing the total cost streams for various road works and construction alternatives against a base case ( without project or do minimum) alternative, usually representing the minimum standard of routine maintenance. HDM - 4 is designed to make comparative cost estimates and economic analyses of different investment options. In order to make these comparisons, detailed specifications of investment programmes, design standards, and maintenance alterna tives are needed, together with unit costs, projected t raffic volumes, and environmental conditions. HDM - 4 has three analytical methods; strategy, programme, and project analysis: • Strategic Analysis: This is used for long - term planning and policy development. Strategic analysis is typically focused on identifying the key issues and challenges faced by the road network and developing broad 13 FINAL BUSINESS PLAN REPORT strategies and policies to address them. The outputs of a strategic analysis include recommendations for investments in the road network, its road condition performance and cost profiles based on different budget levels defined by the user. • Programme Analysis: This is used for medium - term road maintenance planning. Programme analysis involves the identification of a list of candidate road maintenance activities that are aligned with the strategic objectives and priorities. The outputs of the programme analysis include a detailed list of proposed road maintenance activities, their estimated costs, and their expected benefits for different budget levels defined by the user. • Project Analysis: This is used for the detailed planning and design of individual road improvement projects. Project analysis involves the evaluation of different maintenance and improvement options, the estimation of total transport costs, and the assessment of the expecte d benefits. The outputs of the project analysis include the road condition performance, cost estimates, and benefit - cost analyses for the individual road project analysed. HDM - 4 is a road infrastructure assessment software tool, utilising several unique algorithms and a broad suite of inputs that allows costed outputs to be generated for the user. The inputs include vehicle classes, vehicle volumes, ax l e weights, local topology and many other factors and variables. The unique algorithms and historic data sets obtained over many years, give HDM - 4 a significant advantage over other products and services. Of particular relevance is that the World Bank and other MDB s stipulate that an assessment using HDM - 4 (or similar) is undertaken before funding for public road infrastructure projects is granted and this provides HDM - 4 with a unique, captive market upon which to develop and grow the product. The product is software - based, written in C++ but was built to run on Windows XP (and prior) operating systems. This greatly limits the current market and customer usability as well as raising significant operating system security and stability issues. The software is also not “connected” in any way, making it difficult to gather analytical data on usage. 14 FINAL BUSINESS PLAN REPORT 4. Mission, Objectives, Strategy and Tactics (MOST) HDM - 4 software operates within a highly specialised business vertical of road infrastructure assessments tools mostly in the developing world. There are very few direct competitors to HDM - 4. 4.1 Mission The mission of the business is to ensure the longevity of HDM - 4 for the common good of people and the environment in road infrastructure projects globally. 4.2 Objective The objective for HDM - 4 is to be the primary cost - benefit analysis software tool of choice for both public and private developers undertaking road infrastructure projects. A stretch objective is to begin to incorporate other features that encompass socio - economic, ecological and sustainability requirements, ready for adoption by lower and middle income countries. 4.3 Strategy The strategy is for a n organisation to run, develop and maintain HDM - 4 to ensure a commercially successful product that can be self - sustaining once established. 4.4 Tactics The tactics that will realise the strategy are: • Undertake a complete software refresh to allow it to be compatible with current operating systems, business environments and security postures. • Migrate the software hosting to a cloud - based ecosystem. • Institute an organisational and technical framework to allow sustainable ongoing software updates. • Move to a recurring license pricing policy. • Undertake sales and marketing activities to promote the software. • Develop additional software capabilities that encompass socio - economic, ecological and sustainability requirements. • Design the software to allow the incorporat ion of a RAM system as a future add - on option . • Arrange for accreditation schemes for HDM - 4 trainers , consultants, and research contributors. T here is an opportunity to collaborate with other software products and software providers in the highly fragmented road asset management software domain , which is analysed in the Competitor Analysis Section 1: 6 . The Unique Selling Point (USP) is that HDM - 4 offers an affordable and accurate estimation of road investment costs and benefits. 15 FINAL BUSINESS PLAN REPORT 5. Market Analysis It is quite challenging to estimate the market for a redeveloped HDM - 4 given its uniqueness. Most of the published market research reports focus on the Asset Management Software markets, of which Highways and Roads Management Software and Systems is a subset. It is useful to understand how HDM - 4 fits into an overall asset management market , in the context of two key resources, the ISO 55000 series and the PIARC Asset Management Manual , which helps to distinguish the differences between an asset management system and HDM - 4 . There are some fundamental differences between road asset management systems and HDM - 4. HDM - 4 can run and compare different budget scenarios to enable policy decisions to be made. Road asset management systems effectively implement the policies chosen and can be used to monitor the impact of those policies over time. Thus, road asset management systems and HDM - 4 are complementary , yet different. R oad asset management systems and HDM - 4 or similar tools can be used by roads organisations at different levels of maturity. HDM - 4 can still be used in organisations at a basic level of maturity, but likely as a one - off exercise by consultants with poor data coverage and quality. As organisations become more proficient, they will implement asset management systems which systematise data collection and quality assurance and provide more automated functions and analyses to develop and update policies and pr ocedures as part of a continual quality improvement program me . 5.1 Current Market The target market for the proposed new business are existing clients such as consultancies and government bodies. There is a longer list of around 3 , 000 historic HDM - 4 users, and this is the primary target market for a newer redeveloped version of the software. Figure 5 - 1 Historic HDM - 4 Sales by Region 16 FINAL BUSINESS PLAN REPORT Figure 5 - 2 Historic HDM - 4 Sales by Type If we dig deeper into the more recent customer base, we see that it remains very fragmented geographically : Figure 5 - 3 Country wise Breakdown of Recent HDM - 4 Li censes S old As can be seen, out of a total of 432 recent licenses sold, despite the good geographic spread, it is very fragmented. T he label “< 5” refers to countries that have between one and four HDM - 4 license and the label “5 to 10” refers to countries where there are between five and ten HDM - 4 license holders (excl uding countries that are separately listed) . If we dig deeper into the countries that have between one and ten HDM - 4 license (representing over half the total number of licenses) we reveal a lengthy list of countries around the world, many holding a single HDM - 4 license. A regional breakdown is provided in Figure 5 - 4 and Figure 5 - 5 below: Spain2%USA3%United KenSouth Africa4%Mexico5%Peru5%Colombia5%Brazil7%India9%< 531%5 to 1022%Country wise breakdown of HDM 4 licenses sold (2018 -2022) 17 FINAL BUSINESS PLAN REPORT Figure 5 - 4 Cumulative Sales by Country type Figure 5 - 5 Recent HDM - 4 Sales by Type Behind the charts, w e also see in the raw excel data that there is an extremely varied (and long) list of different countries that have either one to four or five to ten HDM - 4 licenses. Eastern Europe6%Western Europe and Others16%Africa21%Asia and the Pacific22%Latin America and the Caribbean35%Regional breakdown of HDM 4 license holders (2008 -2022) 18 FINAL BUSINESS PLAN REPORT 5.2 Market Growth According to a commercial report acquired from Orbis Research in 2018 , the global Road Asset Management software market size will grow to $774.41 Million in 2025, from $495.10 Million in 2018, with a CAGR of 6.7% during the forecast period. HDM - 4 is applicable to a subset of this market, and we might expect similar CAGR. To increase the size of the addressable market and to maintain the value of HDM - 4, we envisage adding additional assessment functionality to the application , in the future . The intention is to add metrics and configurations for the following as potentially separate modules: • GHG Emissions . • Road Safety. • Climate Change . • Climate Resilience . • Sensitivity Analysis . • Road Asset Valuation . • Budget Optimisation . • Multi - Criteria Analysis . • Interface to other RAM S . • Non - motorised transport . • Wider Economic Benefits . By including these capabilities (or to integrate with other software packages that offers these analytical enhancements) the product will remain competitive and of substantial value to customers over the medium - and long - term addressing changes in focus of government and suppliers. They also represent opportunities to raise additional finance or grants from organisations interested in these (or other) specific module domains. 5.3 Market Profitability The market for infrastructure projects is of the order of $ 40 billion per annum and offer s a large active market to operate within , particularly in developing countries who rely on the World Bank and other transnational institut ions for funding. HDM - 4 is the leading software used for assessing the viability of most road investments in developing countries , and whilst it is encouraging to see large numbers and a vibrant ecosystem , obviously the spending on physical infrastructure differs from the spending o n the software to manage it (see Section 1: 5.5 below). 5.4 Market Trends The current market for perpetual HDM - 4 licences appears to be getting saturated , despite t he market for road infrastructure programmes grow ing rapidly and with that the need for accurate estimates of costings. In addition, asset management software relevant for such infrastructure program me s has also grown. We can see the “managed decline” in HDM - 4 sales in Figure 5 - 6 below: 19 FINAL BUSINESS PLAN REPORT Figure 5 - 6 Number of HDM - 4 License Sales over the HDMGlobal Concession Period We understand that HDM - 4 as it currently stands is not suitable for continuous asset management, but this is the market it is operating parallel too . We should therefore consider integration capabilities or additional asset management capabilities during the re - design phase. It is important that as we move to an annual license fee model the new software is compelling and as “sticky” as possible. We would also recommend that more ongoing analysis , and perhaps more frequent road network audits (quarterly or annual) could be insisted upon by the MDB stakeholders, where possible . Most deployments of both HDM - 4 and other Road Assets Management Systems appear to be quite ad hoc in nature. MDBs rarely “use” HDM - 4 directly, they only require that recipient countries use it (or rather, something like it) to justify feasibility studies for MDB - funded projects (and by “countries” it is the local RA who will hire consultants to do it on their behalf – most countries will have a pool of local consultants who can do that, or alternatively they will hire an international consultant as part of a Proj ect Management project also funded by the Bank). It is often the case that some of the MDBs do not have enough understanding of HDM - 4 to effectively evaluate the HDM - 4 studies that have been done for them and tend to take them at face value. According to the data of current users, the number of licences held by MDBs is relatively small, as the wo rk itself is often outsourced to consultants , whose quality is highly variable. 5.5 Target Market According to Orbis Research, t he global Road Asset Management Software Market Size will reach $774.41 Million in 2025, from $495.10 Million in 2018. This market number from Orbis Research is simply a starting point of our “TAM SAM SOM” analysis for HDM - 4, where: • TAM or Total Available Market is the total market demand for a product or service. • SAM or Serviceable Available Market is the segment of the TAM targeted by the products and services which is within geographical reach. • SOM or Serviceable Obtainable Market is the portion of SAM that can be captured. 20 FINAL BUSINESS PLAN REPORT Figure 5 - 7 HDM - 4 TAM, SAM, SOM If , According to the Orbis Research Report, the global market is around $500m, and we take the TAM to be the “Highways” element of the market where broadly the global road asset management software market is divided into Highways (38%) and Road & Street (62%) sectors, then the TAM is approximately $190m. The SAM is quite hard to pinpoint, but obviously will be smaller still. Orbis Research have market size estimates by geography. Given the focus of HDM - 4 has been traditionally for road programmes in developing countries, we should exclude North America an d Europe, leaving their estimates for Asia - Pacific $107.93m, South America $33.85m and Middle East & Africa at $20.91m. Again, if we take 38% of the total ($162.69m) we get a Serviceable Available Market of $61.82m. The SOM will be a percentage of the SAM, and the serviceable obtainable market and given the uncertainties is a best estimate for the portion of revenue within a specific product segment that we believe the redeveloped HDM - 4 can capture. Factors that contribute include current reach, product, and competition. When estimating SOM, we have considered historical sales performance, competition, and based on our understanding of the market, we estimate 20% of the market could be captured over three years, which would equate to $12.36m. Although a “guesstimate” we feel t his figure is quite conservative as it ignores any growth, which given the relatively low market base in these regions is probably unfair , despite the lower budgets for such deployments. TAM = $190m SAM = $61.82m SOM = $12.36m 21 FINAL BUSINESS PLAN REPORT 6. Competitor Analysis 6.1 Competitor I dentification & C omparison Most competitors do not have the equivalent capabilities as HDM - 4 but for several companies access to an additional module that simulates the specific algorithms found in HDM - 4 could allow them to offer a more compelling proposition and increase the reach of HDM - 4. From the State of the Art search conducted in a parallel study , we identified thirty three relevant software providers around the world. Of those, six already claim to interface with HDM - 4 ( Table 6 - 1 below). Fourteen have functions similar to HDM - 4 ( Table 6 - 2 below) and five explicitly mention that they implement their systems in developing countries in Africa, Asia, or South America ( Table 6 - 3 below ). Not including TRL, the four other UK software providers (AgileAssets, Compass, Regenerate and XA) include their pricing document on the UK Government website, indicating that their focus is on UK local authorities. Other systems ( e.g., Brightly Software, Global Road Technology, HIMS and Pavement Management Services) pricing strategy is done by individual quotations so the system can be tailored to the customers’ needs and requirements. Most of the other systems do not have any pricing information on their websites. Table 6 - 1 RAM systems that claim to interface with HDM - 4 System Name Interface with HDM - 4 Year Bentley Asset Management System: AssetWise Yes – a Malaysian case study report published in 2020 said that the system used its Digital Twin technology to apply a pavement management system in conjunction with HDM - 4. 2022 Deighton Total Infrastructure Management System C laim that they replicate the HDM - 4 road deterioration models into dTIMS. 2022 HIMS Yes – the website stated in 4 case studies that the pavement management system was based on the HDM - 4 analysis engine. 2015 IRAMS (by EOH/NEXTEC) Yes (according to our case study with the Namibian Roads Authority) 2022 iROADS (TRL Software) Its flexibility allows it to be deployed anywhere in the world, for use with varied survey types, survey machines and integration with HDM - 4. 2022 Maximo by IBM Yes 2022 SATRA Infrastructure Management Services R eseller for HIMS. 2021 Table 6 - 2 Systems that have functions similar to HDM - 4 System Name Functions similar to HDM - 4 Year iROADS (TRL Software) Simplified lifecycle analysis module which can be used instead of HDM - 4 2022 Maximo by IBM Enhances customer return on assets with financial and performance analytics 2022 22 FINAL BUSINESS PLAN REPORT Road Network Evaluation Tools (RONET) Determines the allocation of expenditures among recurrent maintenance, periodic maintenance, and rehabilitation road works. Determines the “funding gap” defined as the difference between current maintenance spending and required maintenance spending. 2020 Pavement Analysis ( AgileAssets ) Analysis scenarios by creating what - if scenarios for analysis comparisons to simplify forecasting and resource allocation 2022 Brightly Software ( Assetic Pty ) Full asset lifecycle prediction modelling and capital planning 2022 Causeway Horizons ( Causeway) Asset lifecycle and scenario modelling 2022 Confirm (Pitney Bowes) / Dude Solutions Lifecycle costing measurements 2021 LogiRoad (by Logiroad) Evaluate the cost of a business to better adjust its profitability 2021 Pavement Maintenance Management System (PAVER) (Colorado State University) The system calculated modelled pavement condition following the implementation and predicts M&R cost avoidance 2022 Ramboll Strategy design and GAP assessments, investment analysis and lifecycle costs, planning and risk analysis 2022 RAMM Software ( Thinkproject ) Maintenance programme periods to review the estimated and claimed costs for the periods to maximise users’ budget and efficiency 2022 Regenerate (Metis Consultants Ltd) Investment modelling 2020 SMEC Pavement Management System Undertakes full lifecycle analysis of treatment options and incorporates financial modelling 2018 XA by XIAS Highway Asset Management Economic prioritisation and whole life costing 2022 Table 6 - 3 Systems that explicitly mention operation in developing countries System Name Explicit mention of operation in developing countries Year Bentley Asset Management System Specifically, India and Asia 2022 Deighton Total Infrastructure Management System America, India, and Asia 2022 HIMS Brazil, Cambodia, India, Japan, New Zealand, Papua New Guinea, Samoa, Serbia, Sri Lanka, UAE, and Zambia Unknown 23 FINAL BUSINESS PLAN REPORT IRAMS (by EOH/NEXTEC) Various African countries including South African municipalities and provinces. 2022 Road Network Evaluation Tools (RONET) Africa and other developing countries 2020 SATRA Infrastructure Management Services India, Mozambique (reseller for HIMS) 2021 6.2 Key F indings The uniqueness of HDM - 4 protects it from direct competition at the moment. However, several companies offer a suite of asset management capabilities which could be quickly enhanced with HDM - 4 type modules. This would give them an immediate competitive advantage and allow them to leap - frog the new HDM - 4 business in terms of target markets and revenue genera tion. It is imperative therefore that the new HDM - 4 business maintains full control of the intellectual property and maintains a roadmap for future development that encompasses new functionality and constant reinvestment and product evolution. All road management businesses can and do target the same markets as HDM - 4, government and commercial entities and most also work with consultancies. A recent survey of HDM - 4 users by Hodos Media between November and December 2022 attracted 81 responses. Respondents identified which other asset management systems they were using ( Table 6 - 4 below) . The most commonly used system is Road Economic Decision Model (24), followed by RONET (14) and ROMDAS (10). Table 6 - 4 Systems U sed by End Users System Name Quantity of respondents that have used it AgileAssets ⴕ 2 AMX 1 Bentley * 1 dTIMS * 2 Icaro Tech 2 iROADS * ⴕ 4 Logiroad 1 PAVER 6 Road Economic Decision Model (RED) 24 Road Scanners 1 Romaps 1 ROMDAS 10 RONET ⴕ 14 24 FINAL BUSINESS PLAN REPORT Sirway** 1 Vaisala 1 WDM 1 Yotta Horizons 1 * indicates that the system claims to interface with HDM - 4 ⴕ indicates that the system has similar functions to HDM - 4 ** Identified in the User S urvey Of the systems identified in our recent user survey, very few claim that they interface with HDM - 4 – this implies that they are manually exporting / importing data from their asset management system to HDM - 4 and conducting all the calculations and transformations manually or by some sort of besp oke interface. The survey responses indicated that none of the respondents to the survey , work for any of the road asset management systems identified in our search, despite inviting them to participate. Finally, after attempting to contact all the RAM system providers yet again, it was felt that the lack of response and commercial awareness is rather low in the sector, which represents an opportunity for a properly resourced sales function . This further reinforces our view that many of the providers in this market are not properly active. 25 FINAL BUSINESS PLAN REPORT 7. S ales & Marketing Plan The sales and marketing activities are critical to the success of the new business. Focus needs to be placed on creating these functions whilst HDM - 4 is redeveloped. A set of parallel activities needs to be established to develop the pipeline, agree the branding and USP and to engage with current and past customers. 7.1 Branding The branding for the new business needs to build on its social good aspect with its historic involvement with the developing world and also, it’s potential for wider, cost - effective use for those same countries with newer features, but with a modern new approach to help support their current and future infrastructure programmes. The USP is that HDM - 4 offers an affordable and accurate estimation of road construction costs and benefits. We support the propose d us e of “HDM - 5” as the new brand, and HDM - 5 should aim to eventually be the Road Asset Management solution of choice for lower - and middle - income countries , but this is some way off in the future, and is not covered by the funds to update HDM - 4 . As a precaution, we have purchased the domain name hdm - 5.com and will happily transfer to the appropriate party when and if needed. 7.2 Sales Plan The following sales functions need to be established as part of the core business formation. A small and highly effective sales team that is familiar with the software and can promote its use including how to input customer data, undertake the analysis an d help interpret the results. There should be a regional assessment of the internal and external pressures that is causing change in potential customers plans. For example, new domestic regulations, socio - economic activities, and the need to reduce costs can all be used to leverage sale s . 7.2.1 Sales Pipeline Creation The pro active (rather than passive) creation of a sales opportunity pipeline is required, and it must be effectively qualified and quantified. For each opportunity, three fundamental questions need to be asked, each with their own subset of questions: • Should we pursue the opportunity? § Does HDM meet the clients business initiative? § Can the client fund the HDM purchase? § What are the client’s reasons for change? • Can we effectively compete for this opportunity? § What is the viability of HDM from the client’s perspective? § What are the sales and implementation resources needed? § What are the specific business values that HDM brings to the client? • Can we reasonably expect to win this opportunity? § What is our ability to impact the client’s decision - making process? § What is our executive credibility and support for this opportunity? § What is our alignment with the relevant client executive? For example, will they be a sponsor, a supporter, neutral, or sponsor a competitor. As part of the sales opportunity pipeline, an assessment of past contact with key client executives is very useful in developing relationships and creating sales. This needs to be undertaken utilising the existing stakeholders of the new HDM - 4 business. Three sales strategies need to be leveraged by the redeveloper of HDM - 4 , depending on the target. • Direct § HDM - 4 has a clear and unique solution fit and is priced to allow LMICs to use it. 26 FINAL BUSINESS PLAN REPORT § There is previous client relationships that can be leveraged. § They can be first o n the scene for new road infrastructure projects. § They can provide swift implementation of the software solution. • Alter § Shifts focus to new buying criteria, such as new regulations that HDM - 4 will meet. § They can address competitor’s weaknesses. • Segment § Limit sales objective to core HDM - 4 functionality accepting that other vendors may be involved in the overall client solution. § This can act a springboard for future opportunities as HDM - 4 is further developed and additional functionality added. § Provides ‘best of breed’ solution where HDM - 4 is utilised for niche purposes only. 7.3 Marketing Substantial investment is required into creating new and fresh marketing collateral. The material should emphasise the redeveloped HDM - 4 benefits in several specific areas, when available, listed below. • Environmental benefits. • Socio - economic benefits. • Cost saving benefits. • New and improved user interfaces. • Compatibility. • Global availability through cloud hosting. • Greater ability to coordinate and share data sets. • Greater security of information. • New and improved support services. 7.4 Product Marketing New updated and refreshed branding, colour palettes, business pantones and graphics need to be designed. Straplines need to be agreed with the P roduct Director and SC but owned and managed by the Marketing & Sales Lead . Once the basic branding is agreed, collateral will be produced. Consistency of look and feel is paramount, along with strong but simple messages to the market. The marketing collateral will include: • New glossy brochures with revised logo, professionally created. • Creation of an entirely new website professionally developed with the ability to update within the business. § A suitable domain name needs to be obtained and secured. § SEO (search engine optimisation) needs to be utilised to improve search term ranking. § Promotions within Google should be considered for terms such as road transport, asset management, and road infrastructure. § Older websites that reference or promote the current version of HDM - 4 should be retired. § A surface scan of the internet for HDM - 4 can be conducted by a third party such as RedWolf which can highlight website that reference HDM - 4 and that can be removed if necessary. § Informative PowerPoints decks that can be presented at conferences including screen shots of the new GUI when available. 27 FINAL BUSINESS PLAN REPORT • New collateral for exhibitions including new stands, posters, freebies, ability to provide demonstrations and simulations. We would expect to start a series of roadshows within a few weeks of the creation of the new arrangements allowing some early visibility to potential friendly user trialists and other stakeholders. Interviews with the new Product Director by trade press will give early awareness to the transport community of the changes that are planned. Once we are close to final launch then full or half page trade press advertising can be used to push potential customers to the new website and capture user data and obtain direct engagement. 7.5 Pricing Pricing is based on a recurring charge with a minimum commitment of 1 year (12 months). Where certain customers, such as Road Authorities wish to purchase a license from Capex rather than Opex budgets, they are able to purchase extra years up front to cover the life of their project. The baseline pricing for core software is set at level to reflect the required return on investment and to allow the business to function. Modelling indicates a standard charge of £1,500 per annum. • Standard prices should be set for each chargeable element of the product: § Base software £1,500 per annum § Modular software add - ons £tbc § RAM module £tbc § Support Services £tbc • Discounted prices should be a fixed percentage on the standard price: Term commitment and discount applied: § 2 year 5% § 3 Year 10% § 4 Year 15% • Volume licence discount applied; § 1 - 5 additional licences 0% § 6 - 10 additional licenses 5% § >10 additional licenses 10% • Education establishments are provided a discount of 25% fixed. § Discounts are additive. Maximum discount to any customer is 25%. Examples: • A client purchasing 1 license for 3 years would pay £4,050 after discount. • A client purchasing 12 licenses for 4 years would pay £54,000 after discounts. 7.6 Getting to the First Purchase Order The use of friendly user trials (FUT) is needed to ensure the redevelopment of HDM - 4 is meeting End User expectations . Early adopters that are willing to provide proactive feedback and participate in friendly user trials will be provided the software free of charge until the time of commercial (hard) launch. Thereafter, standard charging and discounts apply. 28 FINAL BUSINESS PLAN REPORT We envisage starting FUTs 24 months after tender win , depending on the number and quality of developers hired. Existing users of the current HDM - 4 software will be allowed to use the new version of software until its official launch. They then have the option to buy the new HDM - 4 version, or use the old, deprecated version at no further charge. No formal support (accredited training or consultancy) for the old version should be provided once deprecated, and this message should be conveyed to the HMD - 4 community as early as possible with some sympathy given towards the exiting concessionaire. We would encourage MDBs and donors to promote and accept the use of the new system only . Consideration of a discount may be given for very recent purchasers of the old HDM - 4 software, because a user who purchases an old - style perpetual license for $5 , 000 dollars, and then 6 months later, is being asked to pay £1 , 500 a year, might be upset. 7.7 Building the Sales Pipeline Sales teams will initially target legacy/existing users. Collateral will be generated for: š Mailshots (electronic and physical brochures). š Follow up phone calls of leads. š Attendance and presentation slots at conferences globally. š HDM - 4 exhibition stands globally at trade events. š Face to face meetings and standardised presentations where economically viable. š A revised and updated website for HDM - 4 needs to be created with appropriate forms to allow sign up for further information, capturing data and requesting call backs. š Details on coordinated sales team activities, supporting the marketing campaign. š Website refresh and development, improved contact forms, additional order forms for immediate download of products and licensing. š Sales team to follow up on leads, within 24 hours, with targeted organisations, governments, consultancies. 7.8 Target L aunch D ate Assuming a 36 - month development programme, w e would expect contract award in summer 2023 , a soft launch (and handover from HDMGlobal) 24 months later in the summer of 202 5 and hard launch in 202 6 . In view of the schedule and in keeping with good practice software development, a phased approach is envisaged as described later in Section 9 (Operating Plan) . We suggest identifying a relevant transport event or conference to use for the launch ( e.g., ITS World Congress, PIARC , TRB main events etc) . Figure 7 - 1 Launch Milestones Agree Branding schemaDesign new websiteDevelop website content / clean up web presenceCreate physical collateralLaunch WebsiteLaunch marketing campaignOfficial Launch at Conference 29 FINAL BUSINESS PLAN REPORT 8. Organisational Plan Figure 8 - 1 Organisation Plan 8.1 Organisation Form Table 8 - 1 below describes the expected tasks for each business function . Table 8 - 1 Roles & Responsibilities Business Actor Responsibilities Steering Committee Thought Leadership Advise Product Director on current trends Assist Product Director in fund raising Sets Product Owner Performance Targets Product Director Business Strategy Operating Strategy Reports to SC Sets Business Performance Targets Technical Advisory Group Expert Technical advice Supports Technical Lead Reports to SC Conducts technical audits on behalf of the SC Sales Department Generate sales leads Presentations to market Contract management /discount negotiations Secure sales Marketing Website collateral Physical collateral Marketing campaigns Presentations to market IP Holders (World Bank)Steering CommitteeProduct DirectorTechnical LeadDevelopment SquadGraphic DesignerData EngineerCustomer Support TeamSales & Marketing DirectorSales TeamBusiness AnalystFinancial AdminDelivery ManagerTechnical Advisory Group 30 FINAL BUSINESS PLAN REPORT Technical Lead HDM - 4 Product Development Cloud / Infrastructure Management Security, IAM, Licensing Web Site performance Customer Support Department Customer Support telephone / email / website Service monitoring and performance Customer retention Web Site Updates It is important that the Product Director has the freedom to evangelise their own principal ethos and culture . These could include driving customer focus, encouraging cross functional collaboration, defining targets that are results oriented, hiring and allowing individuals to take responsibility, being proactive and flexible and engendering a high trust culture. 8.1.1 Technical Advisory Group It is proposed that a group of Expert Advisors should be established to draft technical specifications to be implemented by the HDM - 4 Redeveloper . This would be undertaken in parallel with the bidding process for the selection of the HDM - 4 Redeveloper , thereby saving valuable time planned for the development of HD M - 4 . It is envisaged that the key role of the Expert Advisors would be to act as technical advisors to the Steering Committee (SC) and Project Management Team (PMT). Their role will be to review international best practices in subject areas relevant to the HDM - 4 modelling framework and subsequently draft detailed specifications compatible with the new modelling framework. To avoid any conflict of interest they should be externally funded. The Expert Advisors would undertake the following t asks and prepare draft specifications for review and approval by the SC and subsequently help support and supervise the HDM - 4 Redeveloper: • Task 1. Review and update the analytical framework used in HDM - 4, including mechanisms for project appraisal, road program me prioritisation, and preparation of road network strategies as a regular part of the business processes of road administrations. • Task 2. Review the full set of core equations in the current HDM - 4 version comprising models for road deterioration, road work effects, vehicle performance and operating costs, traffic flow and congestion, non - motori s ed transport (NMT), energy balance, etc., to assess continued relevance as well as research related to new developments/updates to the core equations. This task should draft specifications for extensions to the core equations, for example to incorporate ne w pavement types, changes in vehicle te chnologies (such as the expected increase in proportion of electric vehicles), modelling climate change impacts/resilience, GHG emissions, road safety, indexing the real value of passenger time, freight, and human life, etc. The draft specifications must e nsure compatibility of the core equations w ith future developments. • Task 3 . Draft low er level software system specifications for the development of the software, data housing, SaaS architecture, etc. This would include definitions of the applications program interface (API) between the various HDM software components, the data structures, an d requirements for integration with external systems (e.g., road asset management systems). The low - level software specification would define the detailed requirements and information needed by developers, testers, and other project stak eholders. This would greatly expedite the software development process as it would have to be done either by the HDM - 4 Redeveloper , or preferably before the start of the software development process. The medium to long term future of the Expert Advisors needs to be considered from the outset. Two options are foreseen: (i) They continue to support the SC to oversee/supervise the HDM - 4 re development contract; or (ii) They are embedded as expert advisors within the HDM - 4 re development team after the award of the contract. 8.2 Business L egal F orm and Ownership The legal ownership of the organisation that will manage HDM - 4 appears to be less pressing now that the World Bank is acting as IP holder and champion of the project , with the expectation that a competitive tender will be 31 FINAL BUSINESS PLAN REPORT issued for the redesign and redevelopment of HDM - 4, and operation of HDM under license, whilst the IP ownership will be retained by the World Bank, under control of the Steering Committee. The Financial Model outlined below is based on UK salary rates, payroll taxes , regulatory pension contributions, recruitment fees and other costs. 8.3 Critical Success Factors and Key Performance Indicators We have identified some c ommon C ritical S uccess F actors (CSF) and associated key performance indicators (KPI) that may be used to assess the performance of the business on an ongoing basis. We have identified four key perspectives that should be assessed and monitored in Figure 8 - 2 below . These are financial, internal (within the business operations), customer, and innovation (within the technical domain of the new software): Figure 8 - 2 Key Perspectives Performance targets should be determined by the Steering Committee and Product Director and agreed as part of the tender award . We have identified several common key performance indicators that would be helpful to measure the critical success factors. These are identified below: Figure 8 - 3 Key Performance Indicators SalesLead Conversion RateNew Customers voulmesTotal CustomersValue of SalesMarketingSearch engine ratingConference attendanceLead generation countMarket ShareFinancialTurnoverP&LROICAGROperationalCustomer Retention RateAverage Call DurationInfrastructure MTTR / MTBFVoice of the Customer ScoreDevelopmentLead Time to marketSDLC VelocityReleases per monthSoftware MTBF / MTTRFinancial PerspectiveSurvivalGrowthInternal PerspectiveEfficient use of resourcesEffective leadershipCustomer PerspectiveHigh customer retention rateExcellent service propositionInnovation PerspectiveDomain LeadershipNew Functionality 32 FINAL BUSINESS PLAN REPORT 8.4 Key External Contacts Additional non payroll actors and potential inputs / activities. • Accountancy Firm. • Legal Firm and Representation. • Recruitment Agency. • Project Management Support . • Management Consultancy. • Technical Consultancy. 8.5 Office Locations This will be defined by whoever wins the tender process. Satellite offices may be developed if a multidivisional operating structure is required in the future, but this is not needed to start. Multilingual support, particularly Spanish and Portuguese are deemed necessary to support customers in South America and French for Francophone countries in Africa . Depending on donor and funder considerations, a n African and Far East presence should also be considered. 33 FINAL BUSINESS PLAN REPORT 9. Operating Plan 9.1 Production P rocess A basic approach to software production is described in Figure 9 - 1 below. This will ultimately be decided by the newly formed team with the Delivery Manager . We suggest using automated testing technology as part of this process. The Software Development Lifecycle will be used for initial version minimum viable product (MVP). Figure 9 - 1 Standard Software Development Lifecycle A minimum viable product is one that can be marketed and sold to a customer, but which has only the necessary functionality to meet the customer ’s basic demands. The aim is to enter the market as soon as possible, and then build new iterations of the software (versioning) rapidly. The development team and the operations (support) teams need to work closely to ensure what is delivered is ready for re lease and the additional functionality is as required by the customer. 9.2 Defining the Minimal Viable Product In our parallel study “ Component A: The Detailed Survey of Current Users of HDM - 4 ” we have conducted a comprehensive analysis 2 where through various techniques we surfaced ninety - six Draft Requirements, before consolidating and ranking them into a set of twenty - two Final User and Business Requirements . Finally, during the End User validation process, we offered a way to cluster the requirements into these different categories and this is expressed in Figure 9 - 2 below: • Business Issues. • Software Usability. • Critical Models. • Expanded Capability. 2 Hodos Media - HVT051 - Component A - Final Project Report - V1 - 22 March 2023 PlanAnalyseDesignImplementTe s tDeploy 34 FINAL BUSINESS PLAN REPORT Figure 9 - 2 : Clustering of User Requirements Business Issues have less to do with the user experience and should be decided upon by the funders. Software Usability, on the other hand, includes both critical and non - critical requirements. Critical Models are the items that need to be addressed to make the outputs of a redeveloped HDM - 4 credible and meet what are now hygiene needs of the Multilateral Development Banks (MDBs) such as the World Bank and the Asian Development Bank. For example, the importance of incorporating Low Carbon Policies (GHG) as a priority into the next version, as the MDBs have an agreement not to fund projects that are non - aligned with the Paris Agreement. The only somewhat contentious issue surrounds UR10 (Licensing) as this requires not only a business decision but also some software development in order to implement it, so it straddles both areas. Figure 9 - 2 also attempts to begin to define the Minimal Viable Product (MVP) by selecting the following Requirements as essential: • Software Usability § UR1 – Reporting § UR12 – User Friendliness § UR11 – Integration with other Tools § UR4 – Analysis Framework • Critical Models § UR2 – Vehicle Fleets § UR3 – Traffic Data § UR5 – VOC Calibration § UR7 – Low Carbon Polices To be clear, t he high scoring requirements that fall outside of the shaded box of the MVP are important, and they not completely removed or absent (such as UR6 : Deterioration Models) they are just not updated at the MVP stage , and the MVP remains reliant upon working with the legacy models initially, to be updated as soon as possible . The Minimal Viable Product by definition, has to make some trade off against what needs be UR10LicensingUR18IT Env ironmentUR9ImplementationSupportUR1ReportingUR12User Friend linessUR11Integ ratio n w ithot her Too lsUR4AnalysisFrameworkUR15QualityAssuranceUR2Vehicle FleetsUR3Tr a ffic Da taUR5VOC C alibrationUR7Low CarbonPoliciesUR17MaintenanceStandardsUR6Det eriorationModelsUR8Ge ne r ate d andDivert ed TrafficUR13Resilience toclimate/disastersUR14Low VolumeRoadsUR20Asset Valuat io nUR19Road SafetyUR21Urban RoadsUR16Modelling DelaysUR22Other AssetsSof twareUsabilityCriticalMo de lsExpandedCapabilityBusinessIssu esMi ni mum Viab le Produ ctThe se a reBu sinessRequirementsThe se a re a bo ut h ow t he soft wa reis use dThe se a re th e critical u pd ate s fo rth e mod el t o b e cred ible an dan swer esse nt ia l qu estio ns (i.e.Pa ris Align me nt re qu ire me nt ofMDB s)The se a re a llth e“keyto pi care as”th atTaskVisscoring 35 FINAL BUSINESS PLAN REPORT taken to market. Our analysis represents a starting point, and we leave it to the Technical Advisory Board to make the final decision regarding those requirements that are essential for the MVP. Expanded Capability requirements are all nice to have but not as crucial as the critical models. They are to be ranked by the World Bank's Task V “Key Topic Areas” scoring work, but we would also recommend that the Technical Advisory Board begin work on the Critical Models need ed for the MVP as a matter of urgency. 9.3 Testing To maintain quality and reputation, emphasis must be placed on testing throughout the development lifecycle : • Unit Test are very low level, close to the source of the application. They consist in testing individual methods and functions of the classes, components or modules used by the software. Unit tests are in general quite cheap to automate and can be run very quickly by a continuous integration server. • Integration Test s to ensure a new software deliverable integrates with the core software. • Acceptance Testing for the functionality of the developed software package in terms of customer acceptance. Figure 9 - 3 Software Testing Phases We recommend testing is built into every stage of development , employing a continuous integration and continuous delivery approach (CI/CD) with an emphasis on small but frequent changes to the software. 9.4 Software development and scale up plan The ongoing development, once the initial MVP is delivered, can occur at higher velocity ( i.e., lots of changes) through automation. By deploying to a cloud - based environment, automation of software testing, delivery, deployment, and control of versioning can be managed. Figure 9 - 4 DevOps Approach to S oftware I mprovement Software development metrics that can be used for measuring workflow are provided below. DevelopmentUnit TestIntegration TestAcceptance TestProductionPlanCodeBuildTe s tDeployOperateMonitor 36 FINAL BUSINESS PLAN REPORT • Change Lead Time – The end - to - end time it takes for a work item to be created through to the work item being closed (done). • Change Cycle Time – The time a work item is active through to resolved (completed). • Time to Value - The time it takes for a customer to realise value of a new software feature. • Build/Test Results – A ratio of the number of software builds vs. the number of tests failed (or passed). • Change Failure Rate - The percentage of deployments causing a failure in production. • % Rework / Complete & Accurate - Percentage of trouble tickets being reopened. These can be incorporated in to the KPIs and Performance Metrics for departments. 9.5 Cloud M igration P lan 9.5.1 Current Codebase Based on the code we have seen to date; we can separate its functionality into two broad categories: • User interface. • Logic. The logic determines the core inputs and outputs and algorithms, and this is where the real value exists in the application. The ‘models’ such as ‘cracking’, ‘potholes’ etc. , that are used for pavement performance and prediction, and the analysis components fall within the ‘logic’ of the application. Historically, the changing landscape of user interface technology and user expectations has meant that the HDM - 4 software has not always been able to keep pace with the changes and so the focus has been on maintaining a stable desktop application using the existing code base. From the analysis of historic proposals regarding updating and upgrading HDM - 4, we see sug gestions for a significant amount of remedial user interface work, necessitated by the deployment and distribution model that exists. This remedial work would onl y enable HDM - 4 to run on newer Windows based computers for a few more years before the same issue reappears. The current deployment model of HDM - 4 is inappropriate today, using physical media or file downloads. This has also been a major pain point of overall maintenance, updating with new operating system releases, etc. since it i s impossible to ensure all clients are updated to the latest version without considerable management overhead. Licensing opportunities and management was also limited by this approach and was not helped by the perpetual license model. Finally, a lack of connectivity with the software installed by the end user made it extremely difficult to understand how the users were engaging with the software, and there were next to no feedback analytics on HDM - 4 usage. 9.5.2 Data Sovereignty, Security, and Connectivity in a Cloud - based HDM - 4 Deployment The recommendation to migrat e of HDM - 4 to a cloud - based platform aims to enhance ease of software updates and enable multilateral development banks to analyse anonymi s ed data across all end - users. However, concerns related to data sovereignty, security, large file sizes, connection bandwidth, and the ability to work offline must be considered (Thavendran, 2021) 3 . A desktop - style web application, which can be packaged from a single code base to work on both desktop and browser environments, could provide a viable solution to these challenges. A desktop - style web application can be designed to work on both desktop and browser environments, offering offline functionality and adaptability to varying internet connectivity scenarios (Kyrnin, 2021) 4 . This approach allows users to work with an offline version of the application in regions with limited or unreliable internet 3 Thavendran, S. (2021). Cloud Computing: Opportunities and Challenges. International Journal of Research and Scientific Innova tion, 8(4), 15 - 21 4 Kyrnin, J. (2021). What Are Web Apps and How Are They Different from Websites? Lifewire. Retrieved from https://www.lifewire.com/what - are - web - apps - 4683235 37 FINAL BUSINESS PLAN REPORT connectivity. Furthermore, it provides a single code base that simplifies software updates and ensures compatibility across different platforms . In terms of the d ata sovereignty challenge, some jurisdictions insist that data cannot be stored outside its borders, leading to the need for choosing appropriate cloud data centres for each country (Peters, Swartz, & Rohde, 2015) 5 . An example is the Swiss banking sector, where banks are required to store their data within the country's borders. In response, global technology companies such as Google and Microsoft have established data centres in Switzerland to ensure compliance with these regulations. A practical example of successfully addressing data sovereignty and connectivity issues is Microsoft Office 365 and OneDrive. These applications store data and APIs locally while uploading data to the cloud during and after each user session. The master co py of the data is stored in the cloud, ensuring data accessibility, security, and compliance with data sovereignty regulations . Addressing concerns related to data sovereignty, security, large file sizes, connection bandwidth, and offline functionality is essential for the successful migration of HDM - 4 to a cloud - based platform. By considering real - world examples and practical impl ications of data sovereignty, a desktop - style web application can provide an effective solution that ensures HDM - 4 remains efficient, secure, and user - friendly for all stakeholders involved. 9.5.3 System Value In the current climate in early 202 3 , the value of the HMD - 4 application is in the logic rather than the user interface. T here is possibly a market for a combined RAMS and evaluation system, based on our recent survey findings, with many customers using different RAMS alongside HDM - 4 (or none at all) with HDM - 4 providing a regulatory and analytical function that is complementary and parallel to the RAMS in use , w e would argue that this option should be the focus of efforts since the modelling and logic com ponent is what drives continued usage of what is an ageing and complex system. This i n turn should maximise the benefits afforded them in conjunction with MDB s and other stakeholders, since effective management of road pavements will extend their useful life, better target, and lower maintenance costs, and increase economic viability. This approach would naturally build on the well trusted brand HDM - 4 has across the developing world at the project level, and the sales connections already established. A dedicated RAM S module can be developed in the future as an optional add - on that is separately priced (and costed). However, the data storage system must be re designed from the outset to be accessible by external /other RAM systems . In terms of a system design, we should be separating responsibilities to facilitate not only integration opportunities but also to simplify ongoing development compartmentalisation. To achieve this, our recommended approach would be encapsulating the model s in an API (application programming interface) which can be monetised externally (e.g., per - use, monthly, etc.) and used to more easily enable any future RAM system created as a value - add. 9.6 Scope HDM - 4 model s technical characteristics such as speed, fuel consumption, tyre consumption, road noise , and vehicle speed, among many other metrics for vehicle operating costs . In today’s environment , those measurements will almost certainly become outdated. Electric Vehicles ( EVs ) are seeing rapid uptake with massive regional variation and socio - economic circumstances affecting road usage. Climate change and population growth affect water and waste management. The current models are unlikely to be valid i n all locations for very long and will require investment to update these under separate project(s). The scope of this project is to lay foundations for the future development of these models, and this needs to happen centrally and in a modern codebase for it to be viable. For example, a simple central change to introduce a new pavement surface type coul d be instantly available to all clients using modern cloud - based approaches. Additionally, data science approaches could take learnings from a previous application developed 5 Peters, M., Swartz, N., & Rohde, F. (2015). Data sovereignty: A perspective. Information Polity, 20(2 - 3), 65 - 77 38 FINAL BUSINESS PLAN REPORT for HDM - 4 to a data set and feed that into a learning model to improve predictive analysis capabilities for other clients, but this is for a future “data lake” type project that builds on this one. Specifically, out of scope is the ‘file converter tool’. We would encourage API use and simply define API specifications and a simple data structure that can be used to adapt to any other pavement management system’s needs. Integration with specific syst ems would be out of scope of the redevelopment project, unless requested as part of a proof of concept. We would anticipate the initial development project to also cover training materials and help articles, since there is no way to measure the effectiveness of such materials without an audience. The development scope should be phased, with an MVP forming an initial ‘evaluation’ release. The technical scope of this MVP should be: š Implement a single model. This may be wrapped or more likely ported from the original codebase . š Implement an end - to - end flow, such that the APIs to prepare for and run that model are defined and implemented, with full infrastructure in - place. š All monitoring, analytics and observability, and all access control systems implemented for that one model. By following the above approach, additional models can be developed by following the same pattern. If a review of the MVP requires that any approaches are changed, it will only affect a single model. 9.6.1 Roadmap to a Centrally Managed Codebase Notwithstanding the internet connectivity can be a challenge for some users, it makes much more sense for the core functionality to be hosted centrally with a client - server model. Benefits of this direction are: • New models can be added for all customers at the same time. • Code modifications can be released that will affect all customers at once. • Centrally held data can be fed into machine learning algorithms and compared. • Dynamic data sets such as weather and climate change can be used as model inputs. • Model logic can be revised and brought up to date. All of the above can be handled with a single release process and does not necessitate roll - out to individual customers. The value of the improved code, data processing and expected regular updates helps to justify to the customers a more sustainable chang e in the licensing model from a lifetime license to a yearly or monthly subscription model. Should the codebase be taken from its current form and re - purposed for a web - based API, there are several tasks that would be necessary, and some analysis and repackaging work. The existing code is written in C++, which is a high performing language when w ritten well, but is difficult and expensive to maintain. However, that code can be called from other languages such as Python or Java, which are generally simpler and cheaper to write and maintain. Additionally, wrapping the C++ code in another layer allow s for new models to be written in different ways and in different languages, and allows for the older models to be rewritten gradually. For example, a new model may be entirely data driven using machine learning approaches and composed of a database and C loud - based machine learning tools. It is very important that there is a provision for new model development since the existing models do not reflect all the issues and uses affecting modern road pavements . For example, many modern cars are heavier and have a greater impact on pavements , weather patterns change, road noise levels can change, vehicle reliability changes, shift towards EV and hybrid vehicles, central reservation barrier construction may not be adequate for modern cars, recovery, weather patterns and many more aspects may not b e reflected in the older models and may require re - work. If the models were hosted over the internet and exposed via an API, that API could be made available for customers to use directly, or for integrators to use to add value to existing RAMS. This would allow RAM systems to add HDM as a value - add feature, fu lly integrated rather than as a parallel complementary system, and could not only provide ongoing revenues but also an expansion of sales and reach for the common good. 39 FINAL BUSINESS PLAN REPORT For a simple new RAM system offered via the project outcomes, it should be possible to feed pavement data into the new API to minimise additional data entry. This overall approach means that software is centralised, and any updates to the software will immediately be available for all users. There is immediately scope to separately charge for value - add features, such as adding in centrally (trusted) held data sets to inform outcomes, comparing data over time, comparing data from different regions / customers, and generally providing the project funding body with more valuable insights. These insights can be surfaced via data science processes to inform other, loosely related projects such as climate change initiatives which would not otherwise be able to see this data, and some consideration should be given to this data access in licensing terms and conditions. 9.6.2 Lightweight RAMS S ystem While there appears to be the appetite for a RAM system, this is very much a separate deliverable and has clearly separate requirements. A RAM system is orthogonal to the function of HDM - 4, which is to provide analysis that feeds into transport infrastructure funding decisions. A RAM system can be used to enter data into this decision making process, but it carries with it an implicit set of requirements based on other RAM systems in the market, and risks trying to compete with those systems. That said, should the requirements be generalised, they could be reduced to data management, event driven actions and messaging, such as re - evaluation through HDM - 4 when key data changes or alerting. A truly minimal product would not deal with extensive reporting. However, it should offer core data entry and management via mobile to aid field surveys and mobile data entry. Data management systems need to be flexible to be of the most use to a highly variable user base, and road authorities around the world will certainly have differing needs due to terrain, climate, traffic patterns, vehicle type distribution, legislative co ncerns, etc. Therefore, there should be a flexible and extensible forms - based data model backing any RAM system that has core data fields (required for the redeveloped HDM - 4 APIs) and customisable fields for additional data as well as completely customisa ble additional data structures. The RAM system also needs to allow data import/export into common formats, provided those files being imported are simple data formats rather than highly formatted spreadsheets, and it needs a flexible reporting subsystem. We would expect modern road surveying approaches to be highly mobile - oriented, so it should be possible to package the app or a part of it as a mobile application to facilitate updates in the field (photos, geo - tagging, physical survey registration). It is assumed that there is nothing in the RAM system that would necessitate a desktop - based application, and so a web - based application should be developed and packaged for mobile. In fact, it should be developed mobile - first as a guiding principle, so that mo bile features are not left behind. Desktop browser features are expansions on the mobile views, rather than the other way around. If i t is decided that a future RAM system is required, and there is the budget for it, our recommendation is to develop a system that allows for future expansion via its framework and metadata but having only interoperability with the redeveloped HDM - 4 APIs as its deliverable in the immediate redevelopment project. Most of the development work would focus on the framework (permissions, data definition, data entry, search, events and hooks, custom APIs, and custom content management) and a smaller portion o n interoperability with redeveloped HDM - 4 (extracting required input data, calling APIs, and collecting outputs). In the event that a RAM system is deemed in - scope, and an MVP release is planned to prove the architectural approach, the MVP should function end - to - end for a thin slice of functionality. For example, it should: š P rove the general approach for flexible data modelling . š P rovide a management interface for the input data needed to execute the redeveloped HDM - 4 APIs that are in - scope for the new MVP (single model) and no more. 9.6.3 Overall Project Delivery Approach This section touches on modern delivery methodologies with some suggestions. 40 FINAL BUSINESS PLAN REPORT A phased approach with a minimal viable product (MVP) in the first phase would allow for a shorter time - to - market, and subsequent feature definition and prioritisation should follow from that, based on observed usage patterns and potentially A - B testing. T he MVP would not necessarily be something that could be taken to market aggressively, but a small number of trial users could help drive out feature detail and priority. The task at hand is not solely software development. The greatest chance of success would come from a tight Development team composed of: • Product Director , in charge of strategic direction and feature prioritisation, and reporting upwards and manging the entire team, and delivering the contract (preferably CEO, P artner or Director level). • Business analyst, in charge of functional feature definition and documentation. • Delivery manager, in charge of team ceremonies, project coordination, etc. • Tech Lead / Architect, in charge of overall technical direction and implementation. • 1 x Development squad of around 3 - 5 developers who are comfortable with a ‘you build it, you run it’ approach – in other words, they take ownership of their own code when it reaches production. Developers should write their own automated tests to prevent regressions as development progr esses. • Graphic designer (potentially part - time). • 1 x Data engineers. In terms of delivery roadmap and timescales, the MVP for could take around 24 months . From there, we would expect that a further 12 months would be required before the system could be sold and used commercially with any success (or revenues). Many wished - for features are currently lacking definition, such as greenhouse gas modelling, and it is difficult to predict how the requirements and priorities might change in the next year. These might be dictated by funding projects ongoing at the time. Therefore, we would recommend that development be expected to last for 36 months, with the last 6 - 9 months undefined at the point the project starts, but with ongoing funding subject to Steering Committee reviews, with allowances included for revenue gen eration to date, and agreed KPIs met. It is important to understand as well that by taking on this development work, future potential should be unlocked. The nature of the product will chang e dramatically, along with the data being stored and processed. That data will have other uses, and the changing data will also influence how the Steering Committee members and other MDB s handle funding decisions, and this in turn will seed other development. In this way, the product development function is dynamic, reactive, and ongoing, although the resourcing requirements of the ongoing work may change (may need more data science capability later and less software development for example ). However, it could be a mistake to treat this as a one - off isolated product development requirement, which has proven to be the Achilles heel of the HDM programme since it began. 9.6.4 Development Team & Costs Based on the above team composition, current market rates in the UK for these roles are approximately: Table 9 - 1 Expected Roles and Market Rates Role UK Market rate (permanent, yearly) UK Market rate (contract, daily, outside IR35) Yearly contract cost (lower value) for all heads Yearly contract cost (upper value) for all heads Internal Product Owner £90 - 140k £650 - £850 £143,000 £187,000 Business Analyst £40 - 80k £400 - £600 £88,000 £132,000 41 FINAL BUSINESS PLAN REPORT Delivery Manager £60 - 95k £550 - £700 £121,000 £154,000 Tech Lead / Architect £90 - 140k £750 - £850 £165,000 £187,000 Graphic Designer £60 - 90k £500 - £600 £110,000 £132,000 Data Engineer (X 1 ) £80 - 120k £600 - £750 £ 132 ,000 £ 165 ,000 Mid - level developer (X 2 ) £50 - 70k £400 - £550 £ 126 ,000 £ 242 ,000 Senior developer (X 1 ) £70 - 90k £500 - £650 £ 11 0,000 £ 143 ,000 Totals £ 599 ,000 - £825,000 £ 995,000 £1, 342 ,000 Assuming 220 working days a year, filling the project entirely with contractors would cost nearly £1 million for the first year, or $ 1. 19 million, plus any recruitment agency overhead . Permanent /existing hires could cost less, but holiday pay, employers NI , statutory pension contributions, and other costs need to be considered . Being practical, it would make sense for a blend of permanent and contract, potentially at about a 50 - 50 split, since permanent employees typically result in lower staff churn, while contractors can be more highly skilled and useful for plugging a more sho rt - term resourcing gap. This would be defined by each bidder and their existing resourcing, potentially plugging gaps in their payroll team with external freelancers. 42 UPDATED BUSINESS PLAN REPORT 9.6.5 Solution Design Overview A high - level solution design could look like the following, which indicates key system boundaries, system components and interfaces between them: Figure 9 - 5 High Level System Architecture 43 FINAL BUSINESS PLAN REPORT These system components and interfaces are described below: Table 9 - 2 System Components Key System Component Name Description S1 3 rd Party RAMS or user Users and 3 rd party systems interact with the API in roughly the same way – either there will be an HDM software frontend that uses this API, or there will be a 3 rd party system that uses this API. Both will be authenticated and have permissions to use certain features. S2 Firewall The firewall allows API traffic through but denies access to anything else within the private network S3 API Monetisation This component tracks API usage and handles billing and can influence API access by a client ( i.e., deny access if the customer has no credit) S4 Identity Platform Typically, in the modern world, this would be an OAuth2 system which holds user account info, and the identifiers for the systems that those accounts can access and the features allowed. The identity platform issues short - lived access tokens when a user a uthenticates, and that token is passed in each API call. The server - side code validates the provided token with the identity platform. S5 Load Balancer A load balancer provides a single interface to a scalable system that internally has multiple interfaces. As the name suggests, it spreads request load between the back - end systems, but it also tracks which of those systems are up and running and which ar e not, so that it can route requests accordingly. S6 API Gateway An API gateway typically provides a way of bundling different systems into a single cohesive API presence. Different gateways have different features beyond this. S7 Application Orchestration There are several application orchestration systems. Among the responsibilities of such a system is scaling, automatic application restarts, version roll - out, etc. This greatly simplifies managing a live application. S8 Wrapped legacy logic There is a substantial amount of C++ code that makes up the models and the analysis. This code would need to be packaged in such a way that it can be deployed into an application orchestration cluster S9 Web Server Implements the API specification and orchestrates a response S10 Back Office Internal systems / APIs required for management 44 FINAL BUSINESS PLAN REPORT S11 Batch Processor Handles large data sets and scheduled data collection S12 Database This may comprise more than one actual database – one for big data sets and one for faster access S13 Dataflow Ingestion of data via a storage bucket S14 Scheduled Functions Scheduled collection of data from various sources that can be shared across all clients, such as weather data, freely available data sets that can influence planning S15 CI/CD Continuous Integration and Continuous Delivery – the automated testing and deployment of code S16 Artifact Registry Stores different versions of deployable code once it’s been tested and packaged. S17 Cloud Storage File - based storage – this would be used for log archives, customer file upload, etc. S18 Logging & Metrics Real - time log analysis and metrics allow visibility of the current state of the system and root - cause analysis of failures S19 Developer The developer will change code, commit that change to a source code repository, that change will then be detected by the CI/CD system, which will then build, test, and deploy S20 3 rd Party APIs Used as data sources for continually updated data such as weather or traffic. S21 RAMS application A web - based application S22 Additional models API calls to invoke HDM behaviour will trigger optional and mandatory models via an internal interface. These models will act on data and could be either a service running within the cluster or composed of data pipelines and machine learning systems in th e cloud platform. Table 9 - 3 Interface Components Key Interface Name I1 User API network connection to firewall I2 3 rd party RAMS network connection to firewall I3 Firewall to load balancer I4 User request to identity system for token 45 FINAL BUSINESS PLAN REPORT I5 API gateway to API monetisation system I6 API gateway to identity system for token validation I7 Load balancer to API gateway (API gateway will be multiple instances) I8 API gateway to Kubernetes ingress – request routing definitions of authenticated requests I9 Kubernetes ingress to web server (API server) I10 Kubernetes ingress to back - office server (administrative) I11 Web server to batch server – invoke batch functions, then poll for progress. I12 Batch server to wrapped legacy logic – orchestrate wrapped existing model code I13 Kubernetes to cloud storage – backups, customer data ingress I14 Logging and metrics – most likely Google logging, but potentially 3 rd party metrics I15 Batch server to database – invoke database queries. I16 Back office to database I17 Dataflow to database – ingest data from file sources I18 Scheduled functions to dataflow – scheduled collection of data I19 Scheduled function to public cloud – via Google Internet Gateway I20 Public cloud to 3 rd party APIs – invoking APIs to collect data I21 Developer to CI/CD (Google Cloud Build) I22 Google Cloud Build to Google Container Registry to store Docker images I23 CICD to Kubernetes to deploy applications using the Docker images stored in Google Container Registry. I24 Kubernetes ingress to RAMS web server I25 RAMS application to database 9.6.6 Indicative Pricing for O perational R unning Indicative monthly pricing for such a system would be as follows (Google Cloud used as an example). The system would be generally self - healing but would require at least a part time service reliability engineer (SRE). 46 FINAL BUSINESS PLAN REPORT Table 9 - 4 Indicative Pricing by Architecture Component Component Per month pricing (USD) per month Description S3 – API Monetisation 0.5% of invoiced amount e.g., https://www.amberflo.io/pricing S4 – Identity Platform $25 Google identity platform S5 – Load Balancing $40 Google global load balancing S6 – API Gateway Kong Community edition $0 Kong would run inside the application cluster. S7 – Application Orchestration $700 Google Kubernetes Engine (GKE) S12 - Database $550 BigQuery and DataStore S14 - Scheduler $50 Google Cloud Scheduler S17 – Cloud Storage $200 Cost of file storage S18 – Logging and Metrics $150 Storage and 3 rd party subscriptions for logging and metrics I3 – Network Egress $400 Cost of network traffic SRE technical support (full time) $6000 Single FTE salary Total $7,715 We have factored the above total cost into the business plan from the hard launch date, however during the development phase, the cloud infrastructure costs are estimated to be at a reduced level of around £500 a month. 47 FINAL BUSINESS PLAN REPORT 9.7 Legal and IP S trategy Building on the intellectual property rights work conducted by the World Bank for HDM - 4 , it would be preferably to manage IPR by external legal professionals. Law firms that can be approached include Payne, Hicks & Beech, Clifford Chance, Linklaters, Olswang, and Allen & Overy. Areas to cover: • IP protection for new and existing algorithms and data sets. • Definition and understanding of relative share of IP by stakeholders before and after the tender process. • IP assignment to the World Bank as a condition of tender, from the new operators (if generated). • Data Protection including GDPR to meet all necessary regulations. • Any stakeholder agreements. • Contract with successful tenderer. Any successful tenderer should bear responsibility for tracking IP development and maintaining a shared register of IP with the World Bank. 9.8 Overseas M arket A ccess Overseas markets should be approached as part of the marketing campaign. We envisage utilising existing network of clients and stakeholders as well as roadshows, exhibitions, and conferences. There is potentially a requirement for localised sales and training, but we envisage improvements in software and on - line supporting documentation should reduce the need for excessive face - to - face training. Once consultants and training operate under an accredited scheme, local partners can be trusted to provide training. 9.9 Supply C hain M anagement Any s upply management will be undertaken by Production and Financial departments and will be the responsible of the successful tenderer . SLAs and KPIs need to be agreed with suppliers , and any contractual requirements should flow down to their agreements. 9.10 SWOT Analysis Below is a summary of the strengths, weaknesses, opportunities, and threats posed to a redeveloped HDM - 4 operator . It should be noted that these are highly dynamic and should be revisited regularly. Figure 9 - 6 HDM - 4 SWOT Analysis 48 FINAL BUSINESS PLAN REPORT 10. Alternative Revenue Streams Traditionally, software companies can generate revenue in a number of different ways, and the most appropriate strategy will depend on the specific circumstances and goals of the company. Some common revenue generation strategies that software companies might pursue include: 1. Subscription - based model: The company could move from a one - time purchase model to a subscription - based model. Customers would pay a monthly or annual fee for access to the software and its updates. This could provide a more predictable revenue stream and potentially increase customer lifetime value. 2. Value - based pricing: Rather than charging a flat fee for the software, the company could charge based on the value that the software provides to customers. For example, they could charge a percentage of the savings that a customer reali s es from using the software to manage their road assets. 3. Upselling and cross - selling: The company could offer additional services or features that customers could purchase to complement their road asset management software. For example, they could offer consulting services or training program me s to help customers get the most out of the software. 4. Partnering with other companies: The company could partner with other companies in the road asset management industry to offer complementary products or services. For example, they could partner with a company that provides road maintenance services and of fer bundled packages to customers. 5. Usage - based pricing: The company could charge customers based on their usage of the software, such as the number of users or the amount of data stored. This could provide a more flexible pricing model for customers and potentially increase the company's re venue. 6. Freemium model: The company could offer a basic version of the software for free and charge for more advanced features or additional support. This could attract more customers to try the software and potentially increase conversion rates for paid versions. 7. Advertising: The company could explore advertising as a revenue stream by offering advertising space on their software platform to relevant third - party advertisers. This could generate additional revenue, but it's important to consider whether this would n egatively impact the user experience. These are the most common alternative revenue strategies that a software company could pursue . The best approach will depend on the company's specific goals, the needs of their customers, and the competitive landscape, but i f we discount the above areas that are related to pricing of the new version of HDM - 4 as that is dealt with in Section 7.5 (page 27 ) above, as well as the Freemium model (which is a solid concept but does not generate revenue by its very nature, and has been already deployed by HDMGlobal – see HDM sentry 6 ) and the advertising model given how niche HDM - 4 is, that leaves bullet point 3, Upselling and cross selling, and bullet point 4, Partnering with other organisations. We shall dive deeper into those strategies of upselling and cross - selling and partnering with other companies. 10.1 Upselling and cross - selling Upselling involves offering customers additional products or services that complement the software they have already purchased, while cross - selling involves offering customers related products or services that they might also be interested in. For a road a sset management software company, some examples of upselling and cross - selling opportunities might include: • Offering training program mes or consulting services to help customers get the most out of the software. • Upselling to a more advanced version of the software with additional features or functionality. • Cross - selling complementary software tools, such as GPS tracking software or road management software and hardware. By providing additional value to customers and increasing the total amount of revenue per customer, upselling and cross - selling can be a highly effective revenue strategy for software companies. 6 http://www.hdmglobal.com/hdm - sentry - a - simplified - interface - to - hdm - 4/ 49 FINAL BUSINESS PLAN REPORT 10.2 Partnering with O ther C ompanies Partnering with other companies in the road asset management industry can provide opportunities for mutual growth and increased revenue. Some potential partnerships for an HDM - 4 redeveloper might include: • Partnering with a road maintenance company to offer bundled packages that include both road maintenance services and the software to manage those services. • Partnering with a data analytics company to provide more detailed insights and reporting capabilities within the software. • Partnering with a technology company to integrate the software with other hardware or software systems. By leveraging the expertise and resources of partner companies, the HDM - 4 redeveloper can expand its offerings and provide more value to customers, ultimately increasing revenue and market share. When considering these revenue strategies, it is important to assess the potential costs, benefits, and risks of each option, and to determine which strategies align best with the company's goals and objectives. In terms of selling HDM - 4 branded hardware like mobile devices, which whilst it can be a viable revenue stream for a software company , we remain sceptical as the margins on hardware devices can be much lower than those on software products, so it is important to carefully consider the potential costs and benefits of this revenue strategy. Here are some potential benefits and challenges of selling branded hardware devices: Benefits: • Additional revenue: By selling hardware devices, the software company can generate additional revenue streams. • Increased market share: Offering hardware devices can increase the company's market share and reach a wider audience. • Improved customer experience: By providing customers with a seamless hardware and software experience, the software company can improve customer satisfaction and loyalty. Challenges: • Low margins: The margins on hardware devices can be much lower than those on software products, so the company may need to sell a large volume of devices to make a significant profit , which seems unlikely. • Increased competition: Selling hardware devices can put the HDM - 4 redeveloper in direct competition with established hardware manufacturers, such as Apple and Samsung. • Increased complexity: Selling hardware devices can add complexity to the HDM - 4 redeveloper ’ operations, including manufacturing, supply chain management, and support. It is important for the HDM - 4 redeveloper to carefully consider the potential costs and benefits of selling hardware devices, as well as the level of demand for such devices in the market. The HDM - 4 redeveloper should also consider how the hardware devices will be integrated with their software products and whether the devices will require additional support and maintenance. In terms of the expected development strategy, we have assumed that the new iteration of HMD - 4 will work with off the shelf mobile devices without much configuration. As we do not anticipate exception al margins from any alternative revenue approach, w e think the best tactic is to explore those that have strategic value and contribute back to the core HDM - 4 sales (or stickiness of recurring license fees) by better supporting customers , as well as best practice in the sector, therefore we think that licensing the HDM Intellectual Property through APIs, training provision , and accreditation (both for HDM - 4 trainers and consultants) are the three alternative revenue streams that should be analysed in more detail. 10.3 Licensing HDM Technology APIs (Application Programming Interfaces) provide a standardi s ed way for software developers to interact with a software application. By offering APIs to third - party developers, a software company can allow other companies to build products that integrate with their technology , while also moneti s ing their intellectual 50 FINAL BUSINESS PLAN REPORT property. Here are some potential benefits and challenges of licensing software intellectual property through the use of APIs: Benefits: • Additional revenue: By licensing APIs, the HDM - 4 redeveloper can generate additional revenue streams. • Increased market share: By allowing third - party developers to integrate with their software, HDM - 4 redeveloper can increase their market share and reach a wider audience. • Improved customer experience: By providing customers with a seamless integration between their software and pre - existing third - party products, the HDM - 4 redeveloper can improve customer satisfaction and loyalty. Challenges: • Integration challenges: Integrating with third - party products can be complex and time - consuming, and HDM - 4 redeveloper may need to provide additional support and documentation to ensure that the integration is successful. • Control over intellectual property: By licensing APIs, the HDM - 4 redeveloper is sharing intellectual property with third - party developers, which can create challenges in controlling how the software is used and ensuring that their intellectual property is protected (which as a third party operating under license might be non - trivial). • Competitive risks: By allowing third - party developers to integrate with the software, the HDM - 4 redeveloper may be creating new competitors in their market. To successfully license software intellectual property through the use of APIs, the HDM - 4 redeveloper should carefully consider the potential costs and benefits, as well as the level of demand for such integrations in the market. The HDM - 4 redeveloper should also develop clear licensing terms and agreements to protect their intellectual property and control how the software is used by third - party developers. Here are some real - world examples of companies that license software intellectual property through the use of APIs: • Stripe is a payment processing platform that offers APIs to developers for integrating payment functionality into their own applications. Stripe charges a percentage - based fee for each transaction processed through their payment processing API. The fee varies by country and payment method, but it generally ranges from 1.4% to 2.9% of the transaction value, plus a fixed fee of a few cents per transaction. • Twilio is a cloud communications platform that offers APIs for developers to build voice, video, and messaging functionality into their own applications. Twilio charges a fee per use of their communication API, with pricing based on the type of communication (voice, video, or messaging) and the volume of use. The company offers a variety of pricing plans, with different levels of features and support. • Google Maps offers APIs for developers to integrate maps and location - based functionality into their own applications. Google Maps offers a usage - based pricing model for their mapping API, with a free tier and a paid tier for high - volume use. The cost for the paid tier is based on the number of API requests and the amount of data transferred. Google does not disclose speci fic revenue figures for their API business . • Amazon Web Services (AWS ) offers APIs for developers to access and manage their cloud computing resources. AWS charges a usage - based fee for their cloud computing API, with pricing based on the type of resource used and the amount of usage. The company offers a variety of pricing plans, with different levels of features and support. Overall, licensing software intellectual property through the use of APIs can be a valuable revenue stream for the HDM - 4 redeveloper , but it requires careful planning and execution to ensure success. 10.3.1 API Fee Structure It is quite challenging at this stage to estimate revenues from API access, but here is an example of a potential API fee structure: 51 FINAL BUSINESS PLAN REPORT • A basic tier provides a limited amount of API usage and basic support. This tier is intended for small businesses or individuals who need basic access to the API. The fee for this tier could be a flat rate of £ 50 per month. • A pro tier provides a higher level of API usage and enhanced support. This tier is intended for medium - sized businesses or individuals who need more robust access to the API. The fee for this tier could be a usage - based fee of £ 0.01 per API call, with a minimum monthly charge of £ 100. • An enterprise tier provides a high level of API usage, custom features, and priority support. This tier is intended for larger businesses or organi s ations with high - volume usage of the API. The fee for this tier could be a usage - based fee of £ 0.005 per API call, with a minimum monthly charge of £ 1,000. It is important to carefully consider the cost of providing the API, as well as the level of demand for the API in the market, when determining the fee structure. The fee structure should also be transparent and clearly communicated to potential users of the API . The provider may also want to consider offering a free tier for low - volume usage of the API, as this can help attract new users (or academics) to help encourage adoption of the API. 10.3.2 API Revenue Model If we try to build a revenue model around the above pricing structure, we could reasonably estimate the following: • Basic Tier: The revenue for the basic tier is based on the flat rate of £ 50 per month. If the provider has 100 customers using the basic tier, the total monthly revenue would be £ 5,000. • Pro Tier: The revenue for the pro tier is based on the usage - based fee of £ 0.01 per API call. If the provider has 10,000 API calls per month for the pro tier, the total monthly revenue would be ( £ 100 minimum monthly charge) + (10,000 x £ 0.01) = £ 200. • Enterprise Tier: The revenue for the enterprise tier is based on the usage - based fee of £ 0.005 per API call. If the provider has 100,000 API calls per month for the enterprise tier, the total monthly revenue would be £ 1,000 (minimum monthly charge) + (100,000 x £ 0.005) = £ 1,500. In total we can estimate around £6,700 a month in revenues, in terms of cost , the development approach we expect to use will cover most of the API costs, however there will be an ongoing Service Reliability Engineer (SRE) role (~£80K) required to look after the deployments, which means the model just about breaks even. 10.4 HDM T raining Provision The HDM - 4 redeveloper could offer an advanced training program me that provides speciali s ed training on specific features or functionalities of the updated software. This could include both online and in - person training sessions. The price for the advanced training program me could range from a few hundred to a few thousand dollars, depending on the level of training provided. Here are some potential benefits of this revenue strategy: • Additional revenue: By charging for training, the y can generate additional revenue streams. • Increased customer loyalty: Customers who have invested time and money in training are more likely to continue using the software and remain loyal to the company. • Improved customer satisfaction: Providing training can improve customer satisfaction by helping users better understand and utili s e the software. • Competitive advantage: Offering training can differentiate the HDM - 4 redeveloper from competitors and provide a unique selling point. Historically, the University of Birmingham provided “ HDM - 4: Train the Trainer” sessions which was an in - depth training course for those intending to use HDM - 4 and go on to teach/assist others , indeed some consultants still promote themselves as “Trainers” because they went on this course some 20+ years ago. The course was replaced and HDMGlobal and TRL now offer a more generic “Introduction to HDM - 4” training course which cover s the breadth of the software functionality at an introductory level. In terms of accreditation, they only 52 FINAL BUSINESS PLAN REPORT offer a “certificate of attendance” and do not endorse anyone’s competency, although in the past they have been asked to provide a “Certificate of Competency”, which they do not do. These courses include face - to - face training , and cost in the order of £1,500 per person for a 1 week course. The number s on these courses would vary between five and twenty individuals . The course tends to be quite practical and when classroom numbers are larger, two and sometimes three suitably qualified instructors are required to ensure assistance can be given. Even with the lower number courses HDMGlobal prefer to have at least two trainers to vary the delivery of the course material and to have differe nt backgrounds when answering questions that may come up. Apparently, m any (20+ years) ago some standardised HDM training material was produced with the aim of making this available to anyone who wanted to conduct HDM - 4 training , but the idea never really gained any traction. On occasion HDMGlobal has been asked if they would sell training material or instruction al videos – again, they could not see that the effort would create much of a revenue stream, so did not follow it up. All these things are something that a dedicated training resource could become involved with, but HDMGlobal have never had the resources to do so. Historically, HDMGlobal have been asked about distance learning courses but have not had the resources to set up anything like this . The feeling is that revenue would be low, although it would contribute to better use of HDM for those unable to attend training courses, and possibly reduce some technical support questions that are obviously coming from those with no training on its use and who have been thrown in the deep end to conduct an analysis . During Covid - 19 however , HDMGlobal started to offer online courses, managed through TRL mainly. It was found these run better by having six sessions of four hours each spread out over two weeks. TRL managed the fees for these, and charged £950 per person, and a gain, numbers have varied on the courses from between six to fifteen . According to TRL who assist HDMGlobal with managing sales, the level of interest in HDM - 4 training is actually quite high ( getting around 2 – 3 emails a day requesting information) but the prospective participants usually baulk at the price , which they feel is in line with other on - line software training. In order to cover costs, TRL needs at least ten participants to break even, but in reality, they need fifteen participants to make it a worthwhile activity. HDMGlobal has also been able to offer bespoke courses to organisations, either delivered online or in - person. These tend to be around a week in duration and the material and subject matter can be focused by the organisation. They are typically charged based on the length of the course, the amount of t ime it will take to prepare the material that is bespoke for them, and the number of people who will be attending the training. Again, the larger the course attendance the more trainers that are required. Examp les of such training courses include for a road group in Malaysia, the ADB, the Solomon Islands, South Africa, and TRL have been involved in other countries in Africa. For these custom training courses HDMGlobal charge s between £850 to £1,000 per day (charging more than £1k per day to some organisations creates problems as that requires a higher level authorisation ). In terms of the generic training courses, HDMGlobal are expected by PIARC under the terms of their concession agreement to offer at least two per year – ideally some in English / French / Spanish. Those offered by TRL/ UoBE are in English. They have found that two per year is enough to satisfy demand, and even then, they have had to cancel some due to very low numbers. They have partners in Chile and Mexico who offer training in Spanish, and partners in France who have offered training in French. Very occasionally Webinars have been organised, but these have been free events used primarily to disseminate information and to support marketing . HDMGlobal also offer s a training software licence to academic and commercial organisations with reduced functionality such that it is not useful for commercial work. People are then free to use this on their own training courses. They are aware of some groups that offer HDM - 4 training activities fairly regularl y, such as Central Road Research Institute ( CRRI ) in India and some groups in South Africa, a U niversity in Argentina and also the International Road Federation ( IRF ) have previously promoted an HDM - 4 short course. Here are some real world examples of software organisations that provide training for their software and associated pricing information: 53 FINAL BUSINESS PLAN REPORT • Autodesk, a leading provider of design software, offers a variety of training programs for its software products, including online courses and instructor - led courses . The company offers a range of pricing options : § Online courses: Some free courses are available, while others range from $35 to $395. § Instructor - led courses: Prices vary depending on location and duration, with a 3 - day course on Autodesk Revit costing between $1,200 and $1,800. • SAP, a global enterprise software company, offers a comprehensive training program me for its software products : § Online courses: Some free courses are available, while others range from $500 to $5,000. § Instructor - led courses: Prices vary depending on location and duration, with a 5 - day course on SAP S/4HANA costing between $3,750 and $4,900. • Microsoft offers a range of training program me s for its software products, including online courses and in - person workshops : § Online courses: Some free courses are available, while others range from $99 to $995. § Instructor - led courses: Prices vary depending on location and duration, with a 5 - day course on Microsoft Azure costing between $2,595 and $3,295. • Salesforce, a leading provider of customer relationship management (CRM) software, offers a variety of training program me s for its software products, including online courses and in - person workshops : § Online courses: Some free courses are available, while others range from $300 to $4,000. § Instructor - led courses: Prices vary depending on location and duration, with a 5 - day course on Salesforce Administration costing between $2,500 and $3,000. 10.4.1 Training Fee Structure The actual fee structure used will depend on a variety of factors, including the type of training being offered, the target audience, and the overall pricing strategy going forwards . I t is important to consider the costs of delivering the training, margins, as well as the value it provides to the customer, when setting prices. It is also important to keep in mind the competition and the pricing of similar training program me s in the sector, because although HDM - 4 training seems to be in demand, the end users appear to be on tight budgets. In terms of a potential training fee structure, we propose the following: • Instructor - led training: § Flat fee per student per day: The provider charges a flat fee of £ 200 per student per day for instructor - led training. § Early bird discount: The provider offers a 10% discount to students who register for the course at least 30 days in advance. § Group discount: The provider offers a 20% discount to groups of 5 or more students who register for the same course at the same time. • Online training: § Flat fee per student per day: The provider charges a flat fee of £ 150 per student per day for online training. § Early bird discount: The provider offers a 10% discount to students who register for the course at least 30 days in advance. § Group discount: The provider offers a 20% discount to groups of 5 or more students who register for the same course at the same time. 10.4.2 Training Revenue Model Based upon the fee structure above, desk research and the interviews with both HDMGlobal and TRL we have constructed the following revenue model: 54 FINAL BUSINESS PLAN REPORT • Assumptions: § The HDM - 4 redeveloper offers standard training programmes at £200 per day for instructor - led training and £150 per day for online training. § The HDM - 4 redeveloper offers 60 instructor - led training days and 60 online training days for standard training each year. § The instructor - led training programme has an average of 5 students per session, while the online training programme has an average of 10 students per session. • Revenue Model: § Revenue from instructor - led training: 60 days x 5 students per day x £200 per day = £60,000 § Revenue from online training: 60 days x 10 students per day x £150 per day = £90,000 § Total revenue from training programmes per year: £150,000 This revenue model is based on the assumptions listed above and is for illustrative purposes only. The actual revenue the HDM - 4 redeveloper may generate from training will depend on a variety of factors, such as the number of training courses held, the number of attendees, and the pricing strategy . In terms of costs, we expect a full time T raining M anager ( ~ £ 60K) to be hired to manage the training function, and aim for 50% margin s , with the other half paying towards HDM - 4 experts and room hire etc. but again it appears th is model also just about breaks even. 10.5 Accreditation Revenue Accreditation models for both training and consultancy can be an effective way to generate additional revenue. By providing certification for external consultants and training providers to customers, the HDM - 4 Redeveloper can help users get the most out of their software and increase their proficiency in utilisation. The HDM - 4 Redeveloper could offer a certification program me that provides in - depth training on the software as well as road asset management best practices. The program me could include both online and in - person training, as well as an exam to earn the certification. The price for the certification program me could range from a few hundred to a few thousand dollars, depending on the level of training provided and the level of certification. A certification program me for consultants who deploy HDM - 4 could be a valuable addition to the revenue strategies. By offering certification to consultants who are experienced in deploying the software, the HDM - 4 Redeveloper can provide an additional layer of trust and expertise to their customers. Here are some potential benefits of this revenue strategy: • Improved customer satisfaction: By providing customers with certified consultants who have a high level of expertise in deploying the software, the HDM - 4 Redeveloper can improve customer satisfaction and confidence in the software. • Competitive advantage: Offering a certification program me for consultants can differentiate the software from competitors and provide a unique selling point. • Additional revenue: By charging for certification program me s, the HDM - 4 Redeveloper can generate additional revenue streams. • Better quality control: By certifying consultants, the HDM - 4 Redeveloper can ensure that the software is being deployed in a consistent and high - quality manner. • Better geographic reach: By certifying consultants and trainers across the world, the HDM - 4 Redeveloper can increase the reach of its products, which are global by nature, at a lower cost. 10.5.1 Training Accreditation To implement this revenue strategy, we would expect the organisation to partner with industry organi s ations or academic institutions to provide certification and accreditation for these program me s. The HDM - 4 Redeveloper could charge for these program me s either as a one - time fee or as a subscription - based model. 55 FINAL BUSINESS PLAN REPORT It is important to assess the potential costs and benefits of this revenue strategy, as well as the level of demand for such program me s in the market. However, overall, an accreditation model for training and consultancy could make a small contribution in revenues and help support both the sales volume and stickiness of the recurring software revenue s . Below are some real world examples: • Microsoft offers a variety of certification program me s for their software products, including Microsoft Office, Microsoft Azure, and Microsoft Dynamics. For example, their Microsoft Certified: Azure Administrator Associate certification program provides training and an exam to earn certification in administering Azure cloud services. The cost for the certification e xam is $165 USD. • Oracle offers certification program me s for a range of their software products, including Oracle Database, Java, and Oracle Cloud. Their Oracle Certified Professional, Java SE 11 Developer certification program provides training and an exam to earn certification in Java programming. The cost f or the certification exam is $245 USD. • IBM offers a variety of certification program me s for their software products, including IBM Cloud, IBM Data and AI, and IBM Security. Their IBM Certified Solution Architect - Cloud Pak for Integration v2020.1.x certification program provides training and an exam to earn certification in deploying IBM C loud Pak for Integration solutions. The cost for the certification exam is $200 USD. • Salesforce offers a variety of certification program me s for their software products, including Salesforce Administrator, Salesforce Developer, and Salesforce Architect. Their Salesforce Certified Administrator program provides training and an exam to earn certification in administering Salesforce software. Th e cost for the certification exam is $200 USD. • HubSpot offers certification program me s for their marketing, sales, and service software products. Their HubSpot Inbound Marketing Certification program me provides training and an exam to earn certification in inbound marketing techniques. The program is free to access and complete. 10.5.2 Consultant Accreditation To implement this revenue strategy, the HDM - 4 Redeveloper would need to provide a certification program me for consultants that includes training and an exam to earn the certification , which could be as a one - time fee, or as a recurring subscription - based model. Many major technology companies offer certification program me s for their software products. Here are a few examples: • Red Hat: Red Hat offers certification program me s for their software products, including Red Hat Enterprise Linux, Red Hat OpenShift, and Red Hat Ansible Automation. Their Red Hat Certified System Administrator (RHCSA) program provides training and an exam to earn certification in administering Red Hat Enterprise Linux. The cost for the certification exam is $400 USD. • SAP: SAP offers certification programs for their software products, including the SAP ERP system. Their SAP Certified Application Associate - Business Process Integration with SAP ERP 6.0 EHP7 certification program me provides training and an exam to earn certification in deploying the SAP ERP system. The certification is aimed at consultants who deploy and configure the SAP ERP system for customers. The cost for the certification exam is €500 EUR. • Adobe Certified Associate (ACA): Adobe offers the ACA certification program for their Creative Cloud software products, including Photoshop, InDesign, and Illustrator. The program me offers three levels of certification: Associate, Specialist, and Expert. The program is open to students, educators, and creative professionals, and the fee for the exam varies by location. For example, in the United States, the fee for the ACA exam is $9 5 for students and educators, and $225 for creative professionals. • Cisco Certified Internetwork Expert (CCIE): Cisco offers the CCIE certification program for their networking and security software products. The program offers a range of certification tracks, including Routing and Switching, Security, and Collaboration. T he program me is open to networking professionals, and the fee for the exam is $450 USD. The pricing for this certification program me could range from a few hundred to a few thousand dollars, depending on the level of expertise required and the scope of the program me . The HDM - 4 Redeveloper could 56 FINAL BUSINESS PLAN REPORT also offer ongoing support and training to certified consultants to ensure that they remain up to date on the latest features and best practices for deploying the software. 10.5.3 Academic Accreditation Whilst not expecting to generate much revenue, the Research and Academic communities could also be covered by an accreditation scheme, as there are many software companies that offer academic and research program me s for universities and other academic institutions. These program me s typically provide free or discounted access to the software, as well as resources for teaching and research. Here are a few examples: • Autodesk: Autodesk offers an Education Community program me that provides free access to their software products for educational and research purposes. The program me includes access to training resources and support, as well as opportunities to participate in design challenges and other events. • MathWorks: MathWorks offers an Academic Program me that provides access to their MATLAB and Simulink software products for use in teaching, research, and other academic projects. The program me includes access to training resources and support, as well as opportunities to participate in webinars and other events. • SAS: SAS offers an Academic Program me that provides access to their analytics software products for use in teaching and research. The program me includes access to training resources and support, as well as opportunities to participate in competitions and other events. In addition to providing value to academic and research organi s ations, these program mes can also help software companies build relationships with future customers and establish their software products as the industry standard in their respective fields. It is worth noting that the specifics of an accredited program me for academic and research organi s ations will depend on the nature of the software and the requirements for use in teaching and research. The cost of such a program me may vary depending on the level of access and support provided, and the number of licenses required , and discounts offered on HDM - 4 licenses (as the organisations in question might resist paying for accreditation). 10.5.4 Accreditation Fee Structure A ccreditation schemes for trainers and consultants can provide a way to ensure that the individuals or companies providing services related to the HDM software have the necessary skills and knowledge to do so effectively. This can help to maintain the quality of service, build trust with customers, and ultimately lead to increased revenue from core sales uplift . For consultants, an accreditation scheme could involve a process of vetting and certification, which could include a review of the consultant's experience, skills, and references, as well as an examination. The certification could be valid for a certain pe riod of time, with the consultant needing to renew it periodically to maintain their accreditation. The pricing for these schemes could vary depending on the level of accreditation or certification, with higher levels of accreditation or certification requiring more rigorous testing and therefore higher fees. Alternatively, the fees could be based on a s liding scale depending on the size of the company or the number of consultants or trainers seeking accreditation. Here is a sample fee structure that could be used for a basic accreditation program me : For Trainers: • Training accreditation: This could require a certain number of years of experience in the field, a track record of successful engagements, and an exam, and could be priced at £1,000 per person , with a renewal fee of £500 every 2 years. For C onsultants, the fee structure could be based on a review of their experience, skills, and references, as well as an examination. Here is a sample fee structure for a consultant accreditation program me : • Vetting and certification: This could include a review of the consultant's experience, skills, and references, as well as an examination, and could be priced at £ 2 ,000 per consultant. 57 FINAL BUSINESS PLAN REPORT • Certification renewal: To maintain their certification, consultants may need to renew their certification periodically, which could be priced at £ 1 00 0 per renewal every 2 years . For Research Organisations : • An academic accreditation programme could be £5,000 per institution . • Certificate renewal fee of £2,500 every 2 years. These are just sample fee structures, and the actual fees may vary depending on the specifics of the program me . For example, a program me with a higher level of accreditation or certification may require more rigorous testing and therefore higher fees. Alternatively, the fees could be based on a sliding or tiered scale depending on the size of the company or the number of consultants or trainers seeking accreditation. 10.5.5 Accreditation Revenue Models Below is a revenue model for an accreditation scheme for trainers and consultants, based on the fee structure provided above. • Assumptions: § The HDM - 4 Redeveloper offers a non - tiered accreditation scheme for trainers, a vetting and certification programme for consultants, and an academic accreditation programme for universities and research institutions. § The fee for the training accreditation scheme is £1,000 per person. § The fee for the consultant certification programme is £2,000 per consultant. § The fee for the academic accreditation programme is £5,000 per institution. • Revenue Model: § Number of training accreditation programmes sold per year: 20 § Revenue from training accreditation programmes per year: 20 x £1,000 = £20,000 § Number of consultant vetting, and certification programmes sold per year: 20 § Revenue from consultant vetting and certification programs per year: 20 x £2,000 = £40,000 § Number of academic accreditation programmes sold per year: 5 § Revenue from academic accreditation programmes per year: 5 x £5,000 = £25,000 § Total revenue from accreditation and certification programs per year: £85,000 This revenue model is based on the assumptions listed above and is for illustrative purposes only. The actual revenue the HDM - 4 Redeveloper may generate from accreditation and certification program me s will depend on a variety of factors, such as the number of program me s sold and the pricing strategy. The margins are obviously good, however in terms of costs, an Accreditation Manager will need to be hired (~£60K) to manage the various programmes, and yet again, although strategically valuable it appears the model just about breaks even. 58 FINAL BUSINESS PLAN REPORT 11. Risks , Assumptions, Issues and Dependenc i es A Risks, Assumptions, Issues, and Dependencies (RAID) log is a useful tool for tracking and managing during the course of a project or business plan execution and a sample applied to the redevelopment of HDM - 4 are provided below with their corresponding mitigations /actions. Any scoring range s from 1 to 5, with 1 being the lowest severity or impact and 5 being the highest. 11.1 Risks Table 11 - 1 Risk Log Category ID Description Score Mitigation/Impact Actions Risks R1 Disagreement of IPR and stakeholders unhappy with proposed IP ownership changes 4 Negotiate and clarify IP ownership with stakeholders Engage stakeholders in discussions, seek legal advice Risks R2 Eric Stannard leaves before the HDM - 4 Product is redeveloped 4 Ensure knowledge transfer and secure key resources Identify and engage potential successors, document knowledge Risks R3 Product Director approach to product strategy and development differs from steering committee 3 Establish clear communication and alignment between parties Regular updates, meetings, and reviews Risks R4 Target market changes significantly during product redevelopment 3 Monitor market trends and adapt the product strategy accordingly Conduct market research, adjust strategy as needed Risks R5 Delays in launch of redeveloped HDM - 4 software extends beyond expected timeframes due to technical difficulties 4 Implement robust project management and contingency planning Set realistic timelines, allocate resources, monitor progress Risks R6 PIARC royalty demand too high a share of revenues, leading to an unsustainable future HDM - 4 Redeveloper 3 Negotiate royalty rates with PIARC Prepare a financial analysis, engage in negotiations with PIARC Risks R7 Alternative vendor software comes to market that meets or exceeds the current defined requirements of the World Bank 2 Continuously improve HDM - 4 and maintain its competitive edge Monitor competitors, invest in R&D, adapt to market needs 59 FINAL BUSINESS PLAN REPORT 11.2 Assumptions Table 11 - 2 Assumptions Log Category ID Description Score Mitigation/Impact Actions Assumptions A1 There are sufficient bidders 2 Market analysis and outreach to potential bidders Engage potential bidders, promote the opportunity Assumptions A2 IP ownership can be transferred from WB to HDM - 4 Redeveloper 3 Clarify IP ownership and transfer process with WB Seek legal advice, discuss with WB Assumptions A3 We can agree on a concession model in parallel to IP issues 3 Develop a mutually acceptable concession model Engage stakeholders, refine the model Assumptions A4 Brand is strong and considered intellectual property 2 Strengthen and maintain the brand Develop marketing strategy, monitor brand reputation Assumptions A5 Image and reputation remain strong 2 Monitor and address any issues that could impact image or reputation Regularly review feedback, address issues Assumptions A6 Adequate funding is provided 4 Secure sufficient funding for the project Identify funding sources, prepare funding proposals Assumptions A7 Business plan meets requirement for social good and offers value for money to the customer 3 Review and refine the business plan Conduct stakeholder consultations, revise plan Assumptions A8 Eric Stannard is retained as a key resource for technical advice 4 Maintain engagement and secure his expertise Establish a consulting arrangement, regular updates Assumptions A9 Customer needs do not change significantly during product redevelopment 3 Continuously monitor customer needs and adapt the product as needed Conduct market research, engage customers Assumptions A10 Critical Success Factors and Key Performance Indicators are defined 2 Develop and implement CSFs and KPIs Establish performance monitoring framework 60 FINAL BUSINESS PLAN REPORT 11.3 Issues Table 11 - 3 Issues Log Category ID Description Score Mitigation/Impact Actions Issues I1 IPR original documentation is required for review 4 Obtain IPR documentation from relevant parties Request documentation from WB and other stakeholders Issues I2 WB and SC management of the HDM - 4 Redeveloper 3 Establish clear roles and responsibilities for management Define governance structure, engage with WB and SC Issues I3 Delivery and management team is required to undertake the next phase of the programme 3 Recruit and assemble a qualified delivery and management team Identify key positions, advertise, and hire Issues I4 Policy on upgrade for existing HDM - 4 licence holders needs to be agreed 4 Develop a fair and attractive upgrade policy for existing licensees Draft policy, discuss with stakeholders, finali s e Issues I5 Suitably knowledgeable sales and marketing team will require training in the new product 3 Train the sales and marketing team on the new product features and use Organi s e training sessions, provide resources 11.4 Dependencies Table 11 - 4 Dependencies Log Category ID Description Score Mitigation/Impact Actions Dependencies D1 Sufficient capital is raised to complete the project to the point of launch 3 Ensure adequate funding is secured for project completion Develop a funding strategy, engage potential investors Dependencies D2 A new steering committee is created that provides suitable direction to a new Product Director 4 Form a steering committee with the right expertise and experience Identify and invite relevant stakeholders to join Dependencies D3 Suitably experienced software engineering resources are available when they are required 3 Plan and allocate resources to ensure availability during development Assess resource needs, hire, and allocate resources 61 FINAL BUSINESS PLAN REPORT Category ID Description Score Mitigation/Impact Actions Dependencies D4 Continuity of steering group for the next phases of the project is required to maintain a consistent strategy 3 Ensure commitment and engagement of the steering group for project duration Regular meetings, ongoing communication, define roles Dependencies D5 Sales pipeline needs to be created during product redevelopment phase 4 Develop a sales strategy and initiate marketing activities Plan marketing campaigns, generate leads, follow up The above tables represent a comprehensive starting point for the potential risks, assumptions, issues, and dependencies associated with the HDM - 4 business plan. This information can help guide decision - making and ensure that the project runs smoothly. Figure 11 - 1 b elow is an illustration summarising the RAID log s : Figure 11 - 1 HDM - 4 Risks, Assumptions, Issues and Dependenc i e s 62 FINAL BUSINESS PLAN REPORT 12. Financia ls 12.1 Assumptions The financials are centred on a commercially successful software platform hosted as a Software as a Service (SaaS) propositio n within the cloud. This approach allows for reduced operating costs and enables real - time and frequent updates, facilitating the software's evolution. While the potential for incorporating new modules that address other socio - economic transport factors is supported, they have not been included in the business plan. Instead, we expect these modules to be funded through regional sid e projects or future revenues. The development period is 36 months with a small development team, and the capital required to establish a sustainable business and reach a minimum viable product is £3.3 million ($3.927m). This figure allows for robust corpo rate governance, recruitment of a development and management team, working capital, operational expenses, and the software's launch costs before forecasted recurring revenues lead to break - even. This development period also offers extra time to incorporate advanced models, such as Low Carbon Policies (GHG), which our parallel HDM - 4 User Requirements study identified as a priority. This is in line with Multilateral Development Banks' agreement to only fund projects that align with the Paris Agre ement. Furthe rmore, the business plan includes a simplified contribution from the alternative revenue approaches and models discussed in section 10 above . To avoid confusion, the business plan currency is in UK Sterling, with cost estimates based on a UK location and then converted using an exchange rate of 1.19 USD. We recommend that the investment be made upfront to reduce risk and instil confidence in staff and suppliers. However, recogn ising that this app roach may not suit all donors, we have modelled three milestone investments of £1 million in the first three years, with a final payment of £300 ,000 in year four, where breakeven occurs. In producing the Financial Plan, we have conducted several sensitivity analyses, which help identify the factors that have the greatest impact on the success of a project by examining how changes in individual variables affect the overall project outcome. In the context of the HDM - 4 business plan, and in order of greatest impact the key fac tors that may be sensitive to the project's success include: • Development costs: Changes in development scope , leading to increased expenses for software engineers or a longer development time , can significantly impact the required initial investment and the project's overall profitability , as recurring revenues arrive later. • Sales projections: The business plan's success is dependent on accurate sales projections , which in turn is reliant upon convincing existing license holders to sign up and pay (again). If the actual sales volume or average sales price deviates significantly from the estimates, the project's financial performa nce will be affected. • Market demand: The adoption rate of the new HDM - 4 software and its market penetration will directly impact the project's revenues. Any changes in market demand or the competitive landscape could influence the success of the project. • Implementation timeline: Delays in the software development process or unforeseen technical challenges may result in increase d costs and impact the project's overall timeline. This could affect the project's break - even point . • Alternative revenue streams: The contribution of alternative revenue streams, such as licensing, training provision, and accr editation, may be subject to fluctuations. Any significant changes in these revenue streams could affect the project's overall fina ncial performance. To further assess the sensitivity of these factors, one can perform a sensitivity analysis by adjusting each variable within a reasonable range and observing the impact on the project's financial performance in the accompanying Excel spreadsheet . This will help identify which factors are most critical to the project's success and allow one to develop contingency plans and mitigation strategies to address potential risks. 63 FINAL BUSINESS PLAN REPORT 12.2 Revenue & Earnings Figure 12 - 1 Revenue and Earnings Earnings Yr01 Yr02 Yr03 Yr04 Yr05 Yr06 Yr07 Yr08 Yr09 Yr10 Yr11 Total Old Base Revenue 0 0 0 0 0 0 0 0 0 0 0 0 New Base Revenue 0 0 0 390, 681 1, 370, 780 2, 292, 438 2, 790, 828 3, 029, 133 3, 132, 856 3, 195, 396 3, 259, 181 19, 461, 293 Alternative Revenues 0 0 0 315, 400 321, 708 328, 142 334, 705 341, 399 348, 227 355, 192 362, 295 2, 707, 068 0 Total Revenue 0 0 0 706, 081 1, 692, 488 2, 620, 580 3, 125, 533 3, 370, 532 3, 481, 083 3, 550, 588 3, 621, 476 22, 168, 361 PIARC Royalty 0 0 0 0 0 0 0 0 0 0 0 0 Gross Margi n 0 0 0 706, 081 1, 692, 488 2, 620, 580 3, 125, 533 3, 370, 532 3, 481, 083 3, 550, 588 3, 621, 476 22, 168, 361 Headcount Costs Employee Costs 714, 860 729, 157 839, 384 647, 755 659, 977 672, 199 684, 421 696, 643 708, 864 721, 086 733, 308 7, 807, 655 Recruitment Costs 124, 000 0 16, 000 24, 000 0 0 0 0 0 0 0 140, 000 Opex Costs Offi ce/I T 42, 000 42, 840 48, 066 35, 657 36, 370 37, 097 37, 839 38, 596 39, 368 40, 155 40, 958 438, 946 Ba nki ng 600 612 624 637 649 662 676 689 703 717 731 7, 300 Cl oud cos ts 6, 000 6, 120 6, 242 81, 504 83, 134 84, 797 86, 493 88, 222 89, 987 91, 786 93, 622 717, 907 Ma teri a l s 1, 200 1, 224 1, 248 1, 273 1, 299 1, 325 1, 351 1, 378 1, 406 1, 434 1, 462 14, 601 Lega l 6, 000 6, 120 6, 242 6, 367 6, 495 6, 624 6, 757 6, 892 7, 030 7, 170 7, 314 73, 011 Ac c o u n ta n c y 6, 000 6, 120 6, 242 6, 367 6, 495 6, 624 6, 757 6, 892 7, 030 7, 170 7, 314 73, 011 Ma rketi ng 1, 200 1, 224 1, 248 1, 273 1, 299 1, 325 1, 351 1, 378 1, 406 1, 434 1, 462 14, 601 Sta ti ona ry 1, 200 1, 224 1, 248 1, 273 1, 299 1, 325 1, 351 1, 378 1, 406 1, 434 1, 462 14, 601 Tr a vel & Subs i s tenc e 6, 000 6, 120 6, 242 6, 367 6, 495 6, 624 6, 757 6, 892 7, 030 7, 170 7, 314 73, 011 Uti l i ti es 1, 200 1, 224 1, 248 1, 273 1, 299 1, 325 1, 351 1, 378 1, 406 1, 434 1, 462 14, 601 Insurance 1, 200 1, 224 1, 248 1, 273 1, 299 1, 325 1, 351 1, 378 1, 406 1, 434 1, 462 14, 601 Mi s c./petty ca s h 1, 200 1, 224 1, 248 1, 273 1, 299 1, 325 1, 351 1, 378 1, 406 1, 434 1, 462 14, 601 HDM-4 Expert 60, 000 60, 000 60, 000 60, 000 60, 000 60, 000 60, 000 60, 000 60, 000 60, 000 60, 000 660, 000 133, 800 135, 276 141, 151 204, 540 207, 430 210, 378 213, 385 216, 452 219, 580 222, 771 226, 026 2, 130, 790 EBI TDA (972,660) (864,433) (996,535) (170,214) 825, 081 1, 738, 003 2, 227, 727 2, 457, 437 2, 552, 638 2, 606, 730 2, 662, 142 12, 089, 916 Depreciation 0 0 0 0 0 0 0 0 0 0 0 0 EBIT (972,660) (864,433) (996,535) (170,214) 825, 081 1, 738, 003 2, 227, 727 2, 457, 437 2, 552, 638 2, 606, 730 2, 662, 142 12, 089, 916 Interest Tax Earni ngs (972,660) (864,433) (996,535) (170,214) 825, 081 1, 738, 003 2, 227, 727 2, 457, 437 2, 552, 638 2, 606, 730 2, 662, 142 12, 089, 916 Cum Earnings (972,660) (1,837,093) (2,833,628) (3,003,842) (2,178,761) (440,759) 1, 786, 969 4, 244, 406 6, 797, 044 9, 403, 774 12, 065, 916 64 FINAL BUSINESS PLAN REPORT 12.3 Cashflow Analysis Figure 12 - 2 Cashflow Analysis Cashflow Yr01 Yr02 Yr03 Yr04 Yr05 Yr06 Yr07 Yr08 Yr09 Yr10 Yr11 Total Opening Balance 0 40, 988 176, 998 183, 706 (7,469) 496, 289 1, 906, 535 3, 799, 943 5, 916, 368 8, 121, 167 10, 373, 093 0 Donor/Investment 1, 000, 000 1, 000, 000 1, 000, 000 300, 000 0 0 0 0 0 0 0 3, 300, 000 Old Base Revenue 0 0 0 0 0 0 0 0 0 0 0 0 New Base Revenue 0 0 0 390, 681 1, 370, 780 2, 292, 438 2, 790, 828 3, 029, 133 3, 132, 856 3, 195, 396 3, 259, 181 19, 461, 293 Other Revenue 0 0 0 0 0 0 0 0 0 0 0 0 Total Income 0 0 0 390, 681 1, 370, 780 2, 292, 438 2, 790, 828 3, 029, 133 3, 132, 856 3, 195, 396 3, 259, 181 19, 461, 293 PIARC Royalty 0 0 0 0 0 0 0 0 0 0 0 0 Staff - Net Pay 464, 659 473, 952 545, 600 421, 041 428, 985 436, 929 444, 874 452, 818 460, 762 468, 706 476, 650 5, 074, 976 Staff - PAYE/NI 242, 903 254, 788 290, 569 232, 304 230, 636 234, 913 239, 191 243, 468 247, 746 252, 024 256, 301 2, 724, 844 Recruitment Costs 124, 000 0 16, 000 24, 000 0 0 0 0 0 0 0 164, 000 Opex Costs 127, 450 135, 249 141, 124 204, 511 207, 401 210, 349 213, 355 216, 422 219, 549 222, 740 225, 994 2, 124, 145 Interest 0 0 0 0 0 0 0 0 0 0 0 0 Tax 0 0 0 0 0 0 0 0 0 0 0 0 Total Spend 959, 012 863, 989 993, 293 881, 856 867, 022 882, 191 897, 419 912, 708 928, 057 943, 470 958, 945 10, 087, 964 Capital Spend 0 0 0 0 0 0 0 0 0 0 0 0 Net Cashflow 40, 988 136, 011 6, 707 (191,175) 503, 758 1, 410, 246 1, 893, 409 2, 116, 425 2, 204, 798 2, 251, 927 2, 300, 236 12, 673, 329 Closing Balance 40, 988 176, 998 183, 706 (7,469) 496, 289 1, 906, 535 3, 799, 943 5, 916, 368 8, 121, 167 10, 373, 093 12, 673, 329 12, 673, 329 65 FINAL BUSINESS PLAN REPORT 12.4 Cashflow Forecast Figure 12 - 3 Cashflow Forecast 66 FINAL BUSINESS PLAN REPORT 12.5 Profit & Loss Figure 12 - 4 Profit & Loss 67 FINAL BUSINESS PLAN REPORT 12.6 Balance Sheet Analysis Figure 12 - 5 Balance Sheet Analysis Balance Sheet Yr01 Yr02 Yr03 Yr04 Yr05 Yr06 Yr07 Yr08 Yr09 Yr10 Yr11 12 24 36 48 60 72 84 96 108 120 132 Fixed Assets Bal B/fwd 0 0 0 0 0 0 0 0 0 0 0 Additions 0 0 0 0 0 0 0 0 0 0 0 Depreciation 0 0 0 0 0 0 0 0 0 0 0 Net Book Value 0 0 0 0 0 0 0 0 0 0 0 Current Assets Debtors 0 0 0 0 0 0 0 0 0 0 0 Bank 40, 988 176, 998 183, 706 (7,469) 496, 289 1, 906, 535 3, 799, 943 5, 916, 368 8, 121, 167 10, 373, 093 12, 673, 329 Total 40, 988 176, 998 183, 706 (7,469) 496, 289 1, 906, 535 3, 799, 943 5, 916, 368 8, 121, 167 10, 373, 093 12, 673, 329 Costs Incurred Paid In Month Creditors 13, 648 14, 092 17, 334 11, 773 12, 158 12, 544 12, 930 13, 317 13, 704 14, 092 14, 481 Net Assets 27, 340 162, 907 166, 372 (19,242) 484, 131 1, 893, 991 3, 787, 014 5, 903, 052 8, 107, 462 10, 359, 001 12, 658, 848 Financed By Investment 1, 000, 000 2, 000, 000 3, 000, 000 3, 300, 000 3, 300, 000 3, 300, 000 3, 300, 000 3, 300, 000 3, 300, 000 3, 300, 000 3, 300, 000 Profit & Loss (972,660) (1,837,093) (2,833,628) (3,003,842) (2,178,761) (440,759) 1, 786, 969 4, 244, 406 6, 797, 044 9, 403, 774 12, 065, 916 27, 340 162, 907 166, 372 296, 158 1, 121, 239 2, 859, 241 5, 086, 969 7, 544, 406 10, 097, 044 12, 703, 774 15, 365, 916 Check Total 0 0 0 (315,400) (637,108) (965,250) (1,299,955) (1,641,354) (1,989,581) (2,344,773) (2,707,068) 68 FINAL BUSINESS PLAN REPORT 12.7 Employee Costs Figure 12 - 6 Employee Costs Employee Costs Base NI Pens Total Start End Position Yr01 Yr02 Yr03 Yr04 Yr05 Yr06 Yr07 Yr08 Yr09 Yr10 Yr11 Total 12.30% 3% Month Month 90, 000 11, 070 2, 700 103, 770 1 132 Internal Product Owner 103, 770 105, 845 107, 921 109, 996 112, 072 114, 147 116, 222 118, 298 120, 373 122, 449 124, 524 1, 255, 617 40, 000 4, 920 1, 200 46, 120 1 132 Business Analyst 46, 120 47, 042 47, 965 48, 887 49, 810 50, 732 51, 654 52, 577 53, 499 54, 422 55, 344 558, 052 30, 000 3, 690 900 34, 590 1 132 Financial Admin 34, 590 35, 282 35, 974 36, 665 37, 357 38, 049 38, 741 39, 433 40, 124 40, 816 41, 508 418, 539 80, 000 9, 840 2, 400 92, 240 1 132 Data Engineer 1 (SRE) 92, 240 94, 085 95, 930 97, 774 99, 619 101, 464 103, 309 105, 154 106, 998 108, 843 110, 688 1, 116, 104 60, 000 7, 380 1, 800 69, 180 1 36 Graphi c De si gne r 69, 180 70, 564 71, 947 - - - - - - - - 211, 691 90, 000 11, 070 2, 700 103, 770 1 132 Te chni cal Le ad 103, 770 105, 845 107, 921 109, 996 112, 072 114, 147 116, 222 118, 298 120, 373 122, 449 124, 524 1, 255, 617 60, 000 7, 380 1, 800 69, 180 1 36 Del i very Manager 69, 180 70, 564 71, 947 - - - - - - - - 211, 691 80, 000 9, 840 2, 400 92, 240 25 132 Sales & Marketing Dir - - 95, 930 97, 774 99, 619 101, 464 103, 309 105, 154 106, 998 108, 843 110, 688 929, 779 70, 000 8, 610 2, 100 80, 710 1 36 Senior Developer 1 80, 710 82, 324 83, 938 - - - - - - - - 246, 973 60, 000 7, 380 1, 800 69, 180 37 132 Trai ni ng Manange r - - - 73, 331 74, 714 76, 098 77, 482 78, 865 80, 249 81, 632 83, 016 625, 387 60, 000 7, 380 1, 800 69, 180 37 132 Accreditation Manager - - - 73, 331 74, 714 76, 098 77, 482 78, 865 80, 249 81, 632 83, 016 625, 387 50, 000 6, 150 1, 500 57, 650 1 36 Mi d Le v e l De v e l o p e r 1 57, 650 58, 803 59, 956 - - - - - - - - 176, 409 50, 000 6, 150 1, 500 57, 650 1 36 Mi d Le v e l De v e l o p e r 2 57, 650 58, 803 59, 956 - - - - - - - - 176, 409 Total 714, 860 729, 157 839, 384 647, 755 659, 977 672, 199 684, 421 696, 643 708, 864 721, 086 733, 308 7, 807, 655 Net Pay 65% Cashflow 464, 659 473, 952 545, 600 421, 041 428, 985 436, 929 444, 874 452, 818 460, 762 468, 706 476, 650 5, 074, 976 PAYE/NI 35% 242, 903 254, 788 290, 569 232, 304 230, 636 234, 913 239, 191 243, 468 247, 746 252, 024 256, 301 2, 724, 844 Hodos Media Limited Peregrine House Ford Lane Ford Arundel West Sussex United Kingdom BN18 0DF Tel: +44 (0) 1243 558 092 Email: info@hodosmedia.com Web: www.hodosmedia.com t