5 คุณสมบัติที่ขาดไม่ได้ของผู้จัดการโครงการชั้นนำ

ฟังเวอร์ชั่นเสียงของบทความนี้

การเป็น PM อันดับต้นๆ จะทำให้คุณโดดเด่น และหากคุณถูกมองว่าเป็น PM อันดับต้นๆ คุณก็จะเป็นที่ต้องการสูง ผู้มีส่วนได้ส่วนเสียจะไว้วางใจคุณมากขึ้น พวกเขาต้องการทำงานร่วมกับคุณ และพวกเขาจะฟังคำแนะนำของคุณมากขึ้น ไม่ว่าคุณจะช่วยสร้างอะไร นายกรัฐมนตรีระดับสูงมักเป็นที่ต้องการในองค์กรทั่วโลก นี่คือรายการคุณสมบัติที่สำคัญบางประการของผู้จัดการโครงการชั้นนำ หวังว่ามันจะช่วยให้คุณกลายเป็นหนึ่งหรือตรวจสอบว่าคุณมีนิสัยเหล่านี้อยู่แล้วหรือไม่

1. การสร้างความไว้วางใจภายในทีมของคุณ

ความไว้วางใจเป็นสิ่งสำคัญของทุกทีม มีการพูดคุยและเขียนบ่อยครั้ง แต่ไม่ค่อยเห็นในทางปฏิบัติเมื่อพูดถึงการดำเนินโครงการ ความสำคัญของความไว้วางใจในกระบวนการจัดการโครงการได้รับการยอมรับจากองค์กรการจัดการโครงการต่างๆ

สมาคมการจัดการโครงการระหว่างประเทศได้รวมเฉพาะหัวข้อเกี่ยวกับความไว้วางใจในการรับรอง ICB4 ซึ่งเป็นมาตรฐานสากลสำหรับความสามารถส่วนบุคคลในด้านการจัดการโครงการ โปรแกรม และพอร์ตโฟลิโอ

ในทำนองเดียวกัน Three Pillars of Empiricism ของ Scrum มีพื้นฐานมาจากแนวคิดที่ว่าความไว้วางใจเป็นหนึ่งในสามปัจจัยที่สำคัญที่สุดในการรักษาการควบคุมโครงการเชิงประจักษ์ แนวโน้มเดียวกันของการสร้างความไว้วางใจมีอยู่ใน LEAN และวิธีการจัดการโครงการแบบเดิมอื่นๆ หากหัวข้อนี้เป็นหัวข้อเร่งด่วนมานานแล้ว อะไรคือตัวบล็อกหลักที่ขัดขวางไม่ให้ PM สร้างความไว้วางใจที่แท้จริงภายในทีมของพวกเขา

หนึ่งในคำตอบที่เกิดซ้ำมากที่สุดสำหรับคำถามนี้คือ "ตำหนิวัฒนธรรม" กุญแจสำคัญในการบรรลุวัฒนธรรมความไว้วางใจคือการอพยพออกจากวัฒนธรรมนี้และเปลี่ยนทุกความผิดพลาดให้เป็นโอกาสในการเรียนรู้แทน

เพื่อให้สิ่งนี้เป็นจริง PMs ควรอำนวยความสะดวกในสภาพแวดล้อมที่เหมาะสมของความโปร่งใสและความสะดวกสบายภายในทีมของพวกเขา เนื่องจากคนส่วนใหญ่ทำงานได้ดีขึ้นมากในสภาพแวดล้อมที่สมาชิกในทีมสามารถแสดงออกและทำผิดพลาดได้

