Projektuppföljningssystem: guide för offentliga program 2026

Tre underjordiska lagringstankar i en och samma stad. De två små är klara. Den stora, som rymmer det mesta av vattnet staden blev lovad, står på 74 %. Tar du medelvärdet av de tre rapporterar staden 91,33 % klart. Viktar du varje tank efter den kapacitet den ger blir den ärliga siffran 75,70 %.

Det glappet på nästan sexton procentenheter är hela poängen med ett system för projektuppföljning. Ett kalkylark tar medelvärdet av procentsatser utan att protestera, en tjänsteman läser resultatet i god tro, och ingen märker något förrän någon står bredvid den stora tanken.

Den här guiden är skriven för dig som specificerar, köper eller ärver sådana system: projektledare på en PMU eller PIU och konsulterna som skriver deras uppdragsbeskrivningar. Vi skriver från operatörens stol. Sedan juli 2026 har NexGenix flyttat, byggt om och drivit PDP Executive Monitoring Dashboard för Punjab Development Program (PDP), som följer avlopps-, dag- och spillvattenarbeten i 52 städer. Tankexemplet kommer från systemets egen metoddokumentation.

Varför rapportering via kalkylark och WhatsApp faller på programnivå

De flesta program börjar på samma sätt. Varje plats skickar in en siffra, bilder hamnar i en WhatsApp-grupp och någon på huvudkontoret för över allt till en arbetsbok inför veckomötet. Med fem platser fungerar det. Med femtio städer faller det, alltid på samma ställen:

• Ingen kan bevisa ett foto. En vidarebefordrad bild säger inget pålitligt om var eller när den togs. Samma halvbyggda dike kan dyka upp tre veckor i rad.
• Procentsatser skrivs in, de mäts inte. "Dike 60 %" är en åsikt. Sextio procent av vilken längd, uppmätt av vem, vilken dag?
• Sammanställningen tar medelvärdet av olika saker. Se tankarna.
• Historiken försvinner. En arbetsbok visar veckans siffra, sällan att förra veckans var högre eller vem som ändrade den.
• Rapporten är sen av konstruktion. Två dagars sammanställning betyder en dragning om programmet som det såg ut för två dagar sedan.

Plattformar på provinsnivå tar inte bort behovet. Punjab har redan Smart Monitoring of Development Projects, där förvaltningar har lämnat månatliga lägesrapporter sedan 2016, och ett GIS-baserat Monitoring Observatory for Development Projects. De överblickar hundratals projekt. Ett programs eget system arbetar en nivå ner: per anläggning, per dag, med bevis bifogade.

Vad ett system för projektuppföljning måste klara

Uppdragsbeskrivningar efterfrågar påfallande lika saker, oavsett vem som finansierar arbetet: ett webbaserat och mobilt uppföljnings- och informationssystem, MIS med GIS, en Android-app som matar en central plattform, dashboards, manualer och utbildning. KfW Development Bank har till och med publicerat en guidebok om fjärrstyrning, uppföljning och verifiering. Etiketterna spelar mindre roll än beteendet. Det här är de tio förmågor vi skulle kräva.

1. Fältbevis som avslöjar manipulation

Ett foto ska bli bevis i samma ögonblick som det når servern. I PDP:s fältapp bränner servern in en banderoll i pixlarna på varje foto: program, stad, handläggare, koordinater, pakistansk tid och en kort verifieringskod som tas fram genom att hasha handläggaren, tiden och positionen. Servern stämplar med sin egen klocka, så en telefon inställd på förra tisdagen kan inte förfalska datumet.

En reservation: telefoner får inte alltid en GPS-position under ett betongbjälklag eller i en smal gränd, så registrera "inga koordinater" i stället för att hitta på dem.

2. En offline-app för fältet som inte kan rapportera två gånger

Platser tappar täckning. En app som kräver uppkoppling lär handläggare att fylla i poster på kvällen ur minnet. PDP:s app Field Progress köar inlämningar och foton på telefonen och synkar senare, och varje post har en egen referens, så att ett nytt försök aldrig rapporterar samma framsteg två gånger.

Mät i stället för att fråga där det går. Framdriften för avloppsledningar i PDP-appen kommer från linjen som handläggaren ritar över den projekterade sträckningen med telefonens GPS. Ingen skriver in en procentsats.

3. Viktad progress, inte medelvärden av procentsatser

Tillbaka till tankarna, steg för steg:

1. Varje anläggning får en position i sin egen enhet: utfört i förhållande till åtagande. Tank A rymmer 1 000 000 gallon och står på 74 %. Tank B (40 000 gallon) och C (30 000 gallon) är klara.
2. Det enkla medelvärdet är (74 + 100 + 100) ÷ 3 = 91,33 %.
3. Viktat efter kapacitet: 1 000 000 × 74 + 40 000 × 100 + 30 000 × 100 = 81 000 000.
4. Delat med den totala kapaciteten på 1 070 000 gallon ger det 75,70 %.

