Teamet för totalentreprenad på South Carolina DOT blomstrar tack vare Bluebeam

2014 upprättade South Carolina Department of Transportation (SCDOT) ett nytt team som helt skulle fokusera på en snabbare metod för att leverera byggprojekt som kallas Design-Build, eller totalentreprenad. Teamet skulle ansvara för ungefär fem stora projekt per år, liksom tre projektpaket med flera broar samt eventuella akutprojekt.

I ett traditionellt byggprojekt lägger en entreprenör ett anbud på projektet först efter att en förutbestämd arkitekt eller designer är färdig med sina ritningar. När projektet har tilldelats efter anbudsprocessen börjar man bygga. Den här leveransmetoden, som kallas Design-Bid-Build eller utförandeentreprenad, fungerar visserligen, men är inte så effektiv som den skulle kunna vara.

”Det fungerar som ett stafettlopp, där stafettpinnen lämnas över från designern till entreprenören”, förklarar Brooks Bickley, Assistant Program Manager på SCDOT. Brooks ansvarade för entreprenadteamets arbetsflöde och kommande omvandling.

Nu valde man istället att använda Design-Build, eller totalentreprenad, som innebär att en arkitekt och en entreprenör tillsammans lägger ett anbud på ett projekt. Sedan sköter de projektets arkitektritningar och själva byggandet mer eller mindre samtidigt. Den här metoden leder till att tiden för att leverera ett byggprojekt minskar, vilket i sin tur ger lägre kostnader och maximal lönsamhet.

”Man kan se totalentreprenaden som ett trebent lopp”, säger Brooks Bickley, ”där designern och entreprenören inte kan ta sig fram till mållinjen ensamma – de måste samarbeta redan från start.”

För att uppnå de effektivitetsvinster som totalentreprenaden medför måste dock alla team använda sig av arbetsflöden som är så effektiva som möjligt. Men 2014 hade det nyskapade teamet för totalentreprenad på SCDOT, som bestod av 12 personer, ett arbetsflöde för att granska och revidera projektdokument innan de skickades ut till byggarbetsplatsen som var allt annat än effektivt.

Vid den tidpunkten hade man inget specifikt programvaruverktyg för att samordna samgranskningsprocessen, utan teamet kämpade med ett klumpigt, manuellt arbetsflöde som man skämtsamt kallade för ”stentavlemetoden” – en hänvisning till den primitiva metoden att hugga in ord i stentavlor. Med den här processen skickade en granskningssamordnare ut olika kommentarformulär till granskarna per e-post, varefter intressenterna utförde sina granskningar individuellt innan de skickades tillbaka till samordnaren, som nu ansvarade för att manuellt sammanställa alla kommentarer, ta bort eventuella dubbletter och lösa konflikter.

Det här var en tidskrävande och omständlig metod som ledde till ett ineffektivt tidsschema. ”Det var en smärtsam process”, säger Brooks Bickley. Ett annat problem med den här metoden var att varje kommentar måste visa var på sidan det som kommentaren handlade om fanns, vilket ledde till felkommunikation och risk för misstag.

Om en granskare inte svarade eller höll koll på en viss granskning var samordnaren dessutom tvungen att kontakta parterna separat för att få deras feedback.

Hittade Bluebeam

Brooks Bickley och en kollega fick i uppgift att hitta en ny lösning på teamets smärtsamma samgranskningsprocess. Under de närmaste månaderna experimenterade teamet med olika förslag, bland annat ett där man skulle använda ungefär tolv olika kalkylblad med sju olika flikar i varje. ”Det lät som en bra idé just då”, säger Brooks, ”men det var verkligen överkomplicerat.”

Sedan stötte teamet på Bluebeam. Men eftersom teamet var en del av en myndighet var Brooks inte säker på att det skulle gå att införa ett nytt programvaruverktyg för att lösa problemet med samgranskningarna. ”Alla som har försökt att få något gjort på en myndighet vet att det inte direkt går snabbt”, säger han om möjligheten att få Bluebeam inköpt, testat och infört.