นายกรัฐมนตรีระดับสูงจะสอนหลักการเหล่านี้ให้กับทีมโดยเป็นแบบอย่างโดยอยู่ร่วมกับพวกเขา ส่งเสริมให้แบ่งปันความผิดพลาด และเปลี่ยนให้เป็นตัวอย่างสำหรับการเรียนรู้ นายกรัฐมนตรีระดับสูงตระหนักดีว่าการแสดงความอ่อนน้อมถ่อมตนและความอ่อนแอเป็นสัญญาณของความแข็งแกร่ง โดยเฉพาะอย่างยิ่งเมื่อพูดถึงการยอมรับความผิดพลาดของตัวเอง ผู้คนมักจะกลายเป็นฝ่ายรับหรือเปลี่ยนโทษ อธิบายว่าคุณทำผิดและ ทำไมถึง ทำให้คุณรู้สึกอ่อนแอ แต่ถ้าคุณยอมรับและวิเคราะห์ข้อผิดพลาดเหล่านี้อย่างเปิดเผย นิสัยนี้จะช่วยให้คนอื่นหลีกเลี่ยงได้ในอนาคตและจะช่วยให้ทุกคนสร้างความไว้วางใจและเปิดใจเกี่ยวกับความผิดพลาดของพวกเขา . ตัวอย่างเช่น หากคุณให้คำมั่นสัญญากับผู้มีส่วนได้ส่วนเสียหลักที่จะทำเป้าหมายให้เสร็จเร็วกว่าที่เป็นได้ เนื่องจากขาดความเชี่ยวชาญทางเทคนิคที่คุณมีในหัวข้อนั้น ยอมรับความผิดพลาดของคุณกับทีม และให้พวกเขารู้ว่าคุณประเมินค่าผิดไปแทนที่จะโทษ เพราะไม่ได้ส่งมอบเทคโนโลยีเร็วเท่าที่คุณต้องการ สิ่งนี้สามารถสร้างแรงบันดาลใจให้ผู้อื่นเปิดใจและสร้างความสัมพันธ์ที่แน่นแฟ้นกับคุณและเพื่อนร่วมทีมของพวกเขา

ทำความเข้าใจสมาชิกในทีมของคุณ: ความสามารถ ความกลัว ความผิดหวัง สิ่งที่พวกเขาชอบหรือไม่ชอบ และวิธีที่พวกเขามีปฏิสัมพันธ์กับผู้อื่น เมื่อสมาชิกในทีมรู้สึกว่าตนเองมีค่า พวกเขาจะส่งมอบคุณค่าได้ง่ายขึ้น หาวิธีจูงใจทีมของคุณด้วยงานที่ทำอยู่แทนที่จะผลักดันพวกเขาไปสู่วัตถุประสงค์ของคุณ ในการดำเนินการดังกล่าว ให้ร่างโครงร่างที่ชัดเจนว่าความสำเร็จของโครงการและบทบาทและความรับผิดชอบของทีมโครงการและโครงการเป็นอย่างไร แต่จากนั้นให้พวกเขาเป็นผู้เชี่ยวชาญในสาขาของตน คาดหวังให้สมาชิกในทีมบอกคุณว่าต้องทำอะไร รับฟังพวกเขา กระจายอำนาจการตัดสินใจเพื่อเพิ่มพลังให้ทีมของคุณ แต่เตรียมพร้อมสำหรับการตัดสินใจที่ยากลำบากเมื่อจำเป็น

ท้ายที่สุดแล้ว ทีมของคุณก็พร้อมให้คุณมีส่วนร่วมด้วย PM จำนวนมากเกินไปทำผิดพลาดในการเขียนงานโดยตรงและรับความรับผิดชอบนั้นมากเกินไป บางครั้งสิ่งนี้เกิดขึ้นเนื่องจากขาดความไว้วางใจและความเข้าใจภายในทีมเหล่านั้น เมื่อคุณได้รับความไว้วางใจจากทีมของคุณ ให้ตรวจสอบให้แน่ใจว่าพวกเขามีส่วนร่วมในการกำหนดขอบเขตงาน เขียนเรื่องราวของผู้ใช้ และโดยทั่วไปให้คำแนะนำเกี่ยวกับเรื่องที่พวกเขารู้สึกว่ามีความสำคัญ

นายกรัฐมนตรีระดับสูงตระหนักดีว่าทีมของพวกเขาคือทรัพย์สินที่ดีที่สุด และจะใช้โอกาสแต่ละอย่างเพื่อสร้างความสัมพันธ์ที่แน่นแฟ้นกับพวกเขา เป็นนักเจรจาและอำนวยความสะดวก แต่ก่อนสิ่งอื่นใด จงเป็นหนึ่งเดียวกับทีม พวกเขาต้องรู้สึกราวกับว่าคุณกำลังทำงานกับพวกเขาและไม่ใช่เพื่อคนข้างบน นี่เป็นสารตั้งต้นของเคล็ดลับทางเทคนิคเพิ่มเติมในบทความนี้ เนื่องจากหากไม่มีความไว้วางใจ โครงการของคุณอาจประสบปัญหาหลายอย่าง

