Jag insåg nyligen att jag har lett produktutvecklingsprojekt i mer än ett kvartssekel nu, med en massa fler års erfarenhet av produktdesign utöver det.

Under den här tiden har jag samlat en lista med projektledningstips som verkar mer och mer giltiga för mig med tiden.

Min erfarenhet har mest fokuserat på att utveckla iterationer av prototyper av medicinsk utrustning och andra produkter. Tänk på detta sammanhang i följande förslag.

Ha så kul

Jag tror att ett projektteam är mest effektivt när de har roligt. För vissa kan detta låta oseriöst men underskatta inte hur produktivt ett team kan vara när de verkligen trivs med sitt arbete. De kommer att vara mer benägna att gel och mer benägna att leverera dessa riktigt bra idéer. När jag presenterar ett projekt för en ny gruppmedlem försöker jag väcka en gnista av intresse och nyfikenhet, bland alla andra vardagliga detaljer. Jag tror att teammedlemmar som tilldelas flera projekt tenderar att fokusera sin energi på de roliga. Jag har märkt – till exempel – att jag verkligen börjar få draghjälp i ett projekt när jag är upprörd över det. Jag antar att detta är sant för andra också!

Att vårda denna kultur i första hand, och sedan inte av misstag döda den, är ofta en utmaning.

Visualisera Klar

Jag upptäcker att jag hela tiden försöker ta reda på hur färdigt ser ut, både för att avgöra vad mitt team verkligen försöker åstadkomma och vad projektsponsorn verkligen behöver. Detta är ofta en iterativ process, först för att komma in i rätt bollplank och sedan för att förfina den.

Oavsett anledning bestäms vår budget vanligtvis innan vi har en mycket tydlig uppfattning om hur det ser ut. Det gör det ganska viktigt att finslipa och socialisera detaljerna snabbt för att säkerställa att vi alla arbetar effektivt i rätt riktning. Det här kan vara lite galet för människor som är nya i den här strategin, men på något sätt verkar det mestadels lösa sig.

En stor möjlighet till projektframgång är ofta tillgänglig genom sena ändringar i definitionen av gjort. Av den anledningen spekulerar jag alltid i nya definitioner, både med teamet och projektsponsorn. Det kan mycket väl finnas en stor vinst där någonstans som väntar på att bli upptäckt: avsluta snabbare, minska risken, nå budget, uppnå bättre prestanda.

Lita på ditt team

Jag misstänker att vi alla har arbetat med projekt där premiärministern pressas till val som gör lagets jobb riktigt utmanande. Det som vanligtvis händer under dessa omständigheter är att ett fåtal teammedlemmar kommer att uttrycka oro. Till en början är dessa farhågor magkänsla – svåra att belägga. När situationen blir tuffare blir hela laget desillusionerade och glädjen fördunstar.

Jag tror att det är premiärministerns uppgift att lyssna när teamet uttrycker oro och lägga märke till när deras optimism får ett slag. Även utan tillräckliga bevis måste premiärministern behandla det på allvar och trycka tillbaka för laget. Om teamet inte känner att premiärministern har ryggen, blir glädjen återigen lidande.

Piska inte ditt lag

Jag ser det här beteendet så ofta. Någon är sen med en uppgift och premiärministern ropar ut dem, vanligtvis i en lagsamling. Tyvärr har jag varit i båda ändarna av detta många gånger, och jag har lärt mig att det aldrig hjälper. Det enda resultatet jag har märkt är att en gruppmedlem nu känns som en skit.

Det här är verkligen knepigt som ett PM; du måste ta reda på hur du får projektet tillbaka på rätt spår, men det är så lätt att ingjuta tanken på att den här personen underpresterar och sviker teamet. På samma sätt ser resten av laget det hela spela ut och det gör dem oroliga.

Jag skulle uppskatta alla tips om hur man kan hantera den här typen av problem. Mitt tillvägagångssätt är att engagera sig i individen och fokusera på deras designstrategi, och särskilt hur det ser ut för den uppgiften. Om uppgiften verkligen körs länge på tid eller budget, utvärderar jag om det finns en betydande arkitektonisk förändring möjlig som kommer att återställa saker och ting. Att engagera den bredare gruppen kan vara till hjälp men det kan också vara knepigt, se till att alla tänker positivt på potentiella lösningar och undvika allt som kan tolkas (eller misstolkas) som skuld.

Överfokusera inte på Gantt

Ett knep jag har lärt mig om Gantt-diagram är att bara göra dem lika detaljerade som de viktigaste projektmilstolparna. Att gräva längre ner i hela tidens ömsesidiga beroende av enskilda uppgifter är ett otacksamt jobb som inte skapar så mycket värde.

