(CAPM)® Prep Course


Ολοκληρώθηκε με επιτυχία άλλο ένα live πρόγραμμα προετοιμασίας για την πιστοποίηση (CAPM)® με εισηγητή τον Κυριακίδη Λάζαρο. Αυτήν την φορά τμήμα 14 ατόμων από τον MYTILINEOS S.A. είχαν την ευκαιρία να γνωρίσουν και να εμβαθύνουν στην επιστήμη της Διαχείρισης Έργου, και να εφοδιαστούν με χρήσιμα εργαλεία που θα τους ακολουθούν σε όλη τους την επαγγελματική ζωή. 

 

Επόμενο βήμα…. η εξέταση καλή επιτυχία σε όλους!

 

Business Case vs Project Charter

 

Δεν είναι λίγες οι φορές που τα δύο αυτά έγγραφα έχουν αποτελέσει αφορμή για ώρες συζητήσεων. Ορισμένοι μπορεί να θεωρούν ότι είναι τα ίδια με άλλο όνομα. Οι διαφορές τους ωστόσο είναι σαφείς και θα πρέπει να τις έχουμε στο μυαλό μας όταν τα συντάσσουμε.

Το παρών δεν έχει σκοπό να περιγράψει τα περιεχόμενα του καθενός, διότι αυτά μπορεί να ποικίλουν καθώς:

  • ο κάθε οργανισμός μπορεί να χρησιμοποιεί δικό του Template (OPA) για τα έγγραφα αυτά
  • ο καθένας ως Project Manager μπορεί, να κάνει tailoring στα έγγραφα προσθέτοντας ή αφαιρώντας τμήματα τους ανάλογα με το Project που έχει αναλάβει.

Ωστόσο για την καλύτερη κατανόηση τους θα περιγράψω κάποιους όρους που είναι σημαντικό να περιλαμβάνει το κάθε έγγραφο.

Για να καταλάβουμε το τι είναι το καθένα πρέπει πρώτα να κατανοήσουμε την διαφορά στον ΣΚΟΠΟ τους.

Business Case

Βρίσκεσαι σε έναν οργανισμό, και παρατηρείς ότι υπάρχει είτε ένα πρόβλημα σε αυτόν είτε ότι μια ανάγκη του πρέπει να καλυφθεί. Σκέφτεσαι μια ιδέα που θα μπορούσε να λύσει αυτό το πρόβλημα ή να καλύψει αυτήν την ανάγκη.

