The record, with honest attributions.

The challenge

Zanzibar's blue economy, meaning fisheries, seaweed, marine conservation and coastal livelihoods, is implemented by more than 20 development partners and 40 NGOs at once. Under the Agriculture and Fisheries Development Programme (AFDP), a USD 58.85M programme funded by IFAD, the International Fund for Agricultural Development, the ministry commissioned a management information system to bring all of that activity into one place.

Before the system, the ministry had no consolidated view of who was doing what, where. Coordination ran on fragmented Excel spreadsheets and email chains, and that produced three concrete problems. NGOs carried duplicative reporting burdens, with the same project data requested repeatedly in different formats by different offices. Geographic coordination gaps were invisible: nobody could see that one district had five overlapping livelihood projects while a neighbouring one had none. And evidence-based policy decisions were effectively impossible, because the evidence lived in dozens of disconnected files. The pain was sharpest during IFAD supervision missions, when assembling a single data package took roughly three days of manual compilation and reformatting, every time.

There was also nothing to buy. To the team's knowledge, no purpose-built blue economy coordination platform existed anywhere; multi-stakeholder policy coordination with spatial project tracking is not a category commercial software covers. It had to be built.

The approach

Herman designed and built the entire system end-to-end in a four-week engagement. Three design decisions carried it.

Map-native architecture. PostgreSQL 16 with PostGIS as the spatial foundation, and the map as the primary interface rather than a feature bolted onto a table view. Projects render on an interactive Leaflet map with district and conservation-area overlays, so geographic gaps are visible by default: the empty district is on screen before anyone has to run a query.

Adoption as architecture. Government systems die when the first user opens an empty database and a 40-field form. The adoption mechanics were encoded into the technical design instead of left to training: the system launched pre-populated with 15+ real projects, every data-collection form is limited to fewer than 15 fields, and the payoff is immediate. Submit a project and it appears on the map alongside everyone else's.

Sovereign by design. The stack is entirely open source: Next.js 15 App Router, PostgreSQL with Drizzle ORM, Auth.js, shadcn/ui and Recharts, deployed with Docker Compose on Tanzanian infrastructure. No vendor lock-in, no licence fees, and the system is scoped so the ministry's own IT officer can operate it without ongoing international developer support.

On that base sit four-tier role-based access control, standardised forms for partners, projects and institutions, and automated IFAD-compatible exports, with a design target of cutting the three-day report scramble to under one hour. The four-week build sat inside a February-to-June 2026 delivery arc: site inspection on 13 March, client presentation on 27 April, and training delivered to four distinct user segments on 28 April.

The result

The system is live at mis.blueeconomysmz.go.tz and in real use. A public dashboard gives every stakeholder a transparent view of blue economy activity across Zanzibar, while role-based access separates what ministry staff, development partners and NGO users can see and edit. The interactive map covers all Zanzibar districts and conservation areas, so programming gaps that used to be invisible are now the first thing a viewer notices.

The reporting target held: at acceptance, generating an IFAD-compatible data package took under one hour, against the roughly three days of manual Excel work it replaced.

The result weighted most heavily here is quieter than any launch metric. Between go-live and 23 June, the system went through three post-launch change cycles, every one driven by ministry staff actually working in it. Change requests from real daily use are the difference between software that was delivered and software that was adopted: a wishlist gets written before launch, but friction reports only come from people who depend on the thing. To the team's knowledge this is the first purpose-built blue economy coordination platform anywhere, and it runs on open-source software, on Tanzanian servers, under the ministry's full control.

The challenge

Tanzania Posts Corporation now operates a national e-commerce marketplace, funded by the World Bank under the Digital Tanzania Project. Before this programme, Tanzania's e-commerce ecosystem was fragmented in ways no single vendor could fix. The programme's readiness work, completed before this engagement began, had already mapped the gaps: no unified marketplace where Tanzanian sellers and buyers could meet, no interbank payment integration for online commerce, no mechanism for a consumer to tell a legitimate e-commerce site from a fraudulent one, and no integration with government tax systems. The consequence was predictable: low consumer trust, no standardised payment rails, and businesses unable to participate in the digital economy at any real scale.

Closing those gaps is not a website build. It is a marketplace, a payments integration with the national interbank settlement system, a public key infrastructure for trust certification, and a government integration layer. Each component carries its own stakeholders, security requirements and approval chain, and the whole is delivered by a team split across local and international partners.