Oftast finns det viktiga uppgifter och milstolpar på hög nivå som bör spåras i ett schema, som när en prototypdesign är klar, när delar beställs, när en första prototypkonstruktion är klar för testning eller när prototyper är färdiga.

Jag tycker att det enda skälet att utforska uppgifter med ökad granularitet är att spåra projektets nedbränning. Detta uppnås effektivt med en lista, där varje objekt tilldelas den uppskattade ansträngningen. När uppgifterna slutförs frigörs den ansträngningen, och den totala uppskattningen till slutförande tickar ner. Nedbränningen av uppgifterna på hög nivå kan informera om hur vi spårar oss till de stora milstolpar som alla bryr sig om.

Ett relaterat tillvägagångssätt jag använder är att bara dela upp uppgifter i deluppgifter när vi är närmare att göra det arbetet. Det enda skälet att dela upp uppgifter är att förbättra granulariteten i vår nedbränning och att fungera som en påminnelse om att inte glömma särskilda saker. Ofta är det bättre att vänta tills arbetet ligger precis framför oss innan vi går vilse i detaljerna.

Schema Förlorar alltid

Det är ganska vanligt att folk pratar om PM:s tredubbla begränsningar (budget, omfattning och schema) och vilken som är viktigast i ett projekt.

Oavsett vad någon säger så verkar budget alltid vinna. När pengarna tar slut slutar växlarna att snurra. Ett projekt där pengar verkligen inte spelar någon roll händer nästan aldrig.

Om budgeten är kung, kommer räckvidden på nära håll. Ja, det finns ofta flexibilitet i hur bra en prototyp behöver vara, men det krävs alltid en miniminivå av färdighet. Om du inte har uppnått det ännu, då är du inte klar. Och arbeta inte bara till ett minimum här, det är aldrig en bra strategi!

Så om vår budget är begränsad och för det mesta orörlig och det finns en nivå av gjort som måste uppnås, måste schemat komma sist.

Jag har arbetat med många projekt som försökt tvinga fram ett schema och de blir alltid sura. Problemet är att om du inte är klar så är du inte klar. Att ständigt fokusera på att vara sen driver alla möjliga typer av improduktivt beteende: dåliga designbeslut, minskad moral och ökade misstag. Poff går glädjen i projektet.

Jag säger inte här att alla projekt kommer att bli försenade – bara att enligt min erfarenhet när det blir knepigt drar schemat alltid det korta strået.

Uppskattning med data

Om du uppskattar ett projekt fungerar en uppifrån och ned-strategi baserad på historiska data bäst. Ett nedifrån och upp-tillvägagångssätt ser imponerande ut och förmedlar en finér av noggrannhet, men är ofta uppsvälld och svår att granska för noggrannhet. Genom att använda faktiska prestandadatapunkter för liknande projekt – idealiskt för just ditt team – ger istället en mer tillförlitlig uppskattning av insatsen.

Enligt min mening är syftet med att uppskatta att fastställa den hink med kontanter som du behöver för att slutföra ett projekt, inte mycket annat. Senare kommer du att vilja ställa in dig för att övervaka och kontrollera projektets framsteg. Det kräver en annan sorts projektuppdelning och analys och är ofta väl lämpad för en nedifrån-och-upp-strategi.

Naturligtvis kan det vara bra att göra båda – du kommer att behöva göra det så småningom. Då kan man mötas på mitten och bygga förtroende för sina siffror.

Nyckeln är att använda historisk data när det är möjligt. På så sätt börjar du med siffror som har bevisats. Nästa steg är att ta reda på hur man upprepar dessa resultat i det nya projektet.

Små lag

Det enda ett stort team är bra för – enligt min erfarenhet – är att bränna budgeten riktigt snabbt. Om du vill att ditt team ska gå snabbare och dina teammedlemmar inte arbetar heltid med ditt projekt, är det bästa du kan göra att få mer av sin tid, inte få fler människor. Om du inte kan få mer av deras tid, kanske du är bättre att bara gå långsammare. Alternativet är att bränna mer budget genom bristande effektivitet.

Ja, du behöver människor med all den kompetens som krävs. Ju mer du kan konsolidera den expertisen till ett litet antal tvärfunktionella individer desto bättre. Jag skulle säga att det fortfarande är bättre även om de inte är superexperter på vissa av dessa områden.

Leta efter Wow

Det är ganska vanligt att du eller en av dina lagkamrater under ett projekt kommer på en idé som låter riktigt bra. Det kan vara att ta designmålen lite längre, det kan vara en ny vändning eller möjlighet som gör att projektet går smidigare.