ประเด็นสำคัญ: “ไม่เป็นไรที่จะแสดงให้เห็นว่าทุกคนทำผิดพลาด แบ่งปันความผิดพลาดของคุณเมื่อคุณสร้างมันขึ้นมา แสดงให้ทีมของคุณเห็นว่าคุณอยู่เคียงข้างพวกเขา และทำให้ความไว้วางใจภายในทีมของคุณมีความสำคัญเป็นอันดับหนึ่ง”

2. ชักชวนให้ผู้มีส่วนได้ส่วนเสียของคุณได้รับสิ่งที่พวกเขาต้องการจริงๆ

ในฐานะ PM คุณอาจตระหนักดีถึงความจริงที่ว่าโครงการซอฟต์แวร์จำนวนมากจบลงด้วยการส่งมอบอย่างอื่นที่ไม่ใช่สิ่งที่ผู้มีส่วนได้ส่วนเสียต้องการหรือจำเป็น ปัญหานี้เกิดจากปัจจัยต่างๆ มากมาย และทำให้เกิดวิธีการใหม่ทั้งชุดที่พยายามแก้ปัญหานี้

อย่างไรก็ตาม แม้ในยุคของการพัฒนาแบบ Agile บางครั้งเราก็ยังตกหลุมพรางของการสร้างสิ่งผิดๆ การวิเคราะห์ผู้มีส่วนได้ส่วนเสียมีความสำคัญแต่มักเริ่มต้นด้วยคำถามที่ผิด โดยไม่ต้องถามคำถามว่า “ทำไมเราถึงทำเช่นนี้” หลายโครงการเริ่มต้นและกำหนดไม่ถูกต้อง ตกหลุมพรางของการสร้างไปสู่โซลูชันที่ไม่เคยตอบสนองความต้องการทางธุรกิจที่แท้จริง

ร่วมกับ "ทำไม" นายกรัฐมนตรีระดับสูงต้องถามติดตามว่า "เพื่อใคร" เราสนับสนุนผู้มีส่วนได้ส่วนเสียรายใดเพื่อนำเสนอโซลูชันเพื่อให้ครอบคลุม "ทำไม" ของพวกเขา

นี่คือจุดที่นายกรัฐมนตรีเห็นความแตกต่างที่สำคัญ โซลูชันสามารถกำหนดเป็นผลลัพธ์หรือสิ่งที่ส่งมอบได้ แต่ PM อันดับต้น ๆ เข้าใจว่าโซลูชันใด ๆ ไม่จำเป็นต้องครอบคลุมความต้องการทางธุรกิจดั้งเดิม ตัวอย่างเช่น หากผู้มีส่วนได้ส่วนเสียคิดว่าความต้องการทางธุรกิจของพวกเขาคือการนำระบบ ERP มาใช้ PM ก็ต้องช่วยพวกเขาให้ค้นพบความต้องการที่แท้จริงของธุรกิจที่อยู่เบื้องหลังโดยใช้โซลูชัน เช่น ERP ERP เป็นโซลูชัน ไม่ใช่ความต้องการทางธุรกิจ

การตระหนักถึงความต้องการทางธุรกิจที่แท้จริงจำเป็นต้องมีความเข้าใจอย่างลึกซึ้งในบริบทและผู้มีส่วนได้ส่วนเสีย ทัศนคติ ระดับอำนาจหรืออิทธิพล ระดับความสนใจ ผลกระทบที่มีต่อโครงการ ผลกระทบของโครงการที่มีต่อพวกเขา ข้อกังวลของพวกเขา และแน่นอน สิ่งที่พวกเขาจะยอมรับ ความสำเร็จของโครงการ

ดังนั้น เพื่อให้โครงการประสบความสำเร็จมากขึ้นในการบรรลุวัตถุประสงค์﹣การสร้างโซลูชันที่ส่งผลกระทบต่อเป้าหมายทางธุรกิจ﹣ความรับผิดชอบของผู้จัดการโครงการขยายผ่านการสร้างโซลูชันเอง ไปยังที่ที่โซลูชันดำเนินไป ในการวัดอย่างชัดเจนว่ามูลค่าที่ผลิตจริงนั้นสอดคล้องกับวัตถุประสงค์ที่คาดหวังหรือไม่ ในคำจำกัดความของเป้าหมาย