Något överraskande behövde Brooks Bickley och hans team inte argumentera för Bluebeam. En medarbetare på myndighetens IT-avdelning skickade efter att själv ha upptäckt Bluebeam ett e-postmeddelande till Brooks och frågade om hans team skulle vilja prova det. ”Efter idén med de tolv kalkylbladen var vi redo att prova vad som helst”, säger han. ”Vi hade tittat på så många alternativ, och Bluebeam stod högst på listan. Vi insåg omedelbart att det skulle kunna få en enorm betydelse.”

Brooks Bickley och hans team blev direkt imponerade av Bluebeam Revu, den skrivbordslösning för PDF-markering och -kommentarer som ingick i programvaran. Men det var inte förrän de upptäckte Studio-sessioner i Revu, där flera användare kan samarbeta i realtid om en dokumentuppsättning, som teamet började förstå att verktyget skulle kunna bli revolutionerande.

”Alla våra granskare kunde delta i en granskningssession samtidigt”, säger Brooks. ”Då vet man att alla tittar på samma uppsättning dokument, och kan kommentera i dokumenten – inte på ett separat formulär – så att kommentarerna även blir synliga för övriga granskare.”

”Det gav dem möjlighet att samarbeta direkt i början av granskningsprocessen”, fortsätter han, ”vilket helt eliminerade de många och motstridiga kommentarer som vi hade haft tidigare.”

Något som verkligen sålde in Studio-sessionerna hos teamet var att man genom anpassade statusar automatiskt kunde återskapa ett kommentarsformulär som liknade de gamla ”stentavlorna” som teamet var vana vid att skapa med det gamla arbetsflödet. ”Det här [att se alternativet för anpassad status] var revolutionerande”, säger Brooks. ”Det hade vi inte sett i något annat onlineformat, och då hade vi ändå provat många olika saker.”

Bra argument

Även om det mer eller mindre omedelbart stod klart att Studio-sessionerna helt skulle komma att revolutionera teamets samgranskningsprocess, var det just då inte lika uppenbart hur man skulle bära sig åt för att överföra den gamla, ineffektiva processen till den nya Bluebeam-miljön. Förutom att överföra sin etablerade granskningsdokumentation till Bluebeam skulle entreprenadteamet också behöva utbilda alla i att använda ett nytt verktyg och arbetsflöde, och fundera ut hur man kunde hantera ett flertal granskningar i Studio-sessioner för olika projekt.

Redan innan de införde Bluebeam använde gruppen för totalentreprenad på SCDOT Microsoft OneNote som central lagringsplats för all projektinformation. Precis som Studio-sessioner var OneNote ett verktyg som alla hade tillgång till och där man också kunde samarbeta i realtid. Teamet kunde även skapa projektspecifika sidor där man så småningom kunde inkludera hyperlänkar till motsvarande projektgranskningar i Studio-sessioner.

OneNote var särskilt användbart när teamet skulle skapa e-postmeddelanden för Bluebeam-aviseringar. ”Den stora fördelen är att flera personer kan ha filen öppen samtidigt”, säger Brooks Bickley, ”och göra faktiska ändringar i realtid.”

Efter att ha lagt ner mycket arbete på att skapa och hantera det nya granskningssystemet med Studio-sessioner, var Brooks och hans team nu tvungna att presentera ett pilotprojekt för myndighetens ledning. För att förbereda sig genomförde teamet ett omfattande internt betatest av det nya arbetsflödet, med målet att försöka hitta svaga länkar att korrigera och revidera innan pilotprojektet startade.

”Vi försökte få det att gå sönder”, säger Brooks om det nya arbetsflödet med Bluebeam. ”Vi skapade några låtsasanvändare och testade det själva, och sedan anlitade vi några betatestare från kontoret. Om det fanns några svaga länkar i systemet ville vi hitta dem nu, för om vi inte gjorde det skulle det bli katastrof senare.”

Teamet insåg till exempel i sin första betatestsession att de anpassade statusarna inte fungerade som de skulle – för att lösa det behövde man införa ytterligare ett steg. ”För de anpassade statusarna måste vi i varje dokument öppna en kommentar, skriva den, ge den en status och spara den”, säger Brooks. ”Det var något som vi redan brukade göra, men vi insåg inte att det var något som måste hända i en ny session med hundratals dokument.”