I det läget tar jag alltid lite hänsyn. Jag frågar först om vi kan uppnå denna nya idé inom den budget och den tid som finns tillgänglig. Ofta – särskilt tidigt i projektet – kommer sådana idéer gratis. Om den nya idén faller inom designmandatet skulle jag säga att gå för det. Om det ligger utanför uppdraget, planera att diskutera det med projektsponsorn. Om det finns en projektrisk förknippad med det – det finns det nästan alltid – så överväg det ändå starkt. Fundera igenom sätt att minska den risken. Tänk igenom allvaret i projektet om risken blir verklighet. Kanske överväga att designa i en plan B eller sätta upp ett experiment för att minska risken.

Om idén dyker upp senare i projektet, överväg den ändå. Efter lite eftertanke kanske det inte tvingar fram en total rip-up, eller så kan den implementeras på ett begränsat sätt. Kanske är det verkligen så revolutionerande att det är värt en total omstart.

Att hålla utkik efter dessa möjligheter och göra ditt bästa för att främja dem är ett bra sätt att stärka lagandan och imponera på kunderna.

Att hitta ett sätt att bara få det gjort är bäst, inom befintlig budget och mandat. Att förvandla varje tillfälle som detta till en omförhandling av omfattning och budget tenderar att döda glädjen.

Det är aldrig för sent att hoppa av en dålig idé

I likhet med att hoppa på bra idéer när de upptäcks, tycker jag att det också är rätt val att hoppa på dåliga så fort de har identifierats. Ett exempel kan vara när ett tidigare arkitektoniskt val upptäcks vara fel. När det hittas tidigt är det ingen stor sak. Men ibland dyker de upp senare i ett projekt och det gör det svårt. Ändå kommer dessa problem att fortsätta att förvärras. Innan du vet ordet av är det en full-on Hail Mary med lager av plåster och det blir svårare och svårare att rätta till.

Vi måste hela tiden göra arkitektoniska val med begränsad information. Vissa av dessa visar sig vara fantastiska – andra inte så mycket. När vi väl inser att vi inte är på väg mot storhet, då bör vi snabbt korrigera. Om detta innebär lite av en projektåterställning, låt alla veta som behöver och korrigera kursen. Att hoppas att saker och ting kommer att bli bättre på något sätt när du vet att de är på fel spår är ingen bra strategi för framgång.

Ta inte beslut för tidigt

Det är ofta tröstande att göra avgörande arkitektoniska val tidigt i ett projekt. Det känns som att vi verkligen finslipar vår bana och vi känner att den ökade tydligheten i omfattning kommer att öka våra chanser att lyckas. Enligt min erfarenhet kan det vara bättre att skjuta upp beslut tills de är absolut nödvändiga.

Alla beslut behöver inte ske direkt för att ett team ska vara effektivt. Vissa beslut kommer naturligtvis att bli bättre informerade när andra uppgifter går framåt. Det är den sortens val som är värda att hålla tillbaka på.

Vi kan fortfarande notera våra alternativ, till den tillgängliga upplösningen, men vänta med att välja definitivt tills vi verkligen måste. Jag menar inte att försena projektet; Jag menar att inte fatta ett beslut förrän du är vid den punkt där du måste gå ner för en eller annan gaffel. När du närmar dig gaffeln kan du tänka igenom den information du verkligen vill ha när du kommer dit. Detta kan leda till att du ändrar ordningen för vissa uppgifter för att generera denna säkerhet; kanske finns det några nya aktiviteter som hjälper till med beslutet.

Problemet är att när ett beslut ligger bakom oss börjar vi sammansätta beslut ovanpå det. Snart så länge blir möjligheten att ångra det alldeles för kostsamt.

Effektiva team är ofta resursbegränsade

Jag tycker att när ett team kör med maximal effektivitet är det alltid lite begränsade resurser. Detta är förmodligen ett resultat av några av mina andra tumregler: att hålla laget litet, budget och omfattning kommer först, etc.

Tricket här är att vänja sig vid det. Ja, ditt projekt kommer att hamna i flaskhals då och då. Ja, uppgifter kommer att glida om andra kör för mycket. Jag skulle tänka mycket noga innan du överväger att dra in en annan lagmedlem, speciellt om du bara behöver en bråkdel av deras tid.

Jag hoppas att du har hittat några användbara guldkorn i dessa tips. Kanske några av dem resonerade med dina erfarenheter, kanske några föreslår en annan och möjligen användbar snurr på att hantera prototypiterationer.

Bild: StarFish Medical

Kenneth MacCallum, PEng, är en teknisk ingenjörsfysiker vid StarFish Medical. Han jobbar vidare Innovation inom medicinsk utrustning för en mängd olika områden inklusive ultraljudstillämpningar. Kenneth skulle tycka om att höra från läsarna om deras referensdesign och upplevelser.



• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://starfishmedical.com/blog/top-lessons-in-project-management-of-medical-device-development/