The approach

Herman manages the full 59-week project lifecycle as Project Manager, from detailed design through development to deployment. Design came first, and it was treated as a phase with teeth rather than a formality: data models, level 3 business process maps, and system architecture for every use case defined in the Business Requirement Document, with stage-by-stage approvals before any development began. On a government programme with this many parties, that discipline is what keeps fifteen-plus people building the same system instead of fifteen different ones.

From there, the work is coordination of the joint-venture development team across the platform's components. The marketplace itself, the storefront layer where sellers list and buyers transact. An Enterprise Service Bus, a standardised integration layer so every ecosystem component talks through one contract instead of a web of point-to-point connections. Promise-to-Pay payment functions integrated with the Tanzania Interbank Settlement System (TIPS), so online transactions settle through the country's actual banking rails. PKI infrastructure and a Trust Label system, cryptographic certification that lets legitimate e-commerce websites prove they are what they claim to be. And government tax system integration, so compliance is built into the platform rather than bolted on.

The platform itself runs on Angular over Django and PostgreSQL, containerised with Docker, with the Enterprise Service Bus and PKI infrastructure alongside.

One deliverable was pushed to stay in scope rather than become an afterthought: knowledge transfer. A DevOps shadowing environment ran for Tanzania Posts Corporation's Innovation Center staff throughout delivery, so the people who will maintain and extend the platform learned it by operating it alongside the delivery team, not by reading a handover document.

The result

The platform is delivered and operational, to Herman's knowledge Tanzania's first unified national digital marketplace. The Enterprise Service Bus provides the integration backbone connecting the ecosystem's components. Payments run through the TIPS integration. The PKI-based Trust Label system is deployed to certify legitimate e-commerce websites. The infrastructure runs across the eGA and TPC data centres with disaster recovery capability, and TPC Innovation Center staff have been through the full DevOps shadowing programme.

Commercial numbers are deliberately absent here: sellers onboarded, transaction volumes, GMV. Those figures belong to TPC and the programme, and showing nothing is better than showing estimates. What can be pointed to is the thing itself, in production, at kipepeoshop.co.tz.

What this engagement says about how the practice works: on a multi-party government programme, the project manager's job is sequencing and honesty. Get the design approved before the code is written, keep the integration contracts stable, and make sure the client's own engineers can run the system the day you leave. That is what happened here, and the engagement continues.

The challenge

Tanzania's National Construction Council establishes the base unit rates and costs for road construction and maintenance across all of mainland Tanzania. Government agencies budget real projects against those rates, so when the rates are slow to produce or hard to reach, allocation decisions wait. The entire costing workflow ran on Microsoft Excel.

The Excel models were not wrong, and that is worth saying first because it shaped the whole project: NCC's engineers had encoded the costing methodology correctly, and any replacement had to reproduce their numbers exactly, not approximately. The problems were everything around the calculations. Expertise lock-in: producing an estimate required engineering knowledge of the spreadsheets themselves, so the non-engineering users who depend on these rates for budgeting had no visibility into the numbers. Access: the spreadsheets lived on specific machines, and users in remote regions had no practical way to reach current rates. Maintenance: construction material prices are volatile and vary by region, so every price movement meant manual edits across regional spreadsheets.

The approach

Herman joined the delivery team as Business Analyst and Quality Assurance lead, two jobs deliberately paired: specify exactly what the system must compute, then prove that it computes it.

Business analysis. Working through NCC's existing Excel-based costing methodology and translating the engineering-domain requirements into technical specifications the developers could build against: construction resource libraries covering materials, labour and equipment; construction methods linked to those resources; regional pricing variations; and the rate computation formulas that tie it all together. Most of this work was translation in the literal sense, sitting between civil-engineering logic and software architecture and making sure nothing was lost in either direction.

Quality assurance. Because the Excel models were the ground truth, QA on this project meant reconciliation as much as functional testing. Test cases checked the platform's output against the original Excel calculations across every region and every construction activity type, and validated data integrity on every computation path. A costing platform that is 99% right is a budgeting liability, so the bar was exact replication.

Post-implementation support. After delivery, Herman stayed on as the primary system maintainer for the six-month support period: updates, bug fixes, user support, and the regional data updates that follow every material price change. Maintaining the system he had specified and tested closed the loop. The same regional price volatility that motivated the project became a routine data update instead of a spreadsheet-editing exercise. The delivery itself ran five months, with the six-month support period following on from it.