PMs ควรระลึกไว้เสมอว่าผลประโยชน์ที่แท้จริงของการส่งมอบโครงการตลอดกระบวนการทั้งหมดจะต้องสอดคล้องกับความต้องการ เป้าหมาย และวัตถุประสงค์ทางธุรกิจที่แท้จริง

บ่อยครั้งที่ลืมเป้าหมายทางธุรกิจท่ามกลางการเปลี่ยนแปลงของการพัฒนาและความต้องการ บ่อยครั้งที่โปรเจ็กต์จบลงด้วยการส่งมอบผลิตภัณฑ์ที่ใช้งานได้จริง ซึ่งแก้ปัญหาบางอย่าง แต่ไม่ใช่ความต้องการทางธุรกิจที่แท้จริงทั้งหมดที่กระตุ้นการพัฒนาผลิตภัณฑ์ตั้งแต่แรก สิ่งนี้สามารถป้องกันได้หากผู้มีส่วนได้ส่วนเสียได้รับการจัดการอย่างถูกต้องและนำเสนอด้วยการทำซ้ำผลิตภัณฑ์บ่อยครั้ง

นายกรัฐมนตรีระดับสูงยังตระหนักถึงบทบาทของตนในการเป็นผู้นำโครงการ ดังนั้นจึงไม่คาดหวังให้ผู้มีส่วนได้ส่วนเสียแจ้งข้อกำหนดทั้งหมดตั้งแต่เริ่มโครงการ พวกเขาเข้าใจดีว่าผู้มีส่วนได้ส่วนเสียบางรายไม่ทราบวิธีการระบุความต้องการของตนเสมอไป และบทบาทของพวกเขาคือการช่วยให้ผู้มีส่วนได้ส่วนเสียระบุความต้องการของตนได้ชัดเจน ตั้งแต่การกำหนดข้อกำหนด ไปจนถึงการส่งมอบโครงการ สิ่งสำคัญที่ต้องจำไว้คือ ในระหว่างกระบวนการแสดงข้อกำหนด เราต้องดึงข้อกำหนดไม่เฉพาะจากผู้มีส่วนได้ส่วนเสียเท่านั้น แต่ยังต้องคำนึงถึงข้อกังวลของพวกเขาด้วย

ตัวอย่างเช่น ในองค์กรที่ยังไม่บรรลุนิติภาวะ ความขัดแย้งที่น่าสนใจมักเกิดขึ้นในช่วงเริ่มต้นของโครงการใหม่ ในระหว่างขั้นตอนการเริ่มต้นโครงการ ทีมพัฒนาคาดหวังให้ผู้มีส่วนได้ส่วนเสียระบุข้อกำหนดและความต้องการทั้งหมดสำหรับโซลูชันที่จะพัฒนาอย่างชัดเจน ในเวลาเดียวกัน ผู้มีส่วนได้ส่วนเสียคาดหวังว่าทีมจัดส่งจะให้การประมาณการที่ถูกต้องแม่นยำทั้งในเวลาและต้นทุน

อย่างไรก็ตาม ในช่วงเริ่มต้นของการกำหนดขอบเขตโครงการ มีความไม่แน่นอนมากเกินไปที่จะระบุการประมาณการเหล่านี้ และในการทำเช่นนั้น อาจมีอันตรายในการสร้างการประมาณที่ไม่สมจริง ในบางครั้ง ผู้มีส่วนได้ส่วนเสียใส่ข้อกำหนดให้มากที่สุดเท่าที่จะเป็นไปได้ เพื่อรองรับความไม่แน่นอนของโซลูชันที่จับต้องได้น้อยกว่าในปัจจุบัน ในขณะเดียวกัน ทีมจัดส่งให้การประมาณการคร่าวๆ สำหรับสิ่งที่ไม่ทราบ

ผลลัพธ์นี้น่าจะเป็นโซลูชันที่จะได้รับเพียง 20% ของข้อกำหนดทั้งหมดที่ใช้โดยผู้มีส่วนได้ส่วนเสีย ส่วนที่เหลือจะได้รับการพัฒนาโดยไม่มีเป้าหมายที่ชัดเจนในการทำให้โครงการใช้งบประมาณเกินและเกินกำหนดเวลา