De små tankarna är klara, men det mesta av stadens nya lagring finns i den som inte är det. I kod räcker några rader:

// Tre underjordiska lagringstankar i en stad (kapacitet i gallon, progress i %)
const tanks = [
  { capacity: 1_000_000, progress: 74 },
  { capacity: 40_000, progress: 100 },
  { capacity: 30_000, progress: 100 },
];

const naive = tanks.reduce((sum, t) => sum + t.progress, 0) / tanks.length;

const weighted =
  tanks.reduce((sum, t) => sum + t.capacity * t.progress, 0) /
  tanks.reduce((sum, t) => sum + t.capacity, 0);

console.log(naive.toFixed(2), weighted.toFixed(2)); // "91.33" "75.70"

PDP:s fullständiga sammanställning har fyra steg. Anläggningar räknas upp till en komponent inom en stad, viktade efter vad var och en levererar: gallon för tankar, pumpgropsvolym för pumpstationer, löpfot för diken och avloppsledningar. Komponenter räknas upp till staden med vikter som PMU fastställer och som måste summera till 100, och städer till programmet efter godkänd kostnad. Positionerna beräknas vid förfrågan och lagras inte, så att dashboarden, PDF:en och dataflödet aldrig visar olika siffror.

Ytterligare en regel gör nytta: ett auktoriserat golv. När en högre tjänsteman har verifierat en position kan ingen senare inlämning rapportera under den, och bara sekreteraren eller en systemadministratör kan ändra den, med ändringen loggad. En verklig rättelse kräver nu en underskrift. Den friktionen hör hemma där.

Om en leverantör inte kan visa formeln bakom den stora procentsiffran är den stora procentsiffran bara dekoration.

4. S-kurva för projektuppföljning: planerat mot utfall

En S-kurva visar ackumulerad progress över tid: en långsam start, en brant mitt, ett avtagande slut. Lägg den planerade kurvan och utfallskurvan på samma axlar så är det lodräta avståndet din tidsplaneavvikelse, synlig månader innan ett slutdatum glider.

Utfallslinjen kräver registrerad historik. PDP tar en ögonblicksbild av varje position varje natt, och S-kurvan och alla "den här veckan"-siffror läser från de ögonblicksbilderna.

Den planerade linjen är den svårare halvan. Ett program med hundratals entreprenader har sällan en resursbelastad tidsplan för var och en, så PDP:s planerade baslinje är en modellerad kurva fram till måldatumet. Det är legitimt så länge diagrammet säger det. En planerad linje som ritas om varje kvartal för att hamna strax ovanför utfallet är sämre än ingen S-kurva alls.

5. En GIS-karta organiserad som förvaltningen

Tjänstemän tänker i administrativa enheter. PDP:s karta filtrerar från division till distrikt till tehsil till kommunkommitté och markerar varje tank, dike och pumpstation med sin aktuella position.

Kartor blir snabbt tunga. Ett av de första jobben på PDP:s dashboard minskade kartans data vid första inläsningen från 37 MB till 9 MB, vilket på 4G avgör om en tjänsteman över huvud taget öppnar den. Fråga leverantörer hur mycket deras karta väger.

6. En liveyta för PMU-kontoret

PDP Live är en storskärmstavla som visar fältrapporter när de kommer in, så att en stad som inte har rapporterat på förmiddagen syns på väggen och inte först på månadsgenomgången.

Den frågar servern ungefär var tionde sekund i stället för att hålla en push-anslutning öppen. Push är värd sin komplexitet på en flottkarta som matas med en jämn ström av fordonspositioner, som våra anteckningar om arkitektur för realtids-GPS-spårning förklarar. För rapporter som kommer några i taget är polling enklare och ingen som tittar märker skillnaden.

7. Rapporter med ett klick i det format tjänstemännen redan använder

Morgondragningen har redan en form och en sidordning. Ett system som ignorerar den får sina siffror inskrivna för hand i den gamla mallen. PDP tar fram sin dagliga lägesrapport från fältet som en PDF med ett klick, upplagd som tjänstemännens egna bilder, tillsammans med rapporter i PDF och Excel per stad, anläggningstyp och efterlevnad av säkerhetskrav.

8. Rollbaserad åtkomst som avgränsar data, inte menyer

PDP har sex roller, från fälthandläggare som bara ser sina tilldelade städer till chefer som ser hela programmet. Servern filtrerar data. Att dölja ett menyval är inte åtkomstkontroll.

9. Ett revisionsspår du kan lämna till en revisor