Ο σκοπός λοιπόν του Business Case είναι:

  • να περιγράψει το Problem – Need που εντόπισες
  • να πείσει την διοίκηση ότι αξίζει να δεσμεύσει πόρους ( χρήματα, μηχανήματα, προσωπικό για να καλύψει αυτό το ProblemNeed.

Προσοχή: Ακόμα δεν χρησιμοποιώ τον όρο Project γιατί ακόμα δεν υπάρχει Project.

 

 

 

  • Παράδειγμα: (Υποθετική Κατάσταση)

Ο οργανισμός που εργάζεσαι έχει ένα εργαστήρι. Παρατήρησες ότι υπάρχει ένα πρόβλημα το οποίο είναι ότι δεν χωράνε οι εργαζόμενοι.

            Η περιγραφή του προβλήματος, θα ήταν κάπως έτσι.

« Στο εργαστήρι υπάρχει συσσώρευση μεγάλου αριθμού προσωπικού και υλικών. Αυτό προκαλεί πρόβλημα στην εναποθήκευση των εργαλείων μας κάτι που δεν επιτρέπει την άμεση πρόσβαση μας σε αυτά. Παράλληλα δεν μπορούν να εργαστούν άνετα οι εργαζόμενοι μας, μειώνοντας την απόδοση τους και αυξάνοντας τις μεταξύ τους συγκρούσεις.»

Αφού έχεις περιγράψει το πρόβλημα που έχεις εντοπίσει θα εξηγήσεις το πως προτείνεις να λύσεις αυτό το πρόβλημα. Σίγουρα η λύση ενός προβλήματος δεν είναι μόνο μια και σε αυτό το σημείο μπορείς να γράψεις όσες περισσότερες πιστεύεις ότι θα επιλύσουν το πρόβλημα.

  • Παράδειγμα: (Υποθετική Κατάσταση)

            Για να λυθεί το παραπάνω πρόβλημα οι πιθανές εναλλακτικές λύσεις μπορεί να είναι οι παρακάτω:

  1. Να κατασκευάσουμε μια αποθήκη δίπλα από το εργαστήρι
  2. Να κατασκευάσουμε ντουλάπια και ράφια για την ευταξία του χώρου
  3. Να οργανώσουμε νυχτερινή βάρδια για να μην συγκεντρώνονται πολλά άτομα στο εργαστήρι

Τελειώνεις την περιγραφή των εναλλακτικών που προτείνεις και περνάς στο δεύτερο κομμάτι του ΣΚΟΠΟΥ του εγγράφου που είναι να Πείσεις την διοίκηση.

Να την πείσεις ότι αξίζει να λυθεί το πρόβλημα και όχι να ξεκινήσει το έργο. Για να το κάνεις αυτό θα εξηγήσεις ποιο θα είναι το όφελος, εάν θα λυθεί το πρόβλημα καθώς και ορισμένα οικονομικά μεγέθη.

  • Παράδειγμα (Υποθετική Κατάσταση)

 

  • Εάν λυθεί το πρόβλημα που σημαίνει ότι πλέον οι εργαζόμενοι χωράνε στο εργαστήρι τότε η αποδοτικότητα θα αυξηθεί κατά 15% ή οι συγκρούσεις θα μειωθούν κατά 20%, ή η παραγωγικότητα μας θα αυξηθεί κατά 30% κλπ.
  • Το εκτιμώμενο κόστος των προτεινόμενων λύσεων είναι 15.000 ευρώ, 5.000 ευρώ και 2.000 ευρώ αντίστοιχα.
  • Το εκτιμώμενο ROI είναι τον πρώτο χρόνο 6.000 ευρώ, τον δεύτερο χρόνο 7.000 ευρώ και τον τρίτο χρόνο 9.000 ευρώ.

Σε αυτό το σημείο μπορείς να περιγράψεις και άλλα σχετικά με την ιδέα σου όπως για παράδειγμα ένα TimeMap, κάποια Business Risks, ορισμένους βασικούς περιορισμούς κ.α.

Με την ολοκλήρωση της σύνταξης του εγγράφου, το έγγραφο θα παραδοθεί στην διοίκηση ή στο όργανο μέσα στην εταιρία που είναι υπεύθυνο για την λήψη αποφάσεων. Θα ελεγχθεί η σημαντικότητα του προβλήματος και εάν συμφέρει την διοίκηση να το λύσει σε σύγκριση με το όφελος που θα έχει.

Η διοίκηση μπορεί να απορρίψει, ή να εγκρίνει την υλοποίηση όλων ή μερικών από τις λύσεις που έχεις προτείνει.

Από την στιγμή που η διοίκηση αποφασίσει ότι αξίζει να λυθεί το πρόβλημα, ορισμένες από τις λύσεις που έχεις προτείνει, θα τις εντάξει σε ένα project. Αντίστοιχα κάποιες άλλες θα τις εντάξει σε ένα άλλο project κλπ.

Στην ουσία, με την έγκριση του Business Case γεννιέται το project και από εκείνη την στιγμή και μετά μπορούμε να συζητάμε για την ύπαρξη του. Πριν την έγκριση του απλώς υπάρχει ένα πρόβλημα και μια ιδέα για το πως θα το προσεγγίσουμε.  

Project Charter (Καταστατικό του έργου)

  • Παράδειγμα (Υποθετική Κατάσταση)

Η διοίκηση έχει εξετάσει το Business Case και έχει αποφασίσει ότι θα υλοποιήσουμε τις δύο από τις τρείς λύσεις που είχαμε προτείνει. ( Να κατασκευάσουμε μια αποθήκη δίπλα από το εργαστήρι, να κατασκευάσουμε ντουλάπια και ράφια για την ευταξία του χώρου).

 Η υλοποίηση αυτών των λύσεων αποτελεί ένα Project και η διοίκηση αναθέτει την υψηλή του εποπτεία στον Sponsor του έργου. Αυτό συμβαίνει γιατί η διοίκηση δεν μπορεί να έχει όλη την ώρα στο μυαλό της τι συμβαίνει σε κάθε έργο… γιατί δεν θα μπορεί να κάνει την δουλεία της ( που δεν είναι άλλη από τον Στρατηγικό της Σχεδιασμό) (δηλαδή το θέμα είναι πρακτικό). Έτσι τα έργα τα αναθέτει σε κάποιον από τους Sponsors που θα υπάρχουν στον οργανισμό.

Υπόλογος (Accountable) για την σύνταξη του Project Charter είναι ο Sponsor αλλά:

  1. Γιατί έχει στο μυαλό του την διεύθυνση όλων των έργων για τα οποία έχει αναλάβει την υψηλή εποπτεία
  2. Γιατί θέλει να βοηθήσει τον Project Manager (που θα επιλέξει για την υλοποίηση του έργου) να κατανοήσει σε βάθος το έργο που πρόκειται να αναλάβει,

 μεταβιβάζει το responsibility σύνταξης του Project Charter στον Project Manager.

Ο σκοπός ύπαρξης του Project Charter είναι να βοηθήσει τον Project ManagerSponsor να κατανοήσουν:

  • Το τι θα υλοποιήσουν στο έργο – ποιο είναι το Output
  • Το περιβάλλον που θα εργαστούν για την υλοποίηση του έργου

Το Project Charter λειτουργεί ακριβώς όπως μια εργασία που βάζει ένας καθηγητής πανεπιστημίου σε έναν μαθητή. Έχει σκοπό την καλύτερη – βαθύτερη κατανόηση του θέματος από τον Project Manager.

Με το Project Charter εξασφαλίζεις ότι τόσο εσύ σαν Project Manager όσο και ο Sponsor – Διοίκηση θα έχετε μια γενική εικόνα από διάφορες οπτικές γωνίες που θα περιγράφουν το έργο. Είναι ένα πρώτο επιδερμικό πέρασμα από τις βασικές του πτυχές που όμως εξασφαλίζουν ένα καλό ξεκίνημα στο έργο.

Γι’ αυτό  μέσα στο έγγραφο θα περιγράψω πληροφορίες όπως:

  • Project Description (π.χ. Το έργο αφορά την εξασφάλιση χώρου στο εργαστήρι, μέσω της κατασκευής μιας αποθήκης και ραφιών -ντουλαπιών στο εσωτερικό της για την βέλτιστη αξιοποίηση του υπάρχοντος χώρου)
  • Project Deliverables (π.χ. Η αποθήκη, Τα ράφια – ντουλάπια)
  • Project Key Risks
  • Project Key Constraints
  • Project Key Assumptions
  • Project Key Stakeholders

Τα περιεχόμενα του 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.
  • Δεν μπορούμε να συζητάμε για Project πριν την έγκριση του Business Case.
  • Το Project Charter γεννιέται – αντλεί πληροφορία από το Business Case, καθώς το τελευταίο ορίζει και την “κατεύθυνση” του έργου (κυρίως τα οφέλη της επίλυσης του προβλήματος που θα επιτευχθούν με την επίτευξη του έργου).
  • Το Business Case έχει σκοπό να πείσει την διοίκηση ότι αξίζει να ασχοληθούμε με ένα Problem – Need. Το Project Charter περιγράφει το Project που έχει επιλεχτεί για λύσει αυτό το Problem – Need

Προσοχή το έγγραφο δεν το κάνει το όνομα αλλά το περιεχόμενο. Μπορεί να νομίζουμε ότι συντάσσουμε ένα Business Case και στην πραγματικότητά να συντάσσουμε ένα Project Charter ή και το αντίστροφο.

Για να αποφύγουμε αυτό το μπέρδεμα και να συντάξουμε και τα δύο με τα περιεχόμενα και τα νοήματα που πρέπει να περιλαμβάνουν, οφείλουμε να κατανοήσουμε σε βάθος τον σκοπό τους – το WHY τους.

 

 

Lazaros Kiriakidis

MilEng, PMP®,PM2

 

Project Requirement Vs Product Scope Vs Project Scope

Απαιτήσεις έργου VS Φυσικό Αντικείμενο

 

Ποια είναι η Διαφορά μεταξύ του Requirement και του Scope (Product and Project scope);  

Σε μια πιο ελεύθερη μετάφραση και οι δύο όροι σχετίζονται με την περιγραφή του τί θα φτιάξουμε – κατασκευάσουμε κατά την διάρκεια του έργου και πως θα μοιάζει γενικά αυτό που θα πάρει ο πελάτης στα χέρια του στο τέλος,  είτε αυτό είναι μια υπηρεσία είτε ένα προϊόν. Ωστόσο οι δύο όροι δεν είναι επικαλυπτόμενοι και θα πρέπει να χρησιμοποιούνται στο έργο μας με την σωστή σημασία. 

Η βασική ιδέα είναι ότι πρώτα θα συλλέξω τα Requirements  (Collect Requirements) του έργου δηλαδή τις διάφορες απαιτήσεις που πρέπει να καλύψω με το έργο μου. Στην συνέχεια, αυτά θα μου υποδείξουν το πως θα διαμορφώσω το Φυσικό Αντικείμενο (Define Scope) του έργου, το οποίο θα ικανοποιήσει τις διάφορες αυτές απαιτήσεις.

 

Project Requirement. (Απαιτήσεις Έργου)

Έχεις ολοκληρώσει την αναγνώριση των Stakeholders καθώς και μια πρώτη ανάλυση τους για να καταλάβεις την δύναμη και το ενδιαφέρον τους στο έργο (Stakeholders Analysis). Επόμενο βήμα η εκμαίευση των Requirement.

Τα Requirements είναι οι ανάγκες – απαιτήσεις τις οποίες θα πρέπει να καλύψουμε με την ολοκλήρωση του έργου.

Παράδειγμα:  Για ένα έργο που είναι η κατασκευή μιας οικίας, διατυπώσεις requirements μπορεί να είναι οι παρακάτω. (Από την πλευρά του πελάτη)

  • Στην οικία θέλω να υπάρχει σύστημα θέρμανσης.
  • Στην οικία θέλω να υπάρχει χώρος για να παρκάρω τα δύο αμάξια της οικογένειας.

Οι δεξαμενές που μπορούμε να αντλήσουμε τα Requirements του έργου είναι:

  • Τα έγγραφα του έργου. (Documentation Analysis). Σημαντική είναι η ανάλυση – εξέταση των διαφόρων συμβάσεων (εάν είμαστε ανάδοχοι έργου), ή των συμβολαίων του έργου. Requirements βρίσκονται και στο Business Case καθώς και στο Project Charter.
  • Οι Stakeholders του έργου. Αυτοί μπορεί να είναι ο πελάτης, ο Sponsor, η ομάδα του έργου, η διοίκηση κλπ. Η εκμαίευση των requirements από αυτούς μπορεί να γίνει μέσω συνεντεύξεων (Open ending questions), brainstorming, ερωτηματολογίων κλπ.
  • Η παρατήρηση Observation. Για παράδειγμα η επιτόπου παρατήρηση της γραμμής παραγωγής ενός εργοστασίου θα μας αναδείξει τις διάφορες ανάγκες για βελτίωση της.

Τα Requirements τα καταγράφουμε σε ένα Requirement Traceability Matrix. Αποτελεί ένα Template και μπορεί να διαφέρει από έργο σε έργο. Όπως και να έχει ορισμένες βασικές στήλες που θα έχει είναι: σύντομη περιγραφή του Requirement,  από πού το αντλήσαμε, με ποιο deliverable σκοπεύουμε να το ικανοποιήσουμε κ.α.

 

Scope (Φυσικό Αντικείμενο) (Project Scope VS Product Scope)

Το Scope (Φυσικό Αντικείμενο) είναι οτιδήποτε θα κάνουμε – κατασκευάσουμε για να ικανοποιήσουμε τα Requirements και προκύπτει από την ανάλυση αυτών.

Παράδειγμα: Στο προηγούμενο έργο.

  • Για το Requirement “σύστημα θέρμανσης” το Scope μπορεί να είναι:
    • Καλοριφέρ
    • Ενδοδαπέδια Θέρμανση
    • Κλιματιστικό
  • Για το Requirement “να υπάρχει χώρος για να παρκάρω τα δύο αμάξια της οικογένειας ” το Scope μπορεί να είναι:
    • Πιλοτή
    • Γκαράζ
    • Υπόστεγο Parking

Για την ακρίβεια τα παραπάνω αποτελούν Product Scope γιατί στο τέλος του έργου αυτά θα παραδοθούν στον πελάτη. Το Product Scope περιγράφει τις λειτουργίες και τα τεχνικά χαρακτηριστικά, του τελικού προϊόντος καθώς και τις εργασίες, διαδικασίες, δράσεις που απαιτούνται για να υλοποιήσουμε τα Deliverables. Με απλά λόγια είναι μια περιγραφή του πως θα μοιάζει και ποιες θα είναι οι λειτουργίες του τελικού Output του έργου.

Αντίθετα οτιδήποτε άλλο κάνουμε στο έργο που θα μας βοηθήσει στην υλοποίηση του Product Scope αλλά στο τέλος ΔΕΝ θα παραδοθεί στον πελάτη είναι το Project Scope.

Παραδείγματα για Project Scope.

  1. Για να μην βραχούν τα υλικά που θα χρησιμοποιήσω στο έργο μου θα κατασκευάσω ένα υπόστεγο

Στο παραπάνω παράδειγμα το Requirement ( συγκεκριμένα Risk Requirement) είναι “να μην βραχούν τα υλικά” . To Scope που θα ικανοποιήσει το Requirement είναι το “Υπόστεγο”.  Και γιατί στο τέλος δεν θα παραδοθεί στον πελάτη, είναι Project Scope.

  1. Για την αποτελεσματικότερη επικοινωνία με τους Stakeholders του έργου θα συντάξω με την ομάδα μου ένα Communication Management Plan.

Στο παραπάνω παράδειγμα, το 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 κ.α.

  • Στο προηγούμενο παράδειγμα με το “σύστημα θέρμανσης στην οικία”, κάποιος project manager θα ικανοποιούσε αυτό το Requirement με την τοποθέτηση καλοριφέρ, ενώ ένας άλλος με ενδοδαπέδια θέρμανση.
  • Αντίστοιχα στο παράδειγμα “Για να μην βραχούν τα υλικά που θα χρησιμοποιήσω στο έργο μου θα κατασκευάσω ένα υπόστεγο”, ένας Project Manager θα μπορούσε όντως να κατασκευάσει ένα υπόστεγο, ενώ ένας άλλος θα μπορούσε να αγοράσει ένα νάιλον για να τα σκεπάσει. ( Το Requirement είναι να μην βραχούν τα υλικά και το Project Scope είναι το υπόστεγο ή η αγορά νάιλον ) ( Στο συγκεκριμένο μάλιστα παράδειγμα φαίνεται ότι το project scope που θα επιλέξω εξαρτάται και από το Risk Response Strategy που θα εφαρμόσω, κάτι που είναι άρρηκτα συνδεδεμένο και με την ανοχή του ρίσκου στην εταιρία (EEF))

Εν ολίγης κύριο μέλημα μας για την περιγραφή του Φυσικού Αντικειμένου (Product και Project Scope), είναι η αποτελεσματική συλλογή των Requirements. Τα Requirements είναι αυτά που θα μας καθοδηγήσουν στην περιγραφή ενός ολοκληρωμένου Φυσικού Αντικειμένου.

Βέβαια όλα τα παραπάνω μεταθέτουν την βαρύτητα στην εύρεση όλων των πηγών  που θα μας υποδείξουν τα Requirement. Έτσι για παράδειγμα εάν δεν εντοπίσω έναν Stakeholder ή δεν λάβω υπόψιν ένα σημαντικό έγγραφο, δεν θα εκμαιεύσω ένα ή και παραπάνω Requirements γεγονός που θα οδηγήσει στην ελλείπει περιγραφή του Φυσικού Αντικειμένου.

 

 

Lazaros Kiriakidis

MilEng, PMP®,PM2