โชคดีที่ PM ระดับสูงรู้วิธีดึงดูดผู้มีส่วนได้ส่วนเสียอย่างแม่นยำและแนะนำพวกเขาผ่านแต่ละขั้นตอนของโลก VUCA (ความผันผวน ความไม่แน่นอน ความซับซ้อน และความคลุมเครือ) ของโครงการของพวกเขา ผู้จัดการโครงการสามารถแบ่งโครงการออกเป็นส่วนที่จับต้องได้มากขึ้นและมีส่วนร่วมกับผู้มีส่วนได้ส่วนเสียในขณะเดียวกันก็สร้างและทบทวนการเรียนรู้ตลอด

ประเด็นสำคัญที่นี่คือ: “โซลูชันถูกสร้างขึ้นเพื่อแก้ไขความต้องการทางธุรกิจ PMs จำเป็นต้องทำให้แน่ใจว่าจะไม่พลาดเป้าหมายนี้เมื่อสร้างโครงการ ตรวจสอบให้แน่ใจว่าผู้มีส่วนได้ส่วนเสียของคุณต้องการสร้างสิ่งที่ถูกต้อง โดยมีส่วนร่วมกับพวกเขาเพื่อจัดการกับความต้องการและข้อกังวลหลักของพวกเขา”

3. ทำให้การบริหารความเสี่ยงของโครงการเป็นแบบฝึกอินทรีย์

โครงการส่วนใหญ่มีชุดของความเสี่ยงทั่วไปที่เกิดขึ้นในช่วงเริ่มต้นของการเริ่มต้นโครงการ

เกือบทุกโครงการเริ่มต้นด้วยความเสี่ยงทั่วไปเหล่านี้ รวมถึงการต่อต้านการเปลี่ยนแปลงของผู้ใช้ การขาดทรัพยากร และเทคโนโลยีที่ยังไม่บรรลุนิติภาวะ เป็นต้น PM ชั้นนำมีส่วนร่วมกับทีมของพวกเขาเพื่อระบุความเสี่ยงที่ไม่เฉพาะเจาะจงเท่านั้น แต่ยังรวมถึงความเสี่ยงที่เร่งด่วนที่สุดและเฉพาะเจาะจงด้วย เช่น การระบุความเสี่ยงที่สะท้อนออกมาตลอดวงจรชีวิตของโครงการ ไม่ใช่งานธรรมดาในช่วงเริ่มต้นของโครงการ

ในการตระหนักถึงความเสี่ยง PM ระดับสูงยังมองหาความร่วมมือกับผู้มีส่วนได้ส่วนเสียหลัก ซึ่งมักจะกำหนดความเสี่ยงอย่างชัดแจ้งหรือโดยปริยายในข้อกำหนดและข้อกังวลของพวกเขา PM ที่ดีเข้าใจดีว่ากระบวนการนี้เกิดขึ้นจากขั้นตอนการแสดงความต้องการไปจนถึงวงจรชีวิตของโครงการทั้งหมด และถือเป็นสินทรัพย์ในการกำหนดความเสี่ยงตลอดกระบวนการ

PM ผู้เชี่ยวชาญยังเชื่อมั่นในทีมของตนและรับรู้ถึงความรู้ของผู้เชี่ยวชาญในฐานะแหล่งที่มาของการลดความเสี่ยง เพื่อให้สมาชิกในทีมสามารถระบุความเสี่ยงในเชิงรุก PM ให้อำนาจทีมของพวกเขาในการเป็นเจ้าของโครงการและมีส่วนร่วมในการระบุความเสี่ยงและการจัดการ

ในทางปฏิบัติ คำถามที่สามระหว่างสแตนด์อัพประจำวัน "อะไรเป็นอุปสรรคต่อคุณ" สะท้อนถึงการตอบสนองที่รอบคอบมากขึ้นเมื่อทีมได้รับอำนาจในการมีส่วนร่วมในความสำเร็จของโครงการ แน่นอน ตัวบล็อกบางตัวอาจถูกระงับชั่วคราวหรือถูกลบออกทันทีหลังจากการต่อสู้ อย่างไรก็ตาม ตัวบล็อกบางส่วนอาจเป็นตัวเลือกที่อาจมีความเสี่ยงสูง สมาชิกในทีมต้องได้รับการสนับสนุนให้ระบุความเสี่ยงที่อาจเกิดขึ้นเหล่านี้ และควรยกย่องให้มีการผนวกรวมเข้าด้วยกัน แทนที่จะดูถูกแม้กระทั่งเมื่อสิ้นสุดวงจรชีวิตโครงการ

