GK seminars Society
Η κοινωνική προσφορά είναι υπόθεση όλων μας!
Στο πλαίσιο αυτό διοργανώνουμε κάθε χρόνο ενέργειες και δράσεις εθελοντικού χαρακτήρα.
Month: March 2022
Η κοινωνική προσφορά είναι υπόθεση όλων μας!
Στο πλαίσιο αυτό διοργανώνουμε κάθε χρόνο ενέργειες και δράσεις εθελοντικού χαρακτήρα.
Δεν είναι λίγες οι φορές που τα δύο αυτά έγγραφα έχουν αποτελέσει αφορμή για ώρες συζητήσεων. Ορισμένοι μπορεί να θεωρούν ότι είναι τα ίδια με άλλο όνομα. Οι διαφορές τους ωστόσο είναι σαφείς και θα πρέπει να τις έχουμε στο μυαλό μας όταν τα συντάσσουμε.
Το παρών δεν έχει σκοπό να περιγράψει τα περιεχόμενα του καθενός, διότι αυτά μπορεί να ποικίλουν καθώς:
Ωστόσο για την καλύτερη κατανόηση τους θα περιγράψω κάποιους όρους που είναι σημαντικό να περιλαμβάνει το κάθε έγγραφο.
Για να καταλάβουμε το τι είναι το καθένα πρέπει πρώτα να κατανοήσουμε την διαφορά στον ΣΚΟΠΟ τους.
Βρίσκεσαι σε έναν οργανισμό, και παρατηρείς ότι υπάρχει είτε ένα πρόβλημα σε αυτόν είτε ότι μια ανάγκη του πρέπει να καλυφθεί. Σκέφτεσαι μια ιδέα που θα μπορούσε να λύσει αυτό το πρόβλημα ή να καλύψει αυτήν την ανάγκη.
Ο σκοπός λοιπόν του Business Case είναι:
Προσοχή: Ακόμα δεν χρησιμοποιώ τον όρο Project γιατί ακόμα δεν υπάρχει Project.
Ο οργανισμός που εργάζεσαι έχει ένα εργαστήρι. Παρατήρησες ότι υπάρχει ένα πρόβλημα το οποίο είναι ότι δεν χωράνε οι εργαζόμενοι.
Η περιγραφή του προβλήματος, θα ήταν κάπως έτσι.
« Στο εργαστήρι υπάρχει συσσώρευση μεγάλου αριθμού προσωπικού και υλικών. Αυτό προκαλεί πρόβλημα στην εναποθήκευση των εργαλείων μας κάτι που δεν επιτρέπει την άμεση πρόσβαση μας σε αυτά. Παράλληλα δεν μπορούν να εργαστούν άνετα οι εργαζόμενοι μας, μειώνοντας την απόδοση τους και αυξάνοντας τις μεταξύ τους συγκρούσεις.»
Αφού έχεις περιγράψει το πρόβλημα που έχεις εντοπίσει θα εξηγήσεις το πως προτείνεις να λύσεις αυτό το πρόβλημα. Σίγουρα η λύση ενός προβλήματος δεν είναι μόνο μια και σε αυτό το σημείο μπορείς να γράψεις όσες περισσότερες πιστεύεις ότι θα επιλύσουν το πρόβλημα.
Για να λυθεί το παραπάνω πρόβλημα οι πιθανές εναλλακτικές λύσεις μπορεί να είναι οι παρακάτω:
Τελειώνεις την περιγραφή των εναλλακτικών που προτείνεις και περνάς στο δεύτερο κομμάτι του ΣΚΟΠΟΥ του εγγράφου που είναι να Πείσεις την διοίκηση.
Να την πείσεις ότι αξίζει να λυθεί το πρόβλημα και όχι να ξεκινήσει το έργο. Για να το κάνεις αυτό θα εξηγήσεις ποιο θα είναι το όφελος, εάν θα λυθεί το πρόβλημα καθώς και ορισμένα οικονομικά μεγέθη.
Σε αυτό το σημείο μπορείς να περιγράψεις και άλλα σχετικά με την ιδέα σου όπως για παράδειγμα ένα TimeMap, κάποια Business Risks, ορισμένους βασικούς περιορισμούς κ.α.
Με την ολοκλήρωση της σύνταξης του εγγράφου, το έγγραφο θα παραδοθεί στην διοίκηση ή στο όργανο μέσα στην εταιρία που είναι υπεύθυνο για την λήψη αποφάσεων. Θα ελεγχθεί η σημαντικότητα του προβλήματος και εάν συμφέρει την διοίκηση να το λύσει σε σύγκριση με το όφελος που θα έχει.
Η διοίκηση μπορεί να απορρίψει, ή να εγκρίνει την υλοποίηση όλων ή μερικών από τις λύσεις που έχεις προτείνει.
Από την στιγμή που η διοίκηση αποφασίσει ότι αξίζει να λυθεί το πρόβλημα, ορισμένες από τις λύσεις που έχεις προτείνει, θα τις εντάξει σε ένα project. Αντίστοιχα κάποιες άλλες θα τις εντάξει σε ένα άλλο project κλπ.
Στην ουσία, με την έγκριση του Business Case γεννιέται το project και από εκείνη την στιγμή και μετά μπορούμε να συζητάμε για την ύπαρξη του. Πριν την έγκριση του απλώς υπάρχει ένα πρόβλημα και μια ιδέα για το πως θα το προσεγγίσουμε.
Η διοίκηση έχει εξετάσει το Business Case και έχει αποφασίσει ότι θα υλοποιήσουμε τις δύο από τις τρείς λύσεις που είχαμε προτείνει. ( Να κατασκευάσουμε μια αποθήκη δίπλα από το εργαστήρι, να κατασκευάσουμε ντουλάπια και ράφια για την ευταξία του χώρου).
Η υλοποίηση αυτών των λύσεων αποτελεί ένα Project και η διοίκηση αναθέτει την υψηλή του εποπτεία στον Sponsor του έργου. Αυτό συμβαίνει γιατί η διοίκηση δεν μπορεί να έχει όλη την ώρα στο μυαλό της τι συμβαίνει σε κάθε έργο… γιατί δεν θα μπορεί να κάνει την δουλεία της ( που δεν είναι άλλη από τον Στρατηγικό της Σχεδιασμό) (δηλαδή το θέμα είναι πρακτικό). Έτσι τα έργα τα αναθέτει σε κάποιον από τους Sponsors που θα υπάρχουν στον οργανισμό.
Υπόλογος (Accountable) για την σύνταξη του Project Charter είναι ο Sponsor αλλά:
μεταβιβάζει το responsibility σύνταξης του Project Charter στον Project Manager.
Ο σκοπός ύπαρξης του Project Charter είναι να βοηθήσει τον Project Manager – Sponsor να κατανοήσουν:
Το Project Charter λειτουργεί ακριβώς όπως μια εργασία που βάζει ένας καθηγητής πανεπιστημίου σε έναν μαθητή. Έχει σκοπό την καλύτερη – βαθύτερη κατανόηση του θέματος από τον Project Manager.
Με το Project Charter εξασφαλίζεις ότι τόσο εσύ σαν Project Manager όσο και ο Sponsor – Διοίκηση θα έχετε μια γενική εικόνα από διάφορες οπτικές γωνίες που θα περιγράφουν το έργο. Είναι ένα πρώτο επιδερμικό πέρασμα από τις βασικές του πτυχές που όμως εξασφαλίζουν ένα καλό ξεκίνημα στο έργο.
Γι’ αυτό μέσα στο έγγραφο θα περιγράψω πληροφορίες όπως:
Τα περιεχόμενα του Project Charter σίγουρα δεν θα είναι τα ίδια σε κάθε Project. Σίγουρα όμως θα προσπαθούν να φέρουν στην επιφάνεια τις διάφορες πτυχές του έργου.
Σημαντικό είναι να αναφερθεί ότι καθόλη την διάρκεια σύνταξης του Project Charter, ο project manager βρίσκεται σε στενότατη επαφή με τον Sponsor. Αυτό συμβαίνει διότι ο Sponsor είναι ο κύριος πληροφοριοδότης του Project Manager (μέχρι στιγμής).
Αφού συμπληρωθεί το Project Charter από τον Project Manager, θα πρέπει να υπογραφθεί από τον Sponsor. Η υπογραφή του σημαίνει πρώτον ότι συμφωνεί με αυτά που γράφθηκαν στο Project Charter και με την προσέγγιση του Project Manager ως προς το έργο και δεύτερον ότι συμφωνεί με την περαιτέρω και σε μεγαλύτερο βάθος διερεύνηση του έργου ( φάση Planning) κάτι που απαιτεί την δέσμευση περισσότερων πόρων από την εταιρία για να ασχοληθούν με το έργο.
Προσοχή το έγγραφο δεν το κάνει το όνομα αλλά το περιεχόμενο. Μπορεί να νομίζουμε ότι συντάσσουμε ένα Business Case και στην πραγματικότητά να συντάσσουμε ένα Project Charter ή και το αντίστροφο.
Για να αποφύγουμε αυτό το μπέρδεμα και να συντάξουμε και τα δύο με τα περιεχόμενα και τα νοήματα που πρέπει να περιλαμβάνουν, οφείλουμε να κατανοήσουμε σε βάθος τον σκοπό τους – το WHY τους.
MilEng, PMP®,PM2
Απαιτήσεις έργου VS Φυσικό Αντικείμενο
Ποια είναι η Διαφορά μεταξύ του Requirement και του Scope (Product and Project scope);
Σε μια πιο ελεύθερη μετάφραση και οι δύο όροι σχετίζονται με την περιγραφή του τί θα φτιάξουμε – κατασκευάσουμε κατά την διάρκεια του έργου και πως θα μοιάζει γενικά αυτό που θα πάρει ο πελάτης στα χέρια του στο τέλος, είτε αυτό είναι μια υπηρεσία είτε ένα προϊόν. Ωστόσο οι δύο όροι δεν είναι επικαλυπτόμενοι και θα πρέπει να χρησιμοποιούνται στο έργο μας με την σωστή σημασία.
Η βασική ιδέα είναι ότι πρώτα θα συλλέξω τα Requirements (Collect Requirements) του έργου δηλαδή τις διάφορες απαιτήσεις που πρέπει να καλύψω με το έργο μου. Στην συνέχεια, αυτά θα μου υποδείξουν το πως θα διαμορφώσω το Φυσικό Αντικείμενο (Define Scope) του έργου, το οποίο θα ικανοποιήσει τις διάφορες αυτές απαιτήσεις.
Έχεις ολοκληρώσει την αναγνώριση των Stakeholders καθώς και μια πρώτη ανάλυση τους για να καταλάβεις την δύναμη και το ενδιαφέρον τους στο έργο (Stakeholders Analysis). Επόμενο βήμα η εκμαίευση των Requirement.
Τα Requirements είναι οι ανάγκες – απαιτήσεις τις οποίες θα πρέπει να καλύψουμε με την ολοκλήρωση του έργου.
Παράδειγμα: Για ένα έργο που είναι η κατασκευή μιας οικίας, διατυπώσεις requirements μπορεί να είναι οι παρακάτω. (Από την πλευρά του πελάτη)
Οι δεξαμενές που μπορούμε να αντλήσουμε τα Requirements του έργου είναι:
Τα Requirements τα καταγράφουμε σε ένα Requirement Traceability Matrix. Αποτελεί ένα Template και μπορεί να διαφέρει από έργο σε έργο. Όπως και να έχει ορισμένες βασικές στήλες που θα έχει είναι: σύντομη περιγραφή του Requirement, από πού το αντλήσαμε, με ποιο deliverable σκοπεύουμε να το ικανοποιήσουμε κ.α.
Το Scope (Φυσικό Αντικείμενο) είναι οτιδήποτε θα κάνουμε – κατασκευάσουμε για να ικανοποιήσουμε τα Requirements και προκύπτει από την ανάλυση αυτών.
Παράδειγμα: Στο προηγούμενο έργο.
Για την ακρίβεια τα παραπάνω αποτελούν Product Scope γιατί στο τέλος του έργου αυτά θα παραδοθούν στον πελάτη. Το Product Scope περιγράφει τις λειτουργίες και τα τεχνικά χαρακτηριστικά, του τελικού προϊόντος καθώς και τις εργασίες, διαδικασίες, δράσεις που απαιτούνται για να υλοποιήσουμε τα Deliverables. Με απλά λόγια είναι μια περιγραφή του πως θα μοιάζει και ποιες θα είναι οι λειτουργίες του τελικού Output του έργου.
Αντίθετα οτιδήποτε άλλο κάνουμε στο έργο που θα μας βοηθήσει στην υλοποίηση του Product Scope αλλά στο τέλος ΔΕΝ θα παραδοθεί στον πελάτη είναι το Project Scope.
Παραδείγματα για Project Scope.
Στο παραπάνω παράδειγμα το Requirement ( συγκεκριμένα Risk Requirement) είναι “να μην βραχούν τα υλικά” . To Scope που θα ικανοποιήσει το Requirement είναι το “Υπόστεγο”. Και γιατί στο τέλος δεν θα παραδοθεί στον πελάτη, είναι Project Scope.
Στο παραπάνω παράδειγμα, το Requirement είναι η “αποτελεσματικότερη επικοινωνία”. Το Scope που θα ικανοποιήσει το Requirement είναι το “Communication Management Plan”. Και γιατί αυτό θα το συντάξουμε για να μας βοηθήσει κατά την διάρκεια εκτέλεσης του έργου και στο τέλος δεν θα παραδοθεί στον πελάτη, είναι Project Scope.
Συνοψίζοντας.
Όταν συζητάς με τους Stakeholder, με σκοπό να εκμαιεύεις τα Requirements σίγουρα δεν περιμένεις να ακούσεις μια αναλυτική περιγραφή του τι πρέπει να του παραδόσεις, και αυτό είναι και το επιδιωκόμενο. Από τον Stakeholder περιμένεις να ακούσεις την ανάγκη που θα πρέπει να του καλύψεις, με αυτό που θα του παραδόσεις στο τέλος του έργου. Επομένως το Requirement εξαρτάται αποκλειστικά από τον Stakeholder.
Ωστόσο η περιγραφή του φυσικού αντικειμένου (Product και Project Scope) εξαρτάται από τον Project Manager και την ομάδα του. Το Requirement είναι ένα, οι λύσεις (Product Scope) όμως μπορεί να είναι πολλές, και να διαφέρουν ανάλογα με τα Enterprise Environmental Factors, τα Organizational Process Assets, την εξειδίκευση της εταιρίας και του προσωπικού, τις γνώσεις τους πάνω στο Requirement κ.α.
Εν ολίγης κύριο μέλημα μας για την περιγραφή του Φυσικού Αντικειμένου (Product και Project Scope), είναι η αποτελεσματική συλλογή των Requirements. Τα Requirements είναι αυτά που θα μας καθοδηγήσουν στην περιγραφή ενός ολοκληρωμένου Φυσικού Αντικειμένου.
Βέβαια όλα τα παραπάνω μεταθέτουν την βαρύτητα στην εύρεση όλων των πηγών που θα μας υποδείξουν τα Requirement. Έτσι για παράδειγμα εάν δεν εντοπίσω έναν Stakeholder ή δεν λάβω υπόψιν ένα σημαντικό έγγραφο, δεν θα εκμαιεύσω ένα ή και παραπάνω Requirements γεγονός που θα οδηγήσει στην ελλείπει περιγραφή του Φυσικού Αντικειμένου.
MilEng, PMP®,PM2