Ο κόσμος του IT είναι γεμάτος από παραδείγματα έργων IT που «στέφθηκαν» με αποτυχία και οποιοσδήποτε έχει υπάρξει μέρος ενός τέτοιου έργου πιθανόν να αισθάνθηκε την αποτυχία πολύ πριν την ολοκλήρωσή του.
Η «έκτη αίσθηση» αποτελεί ανεκτίμητο προσόν στον τομέα του IT - αλλά μόνο με τη σωστή διαχείρισή της τα προβλήματα αντιμετωπίζονται γρήγορα και επαγγελματικά.
Είτε προσπαθείτε να αποφύγετε να επιβαρυνθείτε με μια αποτυχία είτε να οδηγήσετε μια καταδικασμένη εγκατάσταση εκτός πεδίου κινδύνου, πρέπει να μπορείτε να αναγνωρίσετε τα σημάδια της άμεσης αποτυχίας πολύ πριν το έργο καταρρεύσει ολοκληρωτικά. Αλλωστε,αυτό μπορεί να αποφανθεί σωτήριο για μια καριέρα. Ποιες είναι, ωστόσο, εκείνες οι ενδείξεις που μπορούν να σηματοδοτήσουν την αποτυχία ενός έργου.
Το έργο έχει ξεκινήσει χωρίς «έγκριση»
Συνήθως αυτό συμβαίνει όταν ένα στέλεχος, με ιδιαίτερα δυναμική προσωπικότητα, έχει μια «εξαιρετική» ιδέα και ξεκινάει την εφαρμογή της με συναντήσεις και κατανομή πόρων, χωρίς όμως να έχει πάρει έγκριση από τα ανώτερα στελέχη. Ωσπου φτάνει η στιγμή που απαιτούνται πραγματικά χρήματα για να συνεχιστεί το project και σε αυτό το σημείο το έργο καταρρέει πλήρως.
Για να αποφύγετε την ανάμειξή σας σε ένα τέτοιο έργο, πάντα να αναζητάτε και να συμβουλεύεστε τον ανώτερο υπεύθυνο σχετικά με ένα project. Αν πάλι λειτουργείτε ως σύμβουλος σε ένα έργο, βεβαιωθείτε ότι οι πόροι που έχουν κατανεμηθεί επαρκούν.
Δεν υπάρχει λεπτομερής σχεδιασμός
Ο σχεδιασμός ενός έργου μπορεί να αποτελέσει περίπλοκη και απογοητευτική διαδικασία, ωστόσο ένα έργο που δεν διαθέτει λεπτομερή σχεδιασμό οδεύει προς τη σίγουρη αποτυχία. Τα «επίσημα» σχέδια ενός έργου «αναγκάζουν» τον project manager, και όλους τους υπόλοιπους εμπλεκόμενους, να σκεφτούν τα επόμενα βήματα και τη σειρά που πρέπει να ακολουθήσουν. Με απλά λόγια: «η αποτυχία στο σχεδιασμό αποτελεί σχεδιασμό για την αποτυχία».
Οι συναντήσεις έχουν καθοριστεί χωρίς να ληφθεί υπόψιν η διαθεσιμότητα των συμμετεχόντων
Οταν ένας project manager ή team leader σχεδιάζει συναντήσεις που συμπίπτουν με άλλες σημαντικές, και ήδη κανονισμένες, συναντήσεις, τότε είναι σίγουρο ότι το έργο οδεύει προς την αποτυχία. Ακολουθώντας μια τέτοια τακτική, σημαντικά μέλη της ομάδας δεν θα μπορέσουν να παρευρεθούν, επομένως υπονομεύεται ο σκοπός και η αποτελεσματικότητα της συνάντησης.
Οι χρήστες είχαν ελάχιστη (ή και καθόλου) ανάμειξη στα πρώιμα στάδια
Είναι ευρέως γνωστό ότι η σωστή πρακτική όταν ξεκινάει ένα έργο IT είναι να εμπλέκουμε τον τελικό χρήστη νωρίς ή και στη διαδικασία λήψης αποφάσεων. Για τον λόγο αυτό, αποτελεί έκπληξη το γεγονός ότι βλέπουμε μεγάλα και πολύπλοκα έργα σχεδόν ολοκληρωμένα πριν καν ο χρήστης εμπλακεί για να δώσει τη δική του οπτική και άποψη. Πρέπει να βεβαιωθούμε ότι οι πραγματικοί χρήστες, ή οι εκπρόσωποί τους, έχουν κληθεί να συμμετάσχουν από την αρχή του έργου.
Οσο περισσότερο εμπλακούν οι χρήστες τόσο μεγαλύτερη είναι η πιθανότητα επιτυχίας. Και αν ένα έργο αφορά πολλαπλά τμήματα, πρέπει να βεβαιωθούμε ότι υπάρχει εκπρόσωπος των χρηστών από όλα αυτά τα τμήματα. Τέλος, πρέπει να βεβαιωθούμε ότι οι χρήστες που έχουν κληθεί να συμμετάσχουν είναι «ανοιχτοί» στους στόχους του έργου και μπορούν να εκφράσουν την πραγματική τους άποψη.
Το έργο στοχεύει στις ελάχιστες προδιαγραφές
Τίποτα δεν μπορεί να βλάψει περισσότερο ένα έργο από την αγορά hardware ελάχιστων απαιτήσεων. Οι πάροχοι είναι γνωστό ότι προσπαθούν να κρατήσουν το κόστος ενός έργου χαμηλά πουλώντας κάτω του κόστους το απαραίτητο hardware για βέλτιστα αποτελέσματα. Συνήθως, οι πάροχοι δίνουν μια ελάχιστη προσφορά για το hardware, την οποία όμως οι «έξυπνοι» project managers θα πρέπει να «προσπεράσουν», ώστε αν κάτι πάει στραβά στην πορεία του έργου, οι πελάτες και οι πάροχοι δεν θα επιρρίψουν ευθύνες στην «οικονομική» αγορά hardware. Επίσης, πρέπει να βεβαιωθούμε ότι το hardware και το software που αγοράστηκε για ένα συγκεκριμένο project είναι συμβατά μεταξύ τους και έχουν δοκιμαστεί πριν ληφθούν οι τελικές αποφάσεις.
Οι δοκιμές έρχονται σε «δεύτερη μοίρα»
Οι δοκιμές είναι απαραίτητες για την επιτυχία ενός έργου. Είτε αφορά δοκιμές από ένα συγκεκριμένο τμήμα (που δοκιμάζει μία μόνο πλευρά του συστήματος) είτε αφορά ολοκληρωμένο έλεγχο (που δοκιμάζει όλα τα κομμάτια του έργου), οι δοκιμές πρέπει να γίνονται από τους εργαζόμενους με βάση ένα «σενάριο». Οι δοκιμές πρέπει, επίσης, να περιλαμβάνουν και δοκιμές loading δεδομένων, ώστε να ξέρουμε πώς λειτουργεί το σύστημα και το δίκτυο υπό πίεση.
Δεν υπάρχει σχέδιο επανάκαμψης σε περίπτωση αποτυχίας
Κάθε project manager πρέπει να γνωρίζει πότε πρέπει να παραδεχτεί την αποτυχία του και να ξεκινήσει τις προσπάθειές του εκ νέου. Κάθε έργο πρέπει να έχει ένα back-up σχέδιο σε περίπτωση που το αρχικό αποτύχει. Πολλά έργα δυστυχώς οδηγούνται στην αποτυχία καθώς ακολουθούν το «δόγμα» ότι «τίποτα δεν μπορεί να πάει στραβά». Οι managers αυτών των έργων συχνά δεν διαθέτουν κάποιο back-up σχέδιο, το οποίο είναι σωστά οργανωμένο και επαληθευμένο.
Δεν αναπτύσσουν πρωτόκολλα για τον προσδιορισμό της επιτυχίας και δεν προετοιμάζουν την ομάδα τους για το πώς πρέπει να κινηθεί σε περίπτωση που το έργο αποτύχει. Σίγουρα η αποτυχία ενός έργου είναι ενοχλητική και κανένας manager δεν θέλει να σχεδιάζει ένα έργο με γνώμονα την αποτυχία. Αλλά το να μην μπορέσει να επανακάμψει σε περίπτωση που το έργο βρεθεί μπροστά σε κάποιο εμπόδιο είναι ακόμη χειρότερο και, σε πολλές περιπτώσεις, μπορεί να αποβεί «μοιραίο» για μία καριέρα.
Οι συστάσεις/συμβουλές των ειδικών έχουν απορριφθεί χωρίς να δοκιμαστούν
Υπάρχουν managers που ζητούν συμβουλές από ειδικούς, τις οποίες όμως μετά αγνοούν και ακολουθούν διαφορετική πορεία και έπειτα «ενοχλούνται» που κάτι δεν λειτουργεί σωστά. Δεν θα πρέπει να επιτρέπουμε σε αυτούς τους εργαζόμενους να λαμβάνουν σημαντικές αποφάσεις για ένα έργο. Ενώ είναι καλό να ζητάμε συμβουλές και συστάσεις από ειδικούς, το να τις αγνοούμε μετά είναι απλά ανούσιο.
Και ακόμη και στην περίπτωση που ο σύμβουλος συμφωνεί με την αλλαγή στην πορεία του έργου, καλό θα είναι να βεβαιωθούμε πρώτα ότι η εναλλακτική πορεία έχει δοκιμαστεί. Πολλά έργα αποτυγχάνουν ακριβώς λόγω αυτού, επειδή δηλαδή ο project manager κάνει μικρές αλλαγές που, όμως, φέρνουν τους συμβούλους σε δύσκολη θέση «κουνώντας το κεφάλι» απογοητευμένοι.
Η go-live ημερομηνία είναι Σαββατοκύριακο ή αργία
Πολλοί project managers σχεδιάζουν την ημερομηνία «πρεμιέρας» ενός έργου για κάποιο Σαββατοκύριακο ή κάποια αργία, καθώς τότε υπάρχουν λιγότερες πιθανότητες να διαταραχθούν οι εργασίες των εργαζομένων ή των πελατών. Και ενώ αυτό είναι «αξιέπαινο», σε αυτές τις χρονικές περιόδους είναι επίσης δύσκολη η πρόσβαση στην τεχνική υποστήριξη. Μπορεί μεν ο κύριος πάροχος τεχνικής υποστήριξης να είναι on-site, αλλά οι εξωτερικοί πάροχοι μπορεί να μην εργάζονται ή να μην είναι διαθέσιμοι, και φυσικά το ίδιο μπορεί να ισχύει και για την ομάδα σας.
Δεν έχουν οριστεί ξεκάθαρα οι προσδοκίες του έργου
Οταν ένα νέο σύστημα πρόκειται να αντικαταστήσει ένα παλιό, θα βοηθήσει όλους τους εμπλεκόμενους να έχουν κατανοήσει τις προσδοκίες του νέου έργου. Πώς θα λειτουργεί το νέο σύστημα; Πόσο θα διαφέρουν οι διαδικασίες συναλλαγών; Ποιον θα πρέπει να καλέσουν οι τελικοί χρήστες αν αντιμετωπίσουν προβλήματα; Ενα νέο σύστημα πάντα θα αγχώνει τους χρήστες, αλλά αν θέσουμε ρεαλιστικές προσδοκίες και τους παρέχουμε επιταχυνόμενες επιλογές υποστήριξης, τα προβλήματα τείνουν να εξαλείφονται γρηγορότερα και φυσικά στο τέλος καταλήγουμε να έχουμε πιο ικανοποιημένους πελάτες.
«Τσιγκουνιές» στην εκπαίδευση
Πολλοί project managers θα προσπαθήσουν να μειώσουν τις δαπάνες για την εκπαίδευση των εργαζομένων και των χρηστών όταν έρχονται αντιμέτωποι με μια υπέρβαση στον προϋπολογισμό ενός έργου. Συνήθως, είναι κάποιος ιδιαίτερα αυτάρεσκος project manager που θα ισχυριστεί ότι το σύστημα είναι πολύ εύκολο και δεν χρειάζεται ιδιαίτερη εκπαίδευση.
Και φυσικά δεν είναι μόνο οι χρήστες που χρειάζονται εκπαίδευση αλλά και οι ίδιοι οι project managers και το προσωπικό υποστήριξης. Επιπλέον, πρέπει να είμαστε πρόθυμοι ακόμη και να καθυστερήσουμε την ολοκλήρωση ενός έργου αν χρειάζεται περαιτέρω εκπαίδευση ή αν δεν έχει ήδη δοθεί η κατάλληλη εκπαίδευση.
Δες το άρθρο της Ελένης Χρυσαφοπούλου εδώ.
Σχόλια