การรับรู้ความเสี่ยงนั้นไม่ง่ายเหมือนการระบุความเสี่ยงและดำเนินการต่อไป การรับรู้ความเสี่ยงควรได้รับการประเมินอย่างสม่ำเสมอ ในแง่ของความน่าจะเป็น ความรุนแรง และตัวชี้วัดที่บางครั้งอาจลืม: ความใกล้ชิด เมตริกหลังช่วยให้ทีมสามารถกำหนดรายการการดำเนินการที่ถูกต้อง ไม่ว่าจะเป็น "ไม่ทำอะไรเลยจนกว่าจะถึงขั้นตอนการรับรู้ความเสี่ยงถัดไป" หรือสิ่งที่จับต้องได้มากกว่านี้หากความเสี่ยงอยู่ใกล้มากขึ้น สิ่งสำคัญที่ต้องตระหนักในที่นี้คือ PM ระดับสูงเข้าใจวิธีทำให้ความเสี่ยงสามารถดำเนินการได้ เนื่องจากความเสี่ยงใดๆ จะไม่มีประโยชน์หากไม่มีการจัดการ นอกจากนี้ รายการของการดำเนินการไม่ควรเป็นเชิงรับเท่านั้น แต่ยังมีลักษณะเชิงรุกในท้ายที่สุด เพื่อแจ้ง Backlog ของผลิตภัณฑ์ที่ปรับความเสี่ยงในท้ายที่สุด

กล่าวโดยสรุป PM ระดับสูงตระหนักดีว่าโดยไม่คำนึงถึงประสบการณ์หรืออำนาจ พวกเขาไม่ใช่และไม่ควรเป็นแหล่งเดียวสำหรับการรับรู้และการจัดการความเสี่ยง ผู้มีส่วนได้ส่วนเสีย ทีมงาน และผู้มีส่วนร่วมในโครงการที่สำคัญอื่นๆ ควรมีส่วนร่วมในการรับรู้ความเสี่ยงและการจัดการ ไม่เพียงแต่ในระยะแรกเท่านั้น แต่ยังรวมถึงอย่างสม่ำเสมอตลอดวงจรชีวิตของโครงการด้วย นี่เป็นสิ่งสำคัญเนื่องจากมีความเสี่ยงน้อยมากที่ได้ระบุไว้ในตอนเริ่มต้นของโครงการ แต่ยังไม่ได้รับการจัดการตั้งแต่นั้นเป็นต้นมา

ประเด็นสำคัญที่นี่คือ: “เพื่อให้บรรลุการจัดการโครงการที่ประสบความสำเร็จ ทั้งทีมควรรับผิดชอบในการระบุความเสี่ยง การค้นพบความเสี่ยงจะต้องเป็นกระบวนการต่อเนื่องที่เกิดขึ้นตลอดอายุของโครงการ”

4. เข้าใจสิ่งแวดล้อม

นายกรัฐมนตรีระดับสูงไม่ควรเริ่มโครงการเหมือนกระทิงในร้านค้าจีน แทนที่จะบังคับวิธีการหรือแนวทางโครงการ ผู้จัดการโครงการควรทำการวิเคราะห์เชิงลึกเกี่ยวกับสภาพแวดล้อม โครงสร้างที่เป็นทางการ โครงสร้างที่ไม่เป็นทางการ วัฒนธรรม นิสัย เครื่องมือ ความสามารถ และทรัพย์สินขององค์กรที่อยู่ในมือ จากนั้นเขาก็สามารถเริ่มต้นการเดินทางแห่งการเปลี่ยนแปลงได้

แม้ว่า PM ทุกคนจะเข้าใจดีว่าโครงการที่พวกเขากำลังดำเนินการจะมีผลกระทบต่อองค์กร แต่ PM ระดับสูงตระหนักดีว่าองค์กรก็มีผลกระทบต่อโครงการเช่นเดียวกัน

