Vi tenderar att behandla ny teknik som den heliga gralen, en ljusljus och svaret på allt som är långsamt, ineffektivt och gammalt. Och det kan vara - om det implementeras med en lastbilsplanering och framsyn.
Men vi vet alla hur det går.
Under mina år i regeringen, där det ibland kändes som att vi spelade ett spel med teknisk infångning som omöjligt var att vinna, lärde jag mig vad som kan hända när denna framsyn är för givet. Det ser lite mindre ut som den heliga gral och mycket mer som kostnadsöverskridanden, förseningar och sammanlänkade lösningar på annars enkla problem.
Som jag fick veta är en av de viktigaste nycklarna till ett framgångsrikt teknikprojekt det harmoniska förhållandet mellan företagsteamet och teknikgruppen. Enligt min erfarenhet drev företagsteamet ofta förändringen (vi behöver till exempel ett mer komplext system för att spåra federala bidragsutgifter), men vi kunde inte uppnå en framgång utan att utvecklarna och IT-projektledarna kan göra det hända. Projekt hamnade ofta långt ifrån harmoniskt, ett resultat av att man i princip talade olika språk och upprätthöll mycket olika förväntningar (en förändring som tycktes mindre för mig, till exempel visade sig ofta vara viktig för utvecklarna).
Men företag och teknik kan - och måste - vara vänner. De goda nyheterna? Att uppnå harmoni är verkligen inte så komplicerat. Liksom alla samarbeten har det att göra med frekvensen och kvaliteten på kommunikationen, en ömsesidigt överenskomna uppsättning mål och en plan för att hantera den nästan oundvikliga förändringen av dessa mål. Här är några grundläggande riktlinjer för att hantera klyftan mellan företag och teknik.
1. Målet är att spika kraven första gången
Tänk på företagens krav som en plan. Du skulle inte rita en skissig uppsättning ritningar för ett hus, leverera dem till entreprenören och önska honom lycka till. Du skulle inte komma tillbaka tre veckor i byggandet och be honom lägga till en tredje våning och ett fjärde badrum, och kanske ett fönster i vardagsrummet. Och du skulle verkligen inte rita dina ritningar utan input från en arkitekt och en ingenjör.
Ett teknikprojekt är inte så annorlunda. Det måste utformas med precision, och när utvecklingen börjar är det inte alltid lätt att rymma förändringar utan att påverka hela grunden. Det är därför det är viktigt att vara så omfattande som möjligt från början och få de insatser och expertis du behöver när du tänker igenom vad lösningen kommer att kräva. Intervju slutanvändare för att förstå utmaningarna de står inför och exakt hur de kommer att behöva använda den nya tekniken. Gör inte antaganden och lämna inte några delar av planeringen för senare.
2. Men erkänn att du kommer att sakna några
Som sagt, jag tyckte att det var nästan omöjligt att föreställa mig alla funktioner som vi behövde under de abstrakta planeringsstadierna. När systemet hade utvecklats skulle vi helt klart inse att vi glömde att be om en avancerad sökfunktion eller en "spara och fortsätt" -knapp. När vi kontaktade utvecklarna för att vänligen be dem att tillgodose dessa nya förfrågningar möttes vi ofta med frustration. Kanske skulle den nya förändringen kräva att de ångrar det arbete som de redan gjort och arkiverar delar av lösningen. Kanske vi föreställde oss att det skulle ta två timmar när det faktiskt skulle ta en dag.
Du kanske inte kan förhindra dessa avslöjanden senare i spelet, så det bästa du kan göra är att bygga in en buffert för att rymma dem. Lägg till en extra vecka till din ursprungliga tidslinje och ytterligare 5-10% till din budget. Många organisationer, som inser hur ofta förväntningarna förändras, har använt en smidig strategi för utveckling och rullat ut teknik i faser för att möjliggöra periodisk omvärdering. Oavsett din metod, gör inte misstaget att tro att du har tänkt på allt från start. Det händer nästan aldrig.
3. Know Scope Creep när du ser det
När projektet går framåt och nya behov kommer fram är det viktigt att skilja mellan de du verkligen behöver och de du bara vill ha. Att be dina utvecklare rymma varje klocka och visselpipa som sinnet kan drömma upp leder vanligtvis till oändliga projekt och alltför komplicerade slutresultat. Varje ny begäran, innan den görs, bör prioriteras.
När du funderar på en funktion, ställa dig själv några grundläggande frågor: Fungerar systemet utan det? Hur mycket tid kommer det att ta att genomföra, och hur mycket fördel kommer slutligen att levereras till slutanvändaren? Om vi väntar tills en framtida utgåva för att ta itu med det, kommer något att gå förlorat? Det är en övning av prioritering, och allt kan tilldelas en status som hög, medel eller låg. Om det är lågt lägger du det på en figurativ parkeringsplats - jag har hört talas om företag som har "drömutvecklingsbegäran" -dokument som vem som helst kan lägga till idéer till och ingenjörerna kan bläddra i deras fritid. Det kan alltid ses igen som en del av ett antal förbättringar som ska göras när projektet är ute och körs framgångsrikt.
4. Utveckla ett gemensamt språk
Alla nya system har en uppsättning affärsmål i dess kärna. Det låter dig fånga mer data, effektivisera en befintlig process eller erbjuda nya tjänster till dina kunder. Det är kritiskt att affärsteamet och teknikgruppen sätter sig ner innan något arbete har börjat och kommunicerar dessa mål. Verksamhetsmålen får inte gå vilse i ett hav av teknisk prat, och de måste vara fast i åtanke under varje fas av arbetet.
Att utveckla ett gemensamt språk betyder inte bara kollektiv målsättning, utan spåra framsteg på ett sätt som fungerar för alla. Företag och teknik kan använda olika verktyg för att mäta sitt arbete, men det måste finnas åtminstone en syn på framsteg som delas. Detta kan vara så enkelt som en projektplan eller ett kalkylblad med överenskomna fält, som datum och mål och procent slutförda, så att alla har tillgång till statusen för varje uppgift som ska slutföras. Målet är att undvika en situation där företagsteamet tror att de är halvvägs där och teknikgruppen säger att de bara är en fjärdedel - alla borde ha samma förståelse för vad som har gjorts och vad som återstår att göra.
Du kan tala i affärsplaner och PowerPoints, och de kan tala i kod, men om du inte kommunicerar tydligt från start kommer du aldrig att göra det ur Babel. Ett framgångsrikt teknikprojekt handlar om ett möte i sinnena - inte bara i början, utan vid varje steg på vägen. Erkänn dina antaganden och försök att inte göra för många. Ju mindre skillnaden mellan företag och teknik, desto lättare blir det att korsa dina broar.
