Ti tegn på et datalagringsprosjekt i problemer - dummies

Du kan lettest fortelle at datalagringsprosjektet ditt er i trøbbel når du ikke har noe å vise for din innsats når du trodde du ville. Prøv å få en indikasjon på at brygging av problemer, men før kommer til det punktet. Denne listen presenterer ti tidlige advarselsskilt.

Prosjektets omfangsfase slutter uten generell konsensus

Den tildelte tiden for omfanget av datalagerprosessen din slutter (vanligvis to eller tre uker - litt lengre for store prosjekter), og medlemmene i din valgkrets er ulykkelig.

De er fortsatt grumbling og uenige om prosjektets retning og dens potensielle forretningsverdi (eller mangel på det), de relative prioritetene til evner og hvordan de kartlegges i ulike prosjektfaser og andre punkter.

Oppdragsgivers uttalelse blir besvart etter at omfanget av fasen slutter

Du er tre uker inn i designfasen, etter en fire ukers rekkevidde. Du er i et formiddags statusmøte med IT- og forretningsorganisasjonens ledende sponsorer, samt fire sentrale ledere fra de forretningsområdene som planlegger å bruke data warehouse mest.

Like før en kaffepause, sier en av lederne, "Kjenner du den oppdraget vi snakket om på prosjektets andre dag? Jeg vil snakke om det litt mer fordi jeg har noen problemer med det. "

Verktøy er valgt uten tilstrekkelig undersøkelse.

En prosjektbeslutningsperson ser rundt i rommet i avsky, sukker dypt og sier," Se, vi har ikke tid til å sjekke ut disse verktøyene fordi tidsplanen er for stramt. Den leverandøren som var her i går - hva var det navnet på firmaet igjen? Du vet, de med produktet som - Jeg kan ikke huske alle detaljene. Uansett, likte jeg demoen. Vi kjøper det verktøyet. “

Folk blir trukket fra laget ditt for "Bare noen dager"

"Jeg skal låne Mary, John og Sue Ellen i et par dager fordi vi har noe viktig over i skoenet plast-tips divisjon som må gjøres så snart som mulig. Uansett tror jeg at det vil være bare noen få dager. Prøv å holde deg på planen. "

Du har problemer.

Du er overruled når du forsøker å håndtere omfangskreft

Du er i den siste uken i designfasen, og en forretningsenhetssjef setter seg over fra deg i kafeteriaen. Mellom mouthfuls av Chef's Daily Surprise, forteller han deg om "disse en eller to ting jeg nettopp trodde på, ville gjøre dette datalageret jobbe mye bedre."

Du forklare konseptet om omfangskryp i sammenheng med" Vent til% $ # ^ @ neste fase av datalageret! "(Bortsett fra at du er mer diplomatisk om det). Så to dager senere sender lederens sjef (som også er sjefen din) en e-postmelding som retter deg om å "legge til en eller to ting i funksjonslisten, men ikke la dem påvirke timeplanen. "

Din utøvende sponsor forlater selskapet

Du har gjort en fantastisk jobb med å selge forretningsverdien til datalagringsprosjektet til daglig leder, og alt ruller sammen pent. Plutselig, to dager etter en imponerende kunngjøring om skuffende kvartalsvise salg og inntjening, avtar den utøvende sponsoren fra organisasjonssiden av organisasjonen. Nå har prosjektet ikke en executive sponsor.

Du kan være i trøbbel: Arbeid fort og ikke se tilbake.

Du hører, "Dette vil aldri fungere, men jeg sier ingenting"

Alle i selskapet støtter data warehousing-prosjektet. Du skyver forkant av teknologien, og alle i teamet ditt er entusiastiske. Deres ukentlige statusrapporter viser til og med fremgangen de gjør. Prosjektets sjefsarkitekt forsikrer deg om at jo mer du kommer inn i prosjektet, desto mer er alle overbevist om at du har gjort gode tekniske beslutninger.

Deretter hører du i kafeteriaen to av de eldre utviklerne som diskuterer prosjektet. En sier, "Det er ingen måte at denne tingen kan fungere. Ytelsen er forferdelig, og halvparten av tiden samme spørring mot de samme dataene returnerer forskjellige resultater! Men jeg kommer ikke til å være den som skal ta det opp! "

Du finner en stor" Uh-Oh "i et av produktene du bruker.

Til tross for din beste innsats ved produktevaluering, har noe gått gjennom sprekker, og en viktig funksjon virker bare ikke. Selv om du kan bruke en arbeidsplass, påvirker det arbeidet virkelig negativ ytelse.

Leverandørens representanter slyly sier: "Vel, vi hadde hørt at det kan være et problem. Vår utviklingsorganisasjon ser på det og vil trolig gjøre en oppdatering tilgjengelig i neste måned eller så. "

IT-organisasjonen som er ansvarlig for å støtte prosjektet, drar sin støtte.

Din utviklingsgruppe har ansvaret for det meste av data warehousing-utviklingen, inkludert forretningsinformasjonsverktøyene og databasdefinisjonene. IT-organisasjonen er imidlertid ansvarlig for å opprette databaser og utføre belastningsrutiner, utføre sikkerhetskopierings- og gjenopprettingsprosedyrer, og ta vare på mange av prosjektets andre infrastrukturelementer.

På grunn av høyere prioriteringer trekker IT-organisasjonen de ansvarlige for å støtte prosjektet, og lederen lover å "se på et annet svar. "Hun sier," Kanskje vi skal ansette et par entreprenører, men jeg vil ikke kunne se på det før neste uke. "

Avganger begynner

Avganger er et sikkert tegn på at store problemer ligger foran.Selv folk som er misfornøyde med et selskap gir ofte lojalitet eller en følelse av plikt, og de holder seg til prosjektet er ferdig. (Eller kanskje de bare vil ha résumé-fôret.)

Når en rekke mennesker trekker seg midt i et prosjekt, er du imidlertid i trøbbel.