แทนที่จะมีข้อบกพร่อง ความคิดที่มีขนาดเดียว นายกรัฐมนตรีระดับสูงได้ปรับแนวทางของตนโดยทำความเข้าใจสภาพแวดล้อมของตน ในการทำเช่นนั้น พวกเขาสามารถรับรู้ความต้องการทางธุรกิจที่เร่งด่วนที่สุดได้ดีขึ้น วิธีที่องค์กรจะปรับตัวหรือยอมรับโซลูชัน การนำไปใช้ และการเปลี่ยนแปลงใดที่จะเกิดขึ้นกับโซลูชันเพื่อให้บรรลุวัตถุประสงค์ที่เหมาะสม

ในขณะที่ปรับแต่งแนวทางการจัดการโครงการที่มีประสิทธิภาพ PM ระดับสูงต้องมีความเข้าใจในเชิงลึกเกี่ยวกับวิธีการต่างๆ ไม่เพียงแต่แนวทาง PM ที่แตกต่างกันเท่านั้น แต่ยังรวมถึงวิธีการวิเคราะห์ธุรกิจ กรอบการจัดการการเปลี่ยนแปลง กรอบโครงสร้างสถาปัตยกรรมองค์กร และวิธีการวิเคราะห์ที่มีประโยชน์อื่นๆ สิ่งนี้ทำให้ PM สามารถค้นหาโซลูชันที่เหมาะสมที่สุดสำหรับบริษัทที่อยู่ในมือเพื่อส่งมอบโครงการที่พวกเขากำลังดำเนินการอยู่

ตัวอย่างเช่น หากคุณกำลังเริ่มต้นโครงการในองค์กรที่มีลำดับชั้นที่เข้มงวดอย่างยิ่ง ซึ่งมีระดับการอนุมัติที่แตกต่างกันมากมาย วิธีที่ดีที่สุดอาจเป็นวิธีการจัดการโครงการแบบผสมผสานหรือแบบผสม คุณอาจดำเนินการตามขั้นตอนการกำหนดข้อกำหนดที่มีโครงสร้าง โดยต้องอนุมัติข้อกำหนดล่วงหน้า จากนั้นจึงแบ่งโครงการออกเป็นขั้นตอนด้วยประตูเวทีที่เป็นทางการ ในขณะเดียวกัน PM สามารถตั้งค่าการดำเนินการซ้ำแบบ Agile ภายในทีมพัฒนาเพื่อรวบรวมแนวทางปฏิบัติที่ดีที่สุดของการพัฒนาแบบวนซ้ำ แม้จะดำเนินโครงการแบบเดิมๆ

โดยสรุป PM ระดับสูงจะเคารพวัฒนธรรมของบริษัท ในขณะที่เสนอแนวทางใหม่ ๆ และแนะนำองค์กรด้วยความเคารพในการปรับปรุงแนวทางการจัดการโครงการของพวกเขา พวกเขาตระหนักดีว่าหลายองค์กรมีวุฒิภาวะและความพร้อมสำหรับการเปลี่ยนแปลงที่แตกต่างกัน และมองว่านี่เป็นโอกาสมากกว่าที่จะเป็นภัยคุกคามที่จะส่งผลกระทบในทางบวกต่อความสามารถของแต่ละบริษัทในการดำเนินการตามแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการโครงการ

ประเด็นสำคัญที่นี่คือ: “ผู้จัดการโครงการไม่ควรผลักดันวาระของตนเองอย่างสุ่มสี่สุ่มห้า แต่ควรปรับให้เข้ากับวิธีการทำงานขององค์กร และดำเนินการเปลี่ยนแปลงอย่างช้าๆ หากจำเป็น”

5. การใช้หลักการ LEAN

นายกรัฐมนตรีระดับสูงรู้ว่าการเดินทางมีความสำคัญพอๆ กับเป้าหมาย บางครั้ง การเดินทางของโครงการมีความยุ่งยากเป็นพิเศษโดยกระบวนการที่กำหนดว่าควรทำอย่างไร ซึ่งอาจอยู่ในเทมเพลตที่มีน้ำหนักเกินความจำเป็น การประชุมที่ไร้จุดหมาย หรืออุปกรณ์ต่อพ่วงที่รบกวนสมาธิซึ่งเป็นอุปสรรคต่อการเดินทาง แต่เป็นความรับผิดชอบของคุณในฐานะ PM ที่จะต้องแน่ใจว่าอุปสรรคเหล่านี้ส่งผลกระทบต่อทีมของคุณให้น้อยที่สุด

