Programvara för projektbemanning: vad du ska leta efter när kalkylarket inte räcker

De flesta resursplanerare känner igen situationen. En anbudsförfrågan kommer in. Ett nytt projekt ska bemannas. Du öppnar kalkylarket, SharePoint-mappen eller fliken i HR-systemet och börjar gå igenom vad du har. En timme senare har du en lista med namn som är ungefär tillgängliga. Om någon av dem verkligen passar för uppdraget är en helt annan fråga, och den var verktyget du använder aldrig riktigt byggt för att besvara.

Det finns gott om programvara för projektbemanning. Problemet är att en stor del av den löser den enkla versionen av bemanningsproblemet, alltså att hålla koll på vem som är bokad och vem som inte är det, utan att ta sig an den svårare: om de personer du har faktiskt kan utföra det arbete projektet kräver. Om du utvärderar verktyg är det den skillnaden du ska börja med.

Bemanningsverktyget du tittar på kanske inte är ett bemanningsverktyg

Marknaden för programvara för projektbemanning består av tre typer av produkter, och de är inte lika användbara.

Den första typen är PSA-verktyg, plattformar för projekt- och resursplanering som Kantata eller Kimble. De är starka på tidrapportering, projektekonomi och allokering. Men de är inga kompetensverktyg. De visar vem som är bokad och när, men innehåller lite eller ingen data om vad personerna faktiskt kan. En sökning på ”tillgänglig konsult med GCP-certifiering och fem års erfarenhet av företagsarkitektur” är inget de är byggda för att besvara.

Den andra typen är rekryteringssystem eller HR-plattformar som har fått en bemanningsmodul. Verktygen byggdes för att hantera kandidater och medarbetare, inte för att stödja operativa bemanningsbeslut. Kompetensdatan i dem, i den mån den alls finns, är oftast strukturerad för befattningsarkitektur och rapportering snarare än för den sortens snabba, kriteriebaserade sökning som en resursplanerare gör en måndagsmorgon.

Den tredje typen är plattformar byggda kring kompetens från grunden, där datamodellen utgår från förmåga och inte från antal anställda. Kompetenser, certifieringar, kunskapsnivåer och tillgänglighet är centrala objekt i systemet. Bemanningsfrågan (”vem passar för det här projektet?”) är precis vad systemet byggdes för att besvara, inte något som lagts till i efterhand ovanpå ett helt annat grundsyfte.

Den skillnaden betyder mer än man kan tro. När ett företag utvärderar programvara för projektbemanning är det lätt att jämföra funktioner rakt av. Men ett verktyg som följer tillgänglighet utan att följa förmåga löser ett annat och mycket enklare problem än det de flesta företag faktiskt har. Att veta att sex konsulter står utan uppdrag är användbart. Att veta vilka av de sex som har de kompetenser nästa projekt kräver, på vilken nivå och med vilka giltiga certifieringar, är det som gör informationen till ett bemanningsbeslut.

Fyra förmågor som verkligen spelar roll

Om du utvärderar programvara för projektbemanning är det de här fyra förmågorna som skiljer verktyg byggda för det verkliga problemet från verktyg byggda för en enklare version av det.

1. Kompetenssökning som körs över hela organisationen samtidigt. Det praktiska testet: skriv in en kombination av kompetenser, till exempel ”Azure-certifierad, seniornivå, inte allokerad efter månadsskiftet”, och få ett pålitligt svar på några sekunder. Inte en lista med personer att ringa runt till. En sökning som körs över varenda konsultprofil i systemet och returnerar de bästa matchningarna rangordnade efter hur väl de passar. Det är det som skiljer en kompetensplattform från en databas. En databas lagrar information. En plattform gör den sökbar på det sätt en resursplanerare faktiskt behöver.

I MuchSkills kallas det här AI Super Search. Det moment i demon som de flesta resursplanerare reagerar på är när de skriver in en specifik kombination av kompetens och certifiering och ser matchande, lediga konsulter dyka upp på tio sekunder. Det spelar också roll hur sökningen tolkar det du skriver. Ett vanligt databasfilter tar allt bokstavligt: söker du på ”JavaScript” missar du konsulten vars profil anger ”React” och ”Node” men inte uttryckligen JavaScript. En sökning som bygger på skills intelligence förstår hur termerna hänger ihop och ger träffar utifrån det. 