I dashboarden kan framstegsposter bara läggas till, och ett konto med historik inaktiveras, raderas aldrig. PMIS, avtals- och betalningssystemet för samma program, har ett revisionsspår i fyra lager: beslut, varje förfrågan, före- och efterläget för varje radändring och en nattlig SHA-256-hashkedja som förseglar loggarna så att en senare ändring bryter kedjan.

10. Integration med avtal och betalningar

Uppföljning frågar hur mycket som är byggt. Avtals- och betalningshantering frågar hur mycket som ska betalas, efter vilka avdrag och godkänt av vem. I PDP är det separata system. PMIS bär varje avtals mängdförteckning (BOQ) fyra nivåer djupt, beräknar nio typer av avdrag på servern och skickar varje delbetalningsintyg (IPC, a-contofaktura) genom en godkännandekedja med elva steg plus ett steg efter godkännandet. Sedan den 13 oktober 2026 har systemet en direkt koppling till provinsens Financial Management System och skickar godkända fakturor automatiskt sedan den 21 oktober. Dra den gränsen i uppdragsbeskrivningen från första dagen.

Arkitektur och datamodell: det väsentliga

Dashboards är den synliga delen. Datamodellen under avgör om någon ska tro på dem. Det här är posterna vi skulle förvänta oss, och regeln som gör var och en trovärdig:

Håll tekniken medvetet tråkig. PDP:s dashboard körs på Node.js 20, Express och MySQL 8.0: cirka 128 000 rader kod, ungefär 210 API-slutpunkter och runt 52 tabeller. Någon kommer att underhålla den i flera år efter att det ursprungliga teamet gått vidare, och vanlig teknik gör den kretsen större. MySQL klarar sig bra i den här storleken om indexeringen är genomtänkt, vilket vi beskriver i lärdomar från optimeringen av en MySQL-produktionsdatabas med 287 tabeller. Och om fältappen distribueras utanför en appbutik, lägg en kontroll av lägsta version på servern.

Att ta över ett myndighetssystem i drift utan att stoppa rapporteringen

De flesta myndigheters uppföljningssystem ärvs, de byggs inte från grunden. Så var det för PDP i juli 2026. Den ursprungliga plattformen kom från Technology Hive; NexGenix tog över den, flyttade den till Punjabs regerings egen server och har byggt om och drivit den sedan dess. Övergången den 24 juli 2026 kostade en dags minskad rapportering. Det här är ordningen vi skulle följa igen:

1. Granska innan du rör något. Läs koden, schemat och vad som faktiskt är i drift, och skriv ner det.
2. Flytta en fullständig kopia. Applikationen, databasdumpen och varje fältfoto, som oftast är den största mängden: 13 595 filer vid överlämningen i PDP:s fall.
3. Tillåt en skribent i taget. Bestäm exakt när den gamla servern slutar ta emot fältdata och den nya börjar.
4. Håll fältappen igång. Skicka ut en uppdatering som känner till den nya adressen före övergången, och tvinga sedan gamla versioner att uppdatera.
5. Verifiera genom att räkna. Poster, foton och totaler per stad, före och efter.
6. Förbättra sedan i små leveranser, var och en med en säkerhetskopia först och en väg tillbaka, den disciplin som ligger bakom vår utvecklingsprocess för anpassad mjukvara i fyra faser.

Checklista för upphandling: vad du ska fråga en leverantör av uppföljningssystem

Gör de här testerna i demon, på dina egna data, med de verkliga användarna i rummet.

1. "Visa formeln bakom den stora procentsiffran." Förvänta dig vikter, enheter och ett genomräknat exempel på en av dina städer.
2. "Slå på flygplansläge, rapportera framsteg och anslut igen." Det ska köas, synkas en gång och komma fram stämplat av servern.
3. "Vad hindrar någon från att lämna förra månadens foto som dagens?" En stämpel på serversidan, inte telefonens metadata.
4. "Logga in som fälthandläggare." Bara tilldelade platser, styrt av servern.
5. "Sänk en anläggnings progress." Avvisas under den verifierade positionen, eller loggas med vem och varför.
6. "Var kommer S-kurvans planerade linje ifrån?" En godkänd tidsplan, eller en tydligt märkt modell.
7. "Ta fram förra veckans dragning i vårt format." Kräver det en utvecklare blir det inte av en måndag.
8. "Kan systemet köras på vår egen server?" Fråga vad det kräver av nätverket.
9. "Vad får vi vid överlämningen?" Källkod, schemadokumentation, en användarmanual, driftsättningssteg och utbildning, inskrivet i avtalet.
10. "Hur levererar ni ändringar till ett system i drift?" Säkerhetskopior, en väg tillbaka och en ändringslogg.

Varningssignaler i ett system för projektuppföljning