När betatestet var klart skrev teamet ner sitt slutliga ”recept”, som är Brooks Bickleys benämning på den officiella dokumentationen av arbetsflödet. Teamet använde sedan processdokumentationen för att argumentera för sin sak, och senare som stöd för utbildningen när det var dags för den större Bluebeam-implementeringen.

”Det gick verkligen smidigt”, säger Brooks om att få samgranskningsprocessen godkänd och införd i pilotprojekten, ”eftersom processen sålde in sig själv”.

Det första officiella pilotprojektet var en breddning av motorvägen I-77 i South Carolina, som SCDOT tilldelades i december 2015. ”Efter flera månaders planering och arbete kunde vi äntligen se om det här planet skulle lyfta”, säger Brooks Bickley.

Underlättar utbildningen

En stor del av att komma igång med pilotprojektet handlade om att utbilda projektintressenterna i att använda den nya programvaran och arbetsflödet. ”Introduktionen skulle bli en överväldigande uppgift”, säger Brooks, ”så vi erbjöd oss att sköta den för såväl vår interna SCDOT-personal som den personal i entreprenadteamet som arbetade med det här projektet.”

För att effektivisera och underlätta utbildningen använde sig Brooks och teamet av ett särskilt verktyg: YouTube.

”Vi hade underskattat hur många personer vi egentligen behövde utbilda”, säger han. ”Vi insåg snabbt att vi behövde ett mer effektivt sätt att utbilda dem, så vi började med att skapa några YouTube-videor om Bluebeam Studio.”

Teamet skapade från början två videor: en om hur man skapar ett Bluebeam-konto, och en som gav en översikt över den nya granskningsprocessen. Brooks berättar att distributionen av videorna snabbt blev det bästa sättet att få ut information i stor skala. ”Vi skickade bara ut videorna till de nya användarna, vilket gjorde att vi blev ansvariga för felsökningen istället för den individuella utbildningen”, säger han.

Tack vare att teamet använde videorna för att utbilda proaktivt medan de själva skötte felsökningen kunde de producera ännu mer utbildningsinnehåll. De tog till exempel de vanligaste frågorna och skapade en uppsättning affärsregler som framtida användare kunde referera till. Och medan I-77-projektet gick framåt ordnade teamet en blandning av personliga möten och onlinemöten med projektintressenterna för att samla in feedback och identifiera ny bästa praxis.

”Att få alla utbildade och bekväma tog mycket tid”, säger Brooks. ”Så småningom hade vi nått en punkt då tillräckligt många inom myndigheten och hos omgivande entreprenörer och konsulter hade kommit i kontakt med många av samgranskningarna för att en stor del av utbildningen skulle kunna ske internt på företagen.”

”Innan vi visste ordet av rullade det på av sig självt”, tillägger Brooks.

Realiserade resultat

Under de åtta år som har gått sedan teamet för totalentreprenad på SCDOT införde Bluebeam Studio-sessioner för sin samgranskningsprocess har det gått väldigt bra för dem. Även om man inte helt har lyckats fastställa kvantitativa mått på framgångarna ”är de uppenbara för alla”, säger Brooks Bickley.

Han känner sig säker på att den nya samgranskningsprocessen med Bluebeam har ”sparat SCDOT miljontals dollar”. ”Vårt I-77-projekt hade ursprungligen en budget på omkring 100 miljoner dollar (1,1 miljard kronor), och med den gamla ”stentavlemetoden” skulle det ha krävts en heltidspersonal för att sammanställa alla kommentarer och organisera samgranskningarna”, säger Brooks.

Under sitt första kalenderår med det nya systemet kunde gruppen för totalentreprenad tilldela projekt för 1,2 miljarder dollar (13 miljarder kronor), och en enda person klarade ensam att samordna granskningarna för alla dess projekt. Totalt har Bluebeam enligt Brooks Bickley gjort teamet tolv gånger mer produktivt.

”Samgranskningarna [för I-77-projektet] kunde i vissa fall ha tagit mer än 30 dagar”, säger han. ”Avtalet tillät granskningar på 15 dagar och inga tidsfrister missades, så det här resulterade i en genomsnittlig minskning av granskningstiden med 25 % jämfört med ’stentavlan’.”Gruppen för totalentreprenad lyckades så bra med att införa Bluebeam att programvaran nu används i hela SCDOT.