En resursplanerare på ett AWS Premier-konsultbolag med omkring 400 konsulter beskrev hur det ser ut när den förmågan saknas: en kund vill ha ett digitalt team med erfarenhet av React, Node och Lambda, affärsutvecklaren säger ”jag återkommer”, och sedan går det dagar innan något svar kommer. Det är inte ett processproblem. Det är ett dataproblem.

Kompetenssökning ger dig rätt kandidater. Men att du hittar någon betyder inte att personen är behörig.

2. Certifikat och behörigheter med koll på utgångsdatum. Certifieringar är allt oftare en förutsättning, inte bara en merit. AWS Premier, Azure Expert, Atlassian Gold: i partnerprogram som dessa är statusen kopplad till ett visst antal certifierade konsulter. Ett företag som inte vet hur det ligger till med sina certifieringar kan gå miste om anbud det hade vunnit, eller upptäcka mitt i arbetet med ett anbud att AWS-certifieringen man tänkt ta med gick ut för sex veckor sedan.

Användbar hantering av personalens certifikat för projektbemanning innebär tre saker: att veta vilka certifieringar varje konsult har, att veta när de går ut och att kunna lyfta fram den informationen direkt i en bemanningssökning i stället för i en separat efterlevnadsrapport. Certifikat och behörigheter som ligger i ett annat system än bemanningsdatan skapar samma problem som den skulle lösa: du får reda på att certifieringen har gått ut först när anbudet redan är inskickat.

Certifikat och behörigheter visar vem som är behörig. Men en grupp behöriga individer blir inte automatiskt ett team.

3. En Team Builder, inte bara en kandidatlista. Att bemanna ett projekt är inte att välja ut en person. Det är att sätta ihop ett team där kompetensfördelningen matchar projektets krav, där ingen sitter med uppgifter hen saknar förutsättningar för och där teamets samlade kompetens täcker kundens behov. Ett verktyg som lyfter fram enskilda individer men inte hjälper dig att bedöma teamet som helhet lämnar den svåraste delen av beslutet åt magkänslan.

Team Builder i MuchSkills gör just det: när du har en uppsättning kandidater till ett projekt hjälper plattformen dig att bedöma kombinationen, alltså kompetenstäckning, tillgänglighet och riskflaggor, innan du bestämmer dig. Det är skillnaden mellan ett sökverktyg och ett bemanningsverktyg.

En Team Builder hjälper dig att bedöma kombinationen innan du bestämmer dig. Vad den inte kan säga är om personerna i kombinationen faktiskt vill göra jobbet.

4. Data om motivation tillsammans med kompetensdata. Den här är mindre självklar men värd att ta med. En konsult som har en kompetens vill inte nödvändigtvis använda den i nästa projekt. Att placera någon i ett uppdrag som ligger utanför det personen verkligen är intresserad av riskerar inte bara trivseln, det påverkar också leveranskvaliteten och på sikt viljan att stanna kvar. De företag som bemannar bra är de som följer inte bara förmåga utan också vilja.

MuchSkills fångar det här med Skill Will, ett lager som kompletterar den vanliga kunskapsskalan 1-9 och registrerar om konsulten vill använda kompetensen. Ingen annan plattform i kategorin följer upp motivationsdata. Det låter som en trevlig bonus, ända tills du har suttit i samtalet där en konsult placerats i ett sexmånadersprojekt med just det arbete som hen tre månader tidigare sagt till sin chef att hen var klar med.

Dataproblemet som ingen funktionslista löser

Varje utvärdering av programvara för projektbemanning landar till slut i samma fråga: hur bra är datan bakom? Ett verktyg med utmärkt sökfunktion och en Team Builder är bara så användbart som kompetensdatan det söker i är korrekt och aktuell.

De flesta företag som utvärderar programvara har egen erfarenhet av det här problemet. De byggde en kompetensmatris. De höll den uppdaterad det första kvartalet. Efter sex månader var en tredjedel av profilerna inaktuella. Efter tolv månader litade ingen på någonting i den. Konsultbolagens kyrkogård av misslyckade kompetensinventeringar är välfylld: SharePoint-sajter, Power BI-dashboards och egenbyggda verktyg som övergavs i samma stund som personen som byggde dem slutade.

Orsaken till att de misslyckas är nästan alltid densamma: plattformen var utformad för organisationens behov av kompetensdata, inte för konsultens behov av att synas med sina kompetenser. När det är en plikt att uppdatera profilen snarare än något som gynnar konsulten direkt blir det inte gjort regelbundet.

Och ojämn data är, när det gäller bemanning, värre än ingen data alls, eftersom den skapar en falsk trygghet. Du tror att du vet vad dina konsulter kan. Du söker. Du får ett resultat. Du bemannar projektet. Och felmatchningen visar sig först när arbetet redan är igång.

En kompetensplattform som konsulterna faktiskt använder är en där de tydligt kan se sina egna kompetenser, följa sin utveckling och har ett skäl att hålla informationen aktuell. MuchSkills använder social transparens, där profilerna är synliga för kollegor, vilket minskar överdrifter och ökar träffsäkerheten. Till det kommer en kunskapsskala som tar femton minuter att fylla i ärligt i stället för en timme att försöka manipulera. Resultatet är data som förblir aktuell eftersom de personer den beskriver har ett eget intresse av att den stämmer.

För en resursplanerare blir den praktiska slutsatsen följande: innan du utvärderar någon programvara för projektbemanning ska du inte fråga ”vad gör verktyget?” utan ”hur ser verktyget till att datan det söker i är värd att söka i?” Om svaret är ”vi påminner folk om att uppdatera sina profiler” kommer verktyget att misslyckas. Om svaret handlar om design för användning, synlighet bland kollegor och värde för medarbetarna har det en chans. Ett praktiskt sätt att testa detta: fråga varje leverantör hur hög den genomsnittliga andelen ifyllda profiler är hos befintliga kunder. En leverantör som inte kan svara på den frågan, eller undviker den, säger något viktigt. MuchSkills kunder når normalt 80-90 %. Den siffran finns för att plattformen är utformad för personen som fyller i profilen, inte bara för chefen som läser den.

Vad tidigare försök kan lära dig

De flesta företag som utvärderar programvara för projektbemanning gör det inte för första gången. De har provat något tidigare. Det misslyckades, räckte inte till eller lades i tysthet ner. Den historiken spelar roll.

Det vanligaste tidigare försöket är ett kalkylark eller ett delat dokument. Det fungerar för tio personer, blir tungt att underhålla vid hundra och går inte att använda vid tvåhundra. Näst vanligast är en modul i ett befintligt verktyg: en kompetensdel i HR-systemet eller ett kompetensramverk som skruvats på PSA-verktyget. De fallerar eftersom de aldrig var verktygets huvudsakliga användningsområde. Därför prioriteras de aldrig i utvecklingen, och medarbetarna lär sig snabbt att det de matar in där inte leder till något användbart.

Det tredje mönstret är den egenbyggda lösningen: en Power BI-dashboard, en SharePoint-sajt eller ett internt verktyg byggt av någon som sedan har slutat. Egenbyggda lösningar misslyckas av det skäl som en resursplanerare på ett AWS Premier-konsultbolag uttryckte rakt ut: ”i en konsultverksamhet är det i princip galet att vilja göra det, eftersom vi aldrig kommer att kunna underhålla det. Att få det i drift kommer aldrig att hända.”

Att förstå vad det förra försöket gick ut på, och exakt varför det misslyckades, är den tydligaste fingervisningen om vad nästa lösning måste göra annorlunda. Företag som föll på att ingen använde systemet behöver en plattform byggd för medarbetarna, inte bara för cheferna. Företag som föll på datakvaliteten behöver en plattform som ger incitament att hålla uppgifterna korrekta, inte bara ett formulär att fylla i. Företag som föll för att verktyget inte kopplade ihop kompetens med bemanningsbeslut behöver en plattform där båda delarna ingår i samma system.

Är du där nu, redo att se hur programvara för projektbemanning ser ut när den faktiskt är byggd för just det här problemet? Då går sidan om beläggning och resursplanering igenom vad MuchSkills erbjuder på området. Och vill du förstå själva bemanningsproblemet innan du utvärderar lösningar, förklarar inlägget om projektbemanning varför antal medarbetare och förmåga är två olika frågor.