• Framsteg som anges som en inskriven procentsats utan någon mängd bakom.
• Foton som accepteras från telefonens galleri utan någon stämpel från servern.
• En stor siffra som ingen hos leverantören kan räkna fram för hand.
• En raderingsknapp på inlämnade framsteg.
• En demo som bara fungerar med exempeldata.
• Inget tydligt svar på vem som äger källkoden och data.

Den vi skulle gå därifrån för är raderingsknappen. När historiken kan skrivas över blir varje siffra i systemet förhandlingsbar.

PDP Punjab: uppföljning av 52 städer

Punjab Development Program (PDP) bygger infrastruktur för avlopp, dagvatten och pumpstationer i 52 städer i 25 distrikt i Punjab, med omkring 7 miljoner invånare. I november 2026 omfattar programmet 394 entreprenader med en godkänd programkostnad på cirka 308 miljarder PKR. Dess Program Management Unit (PMU), som inrättats av Local Government & Community Development (LG&CD) Department vid Punjabs regering, arbetar med två system:

• PDP Executive Monitoring Dashboard (webb plus en Android-app för fältet) hanterar fysisk framdrift, bevis, kartor och rapporter. I november 2026 innehåller den cirka 33 000 fältfoton (de flesta geotaggade) och har sex roller och elva moduler på 27 webbsidor; fältappen har version 2.9.0.
• PMIS, Project/Contract & Payment Management System, hanterar mängdförteckningar, delbetalningsintyg, avdrag och kopplingen till Financial Management System. Det har 70+ tabeller och 45+ leveranser i drift, och godkännandekedjorna har kunnat ändras på skärmen sedan den 24 oktober 2026.

Den ursprungliga plattformen för båda kom från Technology Hive. Båda har flyttats till Punjabs regerings egen server och har byggts om och drivits av NexGenix sedan juli 2026.

Lärdomen vi vill föra vidare handlar om införande. Ett system som tar fram de dokument tjänstemännen redan använder, som morgondragningen i deras egen bildlayout, kräver lite utbildning för att börja användas. Bygg dem tidigt. Dashboards kan komma sedan.

Fallstudien om PDP Executive Monitoring Dashboard visar skärmarna och tidslinjen. Den kompletterande fallstudien om PMIS, systemet för avtal och a-contofakturering, beskriver godkännandekedjan och kopplingen till ekonomisystemet. Planerar du något liknande? Vår sida om mjukvaruutveckling för offentlig sektor förklarar hur vi arbetar med PMU:er.

Vanliga frågor

Vad är ett system för projektuppföljning?

Programvara som registrerar den fysiska framdriften i utvecklingsarbeten från fältet, med fotobevis, och räknar samman den till dashboards, kartor och rapporter. Ett bra system viktar progress efter vad varje anläggning levererar och sparar historiken bakom varje siffra.

Vad är skillnaden mellan uppföljning och utvärdering i ett M&E-system?

Uppföljning mäter framsteg löpande medan arbetet pågår: byggda mängder, använda pengar, tidsplaneavvikelse. Utvärdering blickar tillbaka vid bestämda tidpunkter för att bedöma om programmet nådde sina avsedda resultat, med hjälp av de data uppföljningen samlat in.

Hur verifierar geotaggade foton framsteg i offentliga projekt?

Varje foto från fältappen kopplas till en anläggning och en framstegspost, och servern stämplar det med handläggare, koordinater och tid, så att granskare kan bekräfta att det kom från rätt plats rätt dag.

Vad är en S-kurva i projektuppföljning?

Ett diagram över ackumulerad progress över tid för den planerade baslinjen och det faktiska arbetet. Avståndet mellan de två linjerna visar hur långt före eller efter tidsplanen projektet ligger.

Kan ett system för projektuppföljning köras på en myndighets egen server?

Ja, och för de flesta offentliga organisationer bör det göra det. PDP:s system körs på Punjabs regerings egen server. Planera för begränsad internetåtkomst och säkerhetskopior som förvaltningen själv kontrollerar.

Hur skiljer sig ett uppföljningssystem från ett system för avtal och betalningar?

Ett uppföljningssystem mäter hur mycket som är byggt. Ett system för avtals- och betalningshantering, ofta kallat PMIS, hanterar mängdförteckningen, delbetalningsintyg, avdrag och godkännanden innan pengar flyttas. Stora program behöver båda.

Börja med bevisen, inte med dashboarden

Varje system för projektuppföljning bedöms till slut efter en enda fråga: när en tjänsteman citerar en siffra på ett möte, kan någon bevisa den? Specificera beviskedjan, viktningsmetoden och revisionsspåret först. Diagrammen är den enkla delen.

---

Granskad av NexGenix ingenjörsteam. Läs våra redaktionella riktlinjer för att lära dig hur vi verifierar källor, redovisar AI-assistans och korrigerar fel.