PM ระดับสูงควรระบุกระบวนการที่มีประสิทธิภาพและประสิทธิผลมากขึ้นสำหรับทีม โดยใช้หลักการจัดการโครงการที่คล่องตัว ซึ่งกำหนดไว้อย่างดีในระเบียบวิธีแบบ LEAN

ความเข้าใจผิดที่ได้รับความนิยมคือ LEAN เหมาะสำหรับการผลิตเท่านั้น ซึ่งไม่เป็นความจริง วิธีการจัดการโครงการ LEAN สามารถปรับปรุงทุกโครงการและทุกกระบวนการ มันไม่ได้เป็นเพียงโปรแกรมลดต้นทุน แต่เป็นวิธีคิดและดำเนินการสำหรับทีมของคุณ

ประโยชน์ของการใช้หลักการ LEAN นั้นสรุปไว้อย่างดีโดยคำพูดของ Katsuaki Watanabe CEO ของ Toyota: “การจัดการกระบวนการที่ยอดเยี่ยมคือกลยุทธ์ของเรา เราได้รับผลลัพธ์ที่ยอดเยี่ยมจาก คนทั่วไปที่จัดการกระบวนการที่ยอดเยี่ยม เราสังเกตว่าคู่แข่งของเรามักจะได้ผลลัพธ์โดยเฉลี่ย (หรือแย่กว่านั้น) จาก บุคลากรที่เก่งกาจในการจัดการกระบวนการที่ผิดพลาด”

นายกรัฐมนตรีระดับสูงที่มีอคติในการกำจัดเสียงรบกวนและงานที่ไม่จำเป็นของโครงการจะขับเคลื่อนกระบวนการไปสู่หลักการ LEAN โดยธรรมชาติ PM ระดับสูงควรทำงานอย่างใกล้ชิดกับเจ้าของผลิตภัณฑ์ ทีมงาน และผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องเพื่อช่วยให้พวกเขาปรับปรุงและระบุความต้องการและมูลค่าที่คาดหวังไว้เพื่อตอบสนองต่อความต้องการเหล่านั้น

นอกจากนี้ยังเป็นประโยชน์ที่จะมองข้าม LEAN ในการยืมแนวทางปฏิบัติ PM ที่ดีที่สุดสำหรับโครงการของคุณ ตัวอย่างเช่น มีเพียงระเบียบวิธี PRINCE2 เท่านั้นที่มีภารกิจบังคับในการรวบรวมบทเรียนที่ได้เรียนรู้ในช่วง เริ่มต้นของโครงการ ซึ่งจะรวบรวมบทเรียนทั้งหมดที่ได้เรียนรู้จากโครงการก่อนหน้านี้ แทนที่จะเขียนเอกสารที่ส่วนท้ายของโครงการที่ไม่ค่อยมีใครใช้เมื่อเริ่มโครงการใหม่ สิ่งสำคัญคืออย่ากลัวที่จะเปลี่ยนกระบวนการเพื่อขจัดขั้นตอนที่ไม่จำเป็นและมุ่งเน้นไปที่ขั้นตอนที่เพิ่มมูลค่าที่แท้จริง

นี่เป็นโอกาสที่ดีในการช่วยและปรับเปลี่ยนกระบวนการ หรือเพื่อช่วยให้ทีมเลือกสิ่งที่ถูกต้องตั้งแต่เริ่มต้น ตัวชี้วัดประสิทธิภาพที่ชัดเจนเหล่านี้ควรแบ่งปันอย่างโปร่งใสกับทุกคนที่เกี่ยวข้องเพื่อกำหนดแนวทางที่ชัดเจนของความสำเร็จของโครงการ

ประเด็นสำคัญที่นี่คือ: "การค้นหาโซลูชันที่เหมาะสมมีความสำคัญพอๆ กับการมีกระบวนการที่ถูกต้องแม่นยำในการส่งมอบโซลูชันเหล่านั้น"