The result

The system is live and operational at cces.ncc.go.tz. By Herman's estimate, manual calculation time for construction cost estimates dropped by around 65%; computations that previously required Excel expertise from an engineer now run automatically. That figure is an estimate from the engagement rather than a client-audited measurement, and it is labelled accordingly.

Base unit rates for all administrative regions of mainland Tanzania now sit on one web platform, reachable from any device. Users search and filter by construction activity, method, region and tender mark-up, with no engineering background required. Contractors and agencies can upload a Bill of Quantities and have unit rates auto-populated from the system's established rates, replacing line-by-line manual pricing. And regional material pricing is updated centrally as prices move, instead of through edits scattered across regional spreadsheets.

This engagement is a useful counterexample to the idea that consulting value only comes from writing code. The code was written by a capable team; the contribution here was making sure the system computed the right things and proving that it did. For a platform the government budgets against, that is the part that cannot be allowed to fail.

The challenge

Tanzania Telecommunications Corporation (TTCL) is the country's national telco, established by Act of Parliament as its strategic telecommunications provider. Its 3-year Strategic Plan (2025/26–2027/28) committed the corporation to modernising how it operates. The reality on the ground: no integrated IT backbone. Finance, customer relationship management, sales and distribution, supply chain, inventory, project management, HR and enterprise performance management each ran on their own fragmented processes and disconnected applications. For a corporation with a statutory mandate as Tanzania's leading communications service provider, and a role in the national digital economy agenda, that fragmentation was a ceiling.

The fix was bigger than a decision to buy an ERP. Telecom is one of the harder industries to bring an ERP into, because the ERP is never the whole system: it has to sit alongside OSS/BSS (the operations and business support systems), billing platforms and FRAMS, and the boundaries between them have to be drawn deliberately, in advance. And as a public corporation, TTCL procures under Tanzania's Public Procurement Act, which means requirements, evaluation criteria and architecture must be settled before the RFP goes out, not negotiated with a vendor afterwards. Many ERP programmes fail exactly here, in the work that happens before any software is bought. Getting that pre-work right, before anything was bought, was the entire brief of Phase 1.

The approach

The engagement was structured in two phases. Herman served as Project Coordinator for Phase 1, the pre-implementation phase that took the corporation from fragmented processes to a complete requirements specification, a compliant procurement and an 18-month implementation roadmap. Its toolkit was consulting disciplines rather than code: enterprise architecture, business process re-engineering, requirements engineering and ERP vendor evaluation, coordinated across four streams.

As-is assessment. Evaluating TTCL's organisational structure, business processes, IT infrastructure and software applications across all eight business functions, documenting pain points, dependencies and integration requirements with the telecom systems already in production.

Business process re-engineering. Rather than automating the existing processes as found, the team redesigned them for the target operating model, with organisational structure recommendations to match. An ERP configured around broken processes just makes the broken processes faster.

Requirements engineering. Overseeing creation of the Functional Requirements Specification for all core ERP modules, aligned with telecommunications industry practice, and coordinating the Enterprise Architecture design using established models: a documented current state and an explicit target state.

Procurement and vendor selection. Preparing the ERP procurement RFP in compliance with the Public Procurement Act, technical assistance through vendor evaluation, scoring and selection, and an 18-month implementation roadmap with milestones.

The result

Phase 1 closed with TTCL holding everything it needs to implement with its eyes open. A current-state assessment across all eight business functions, with processes, pain points and integration requirements documented rather than assumed. Redesigned business processes and organisational recommendations for the digital operating model. A complete Functional Requirements Specification for a telecom-specific ERP, Finance through Enterprise Performance Management, including integration with OSS/BSS, billing platforms and FRAMS. An Enterprise Architecture blueprint defining the target state. Procurement documentation compliant with Tanzanian law, and a vendor selection framework that carried TTCL through evaluation and scoring. And the 18-month implementation roadmap, with milestones.

Pre-implementation work deserves to be framed as what it is: the transformation itself is delivered in Phase 2, on top of this foundation, and the quality of Phase 1 shows up in how implementation goes. What this phase bought TTCL is the thing ERP programmes most often skip, a requirements baseline and an architecture the corporation owns, so vendor selection became a comparison against TTCL's documented needs rather than a choice between sales decks.