10 απλοί τρόποι να κάνετε “Kill” ένα IT Project!
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Δεν υπάρχει κανένας λόγος να εμπλέξετε τους χρήστες. Δεν απαιτούνται. Ούτως ή άλλως τι θα κάνουν σε τέτοιους δύσκολους καιρούς. Θέλουν δεν θέλουν, θα χρησιμοποιήσουν το προϊόν του project. Καλό είναι επίσης να εφαρμόσετε το “user error, replace user!”

Μα είναι δυνατόν το management της εταιρείας να γνωρίζει από IT Projects; Το management είναι μόνο για να εγκρίνει το project και να μας δώσει τα χρήματα. Δεν χρειάζεται να υποστηρίξει το έργο. Αφού το ενέκρινε, ποιος θα τολμήσει να μην το χρησιμοποιήσει! Α, και μην εξηγήσετε ΠΟΤΕ στον Οικονομικό Δ/ντή της εταιρείας ποιο είναι το CAPEX, το OPEX, και το όφελος του project!

Πάντοτε να κάνετε το καλύτερο σύστημα ή την καλύτερη εφαρμογή στον πλανήτη. Έστω και αν οι χρήστες απαιτούν κάτι απλό, πχ. καταγραφή εισερχόμενων κλήσεων μόνο, εσείς να φτιάχνετε το τέλειο: 87 combo boxes, άπειρα pop-up messages, ενεργοποίηση 12 function keys, σύνδεση με το ERP, αυτόματη αποστολή email και sms, σύνδεση με τον τηλεφωνικό κατάλογο του ΟΤΕ, κλπ. Κάνοντας την τέλεια εφαρμογή είναι σαν να δοκιμάζεται να «βράσετε τον ωκεανό – Βoil Τhe Ocean (ΒΤΟ)!»

Κάθε έργο έχει το product scope (τα χαρακτηριστικά του προϊόντος) και το project scope (όλες οι εργασίες που πρέπει να γίνουν για να παραδοθεί το product scope). Δεν υπάρχει κανένας λόγος να είστε συγκεκριμένοι. Αφήστε τα πράγματα στο «φλου» και επιδιώξτε το scope creep (την ανεξέλεγκτη αύξηση του φυσικού αντικειμένου). Ενοείτε ότι δεν πρέπει να φτιάξετε WBS γιατί, από τα πολλά που τάξατε, κάτι θα παραδώσετε στο τέλος για να βγείτε νικητές!

Πάντα να δεσμευόσαστε σε οποιοδήποτε χρονοδιάγραμμα σαν ζητάτε. Εάν σας πουν “we need this project yesterday”, γυρίστε το χρόνο πίσω. Δεν είναι δύσκολο. Μην κάνετε καθόλου planning για να δείτε τι είναι εφικτό και τι ανέφικτο χρονικά. Εξάλλου η μέρα έχει 24 ώρες και η βδομάδα 7 μέρες. Τα resources είναι unlimited!

Κρατήστε τα κόστη του έργου στο ελάχιστο. Μην λαμβάνεται υπόψη σας τα εσωτερικά κόστη, μόνο ότι πληρώνεται στους sub-contractors. Αγνοείστε τις ώρες του προσωπικού σας πάνω στο έργο (αφού πληρώνονται ούτως ή άλλως, γιατί να τους υπολογίσω Μην υπολογίσετε ποτέ τα overhead κόστη της εταιρείας. Εννοείται ότι δεν λαμβάνεται υπόψη αποσβέσεις στον υπολογισμό του κόστους του έργου.

Χρησιμοποιήστε “Fixed-Price Contract” για να αγοράσετε από τους προμηθευτές σας αγαθά και υπηρεσίες. Ζητήστε τα πάντα και πληρώστε τίποτε εάν γίνεται (Best Value For No Money – BVFNM!). Ούτως ή άλλως με την κρίση που υπάρχει πάντα κάποιος θα δεχθεί να κάνει το έργο για να μπορέσει να «πατήσει πόδι» στην εταιρεία σας.

Μην ασχολείστε με “known-unknowns” και risk response planning. Οι προμηθευτές σας παθαίνουν πανικό όταν ακούν κακές λέξεις όπως «risk management». Όταν σας τύχει κάτι απρόβλεπτο, π.χ. παραιτηθεί και ο 5^ος προγραμματιστή σας, αργήσει η παράδοση του εξοπλισμού για 100^η φορά, ξαναγίνει διακοπή ρεύματος την ώρα που κάνετε OS upgrade, εφαρμόστε την “reactive technique”: κάντε ένα meeting με όλη την ομάδα έργου για να πάρετε ιδέες αντιμετώπισης του θέματος!

Ενημερώστε τους ανθρώπους της πληροφορικής που εργάζονται στο project, να κρατούν τις πληροφορίες για «την πάρτη τους». Ποιος θα καταλάβει μέσα στην εταιρεία τόσες τεχνικές ορολογίες; Γιατί να ζαλίσουμε τους stakeholders του έργου με status reports, progress reports, issues reports, CPI, SPI, ETC και λοιπές άχρηστες πληροφορίες; Το πολύ να τους στέλνουμε ένα mail το μήνα ότι το έργο προχωράει “as planned”!

Το project management είναι κόστος για το έργο. Πουλήστε εκδούλευση στον CFO της εταιρείας και πείτε του ότι δεν θα κάνετε project management στο έργο και θα γλυτώσετε χρήματα από το budget! Εφαρμόστε την τεχνική RBL (Rtsi Bourtzi & Loulas). Η τεχνική «Άρτζι, Μπούρτζι και Λουλάς» δηλώνει χαλαρότητα και ξεγνοιασιά. Μην ασχολείστε με τα παραδοτέα και τα milestones. Να είστε χαλαροί με το project controls. Να τελειώνετε το έργο πάντα με πάρτη όπου είναι όλοι καλεσμένοι. Εάν βέβαια τελειώσει το έργο και είστε ακόμη στην εταιρεία!


Θεοφάνης Γιώτης / Theofanis Giotis
[email protected] / [email protected]