การจัดการโครงการ

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

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

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

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

ประวัติ

จนถึงปี 1900 โครงการวิศวกรรมโยธาโดยทั่วไปได้รับการจัดการโดยสถาปนิกสร้างสรรค์ วิศวกร และผู้สร้างต้นแบบเช่นVitruvius (ศตวรรษแรกก่อนคริสต์ศักราช), Christopher Wren (1632–1723), Thomas Telford (1757–1834) และIsambard Kingdom Brunel ( พ.ศ. 2349-ค.ศ. 1859 [7]ในปี 1950 องค์กรเริ่มใช้เครื่องมือและเทคนิคการจัดการโครงการอย่างเป็นระบบกับโครงการวิศวกรรมที่ซับซ้อน [8]

Henry Gantt (1861–1919) บิดาแห่งเทคนิคการวางแผนและการควบคุม

ตามระเบียบวินัย การจัดการโครงการได้พัฒนาจากการใช้งานที่หลากหลาย รวมถึงการก่อสร้างโยธา วิศวกรรม และกิจกรรมการป้องกันตัวหนัก[9]บรรพบุรุษของการจัดการโครงการสองคนคือHenry Ganttซึ่งเรียกว่าบิดาแห่งเทคนิคการวางแผนและการควบคุม[10]ซึ่งมีชื่อเสียงในการใช้แผนภูมิ Ganttเป็นเครื่องมือในการจัดการโครงการ (หรือHarmonogramเสนอครั้งแรกโดยKarol Adamiecki [11] ); และHenri Fayolสำหรับการสร้างหน้าที่การจัดการทั้งห้าที่เป็นรากฐานขององค์ความรู้ที่เกี่ยวข้องกับการจัดการโครงการและโปรแกรม(12)ทั้งสองแกนต์และ Fayol เป็นนักศึกษาของเฟรเดอริพระพุทธเจ้าเทย์เลอร์ทฤษฎีของการจัดการทางวิทยาศาสตร์ผลงานของเขาเป็นผู้เบิกทางเพื่อเป็นเครื่องมือในการบริหารจัดการโครงการที่ทันสมัยรวมทั้งโครงสร้างการแบ่งงาน (WBS) และการจัดสรรทรัพยากร

ทศวรรษ 1950 เป็นจุดเริ่มต้นของยุคการจัดการโครงการสมัยใหม่ที่สาขาวิศวกรรมหลักมารวมกันเป็นหนึ่งเดียว การจัดการโครงการได้รับการยอมรับว่าเป็นวินัยที่แตกต่างที่เกิดจากวินัยการจัดการกับแบบจำลองทางวิศวกรรม[13]ในสหรัฐอเมริกา ก่อนทศวรรษ 1950 โครงการต่างๆ ได้รับการจัดการแบบเฉพาะกิจ โดยใช้แผนภูมิแกนต์และเทคนิคและเครื่องมือที่ไม่เป็นทางการเป็นส่วนใหญ่ในขณะนั้นมีการพัฒนาแบบจำลองการจัดกำหนดการโครงการทางคณิตศาสตร์สองแบบ " วิธีเส้นทางวิกฤติ " (CPM) ได้รับการพัฒนาโดยเป็นการร่วมทุนระหว่างบริษัทดูปองท์ คอร์ปอเรชั่นและเรมิงตัน แรนด์ คอร์ปอเรชั่นสำหรับการจัดการโครงการบำรุงรักษาโรงงาน NS "เทคนิคการประเมินและทบทวนโปรแกรม " (PERT) ได้รับการพัฒนาโดยสำนักงานโครงการพิเศษกองทัพเรือสหรัฐฯร่วมกับบริษัทล็อกฮีดและบูซ อัลเลน แฮมิลตันซึ่งเป็นส่วนหนึ่งของโครงการเรือดำน้ำโพลาริส[14]

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

แผนภูมิเครือข่าย PERTสำหรับโครงการเจ็ดเดือนที่มีเหตุการณ์สำคัญห้าประการ

ในเวลาเดียวกัน ขณะที่กำลังพัฒนาแบบจำลองการจัดกำหนดการโครงการ เทคโนโลยีสำหรับการประมาณต้นทุนโครงการการจัดการต้นทุน และเศรษฐศาสตร์ด้านวิศวกรรมก็มีการพัฒนา โดยมี Hans Lang และคนอื่นๆ เป็นผู้บุกเบิกงาน ในปี ค.ศ. 1956 American Association of Cost Engineers (ปัจจุบันคือAACE International ; the Association for the Advancement of Cost Engineering ) ได้ก่อตั้งขึ้นโดยผู้ปฏิบัติงานด้านการจัดการโครงการในระยะแรกและความเชี่ยวชาญพิเศษที่เกี่ยวข้องในการวางแผนและการจัดกำหนดการ การประมาณราคา และการควบคุมต้นทุน/ กำหนดการ (โครงการ ควบคุม). AACE ยังคงทำงานบุกเบิกอย่างต่อเนื่อง และในปี 2549 ได้เปิดตัวกระบวนการบูรณาการครั้งแรกสำหรับการจัดการพอร์ตโฟลิโอ โปรแกรม และโครงการ ( กรอบการจัดการต้นทุนทั้งหมด )

ในปี 1969 สถาบัน Project Management Institute (PMI) ได้ก่อตั้งขึ้นในสหรัฐอเมริกา [15] PMI เผยแพร่เวอร์ชันดั้งเดิมของA Guide to the Project Management Body of Knowledge (PMBOK Guide) ในปี 1996 โดยมี William Duncan เป็นผู้เขียนหลัก ซึ่งอธิบายวิธีปฏิบัติในการจัดการโครงการที่เหมือนกันกับ "โครงการส่วนใหญ่ ส่วนใหญ่ " [16]

ประเภทการจัดการโครงการ

วิธีการจัดการโครงการสามารถนำไปใช้กับโครงการใดก็ได้ มักได้รับการปรับแต่งให้เหมาะกับโครงการประเภทใดประเภทหนึ่งโดยพิจารณาจากขนาดโครงการ ธรรมชาติ อุตสาหกรรมหรือภาคส่วน ตัวอย่างเช่น อุตสาหกรรมการก่อสร้างซึ่งมุ่งเน้นไปที่การส่งมอบสิ่งต่างๆ เช่น อาคาร ถนน และสะพาน ได้พัฒนารูปแบบเฉพาะของการจัดการโครงการซึ่งหมายถึงการจัดการโครงการก่อสร้างและผู้จัดการโครงการสามารถเข้ารับการฝึกอบรมและได้รับการรับรองได้[17] อุตสาหกรรมเทคโนโลยีสารสนเทศยังได้พัฒนารูปแบบการจัดการโครงการของตัวเองที่เรียกว่าการจัดการโครงการไอทีและเชี่ยวชาญในการส่งมอบสินทรัพย์และบริการทางเทคนิคที่จำเป็นในการผ่านขั้นตอนต่างๆ ของวงจรชีวิต เช่น การวางแผน การออกแบบ การพัฒนา การทดสอบ และการใช้งาน การจัดการโครงการเทคโนโลยีชีวภาพมุ่งเน้นไปที่ความซับซ้อนของการวิจัยและพัฒนาเทคโนโลยีชีวภาพ [18] การจัดการโครงการโลคัลไลเซชันรวมถึงการนำแนวทางปฏิบัติในการจัดการโครงการมาตรฐานมาประยุกต์ใช้กับงานแปล แม้ว่าหลายคนจะพิจารณาว่าการจัดการประเภทนี้เป็นวินัยที่แตกต่างกันมาก มีการจัดการโครงการสาธารณะที่ครอบคลุมงานสาธารณะทั้งหมดของรัฐบาลที่ดำเนินการโดยหน่วยงานของรัฐหรือทำสัญญากับผู้รับเหมา การจำแนกประเภทอื่นของการจัดการโครงการขึ้นอยู่กับประเภทแข็ง (ทางกายภาพ) หรืออ่อน (ไม่ใช่ทางกายภาพ)

ประเภทการจัดการโครงการที่พบได้ทั่วไปคือ พวกเขามุ่งเน้นไปที่เป้าหมายที่สำคัญสามประการ ได้แก่ เวลา คุณภาพ และงบประมาณ โครงการที่ประสบความสำเร็จจะแล้วเสร็จตามกำหนดเวลา ภายในงบประมาณ และเป็นไปตามมาตรฐานคุณภาพที่ตกลงกันไว้ก่อนหน้านี้ เช่น เป็นไปตาม Iron Triangle หรือ Triple Constraint เพื่อให้โครงการได้รับการพิจารณาว่าสำเร็จหรือล้มเหลว (19)

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

แนวทางการบริหารโครงการ

การศึกษาในปี 2560 ชี้ให้เห็นว่าความสำเร็จของโครงการใดๆ ขึ้นอยู่กับว่าประเด็นสำคัญสี่ประการนั้นสอดคล้องกับการเปลี่ยนแปลงเชิงบริบทที่ส่งผลต่อโครงการได้ดีเพียงใด สิ่งเหล่านี้เรียกว่าสี่ P : [20]

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

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

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

การจัดการผลประโยชน์ที่ได้รับ

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

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

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

การจัดการโครงการลูกโซ่ที่สำคัญ

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

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

การจัดการมูลค่าที่ได้รับ

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

การจัดการโครงการซ้ำและส่วนเพิ่ม

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

ความซับซ้อนเหล่านี้สามารถจัดการได้ดีกว่าด้วยวิธีการสำรวจหรือทำซ้ำและเพิ่มขึ้น [26]หลายรูปแบบของการทำซ้ำและการจัดการโครงการที่เพิ่มขึ้นมีการพัฒนารวมทั้งการจัดการเปรียวโครงการ , ระบบพลวัตวิธีการพัฒนา , การบริหารจัดการโครงการที่รุนแรงและนวัตกรรมEngineering® [27]

การจัดการโครงการแบบลีน

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

แนวทางแบบค่อยเป็นค่อยไป

แนวทางแบบแบ่งระยะ (หรือแบบจัดฉาก) จะแยกย่อยและจัดการงานผ่านชุดของขั้นตอนที่แตกต่างกันเพื่อให้เสร็จสิ้น และมักเรียกกันว่า "ดั้งเดิม" [28]หรือ " น้ำตก " [29]แม้ว่าจะสามารถเปลี่ยนแปลงได้ แต่โดยทั่วไปจะประกอบด้วยพื้นที่กระบวนการห้าส่วน สี่ขั้นตอนพร้อมการควบคุม:

ขั้นตอนการพัฒนาโดยทั่วไปของโครงการวิศวกรรม
  1. การเริ่มต้น
  2. การวางแผนและการออกแบบ
  3. การก่อสร้าง.
  4. การติดตามและควบคุม
  5. เสร็จสิ้นหรือปิด

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

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

การจัดการตามกระบวนการ

การรวมตัวกันของการจัดการตามกระบวนการได้รับแรงผลักดันจากการใช้แบบจำลองวุฒิภาวะ เช่นOPM3และCMMI (การรวมแบบจำลองความสามารถครบกำหนด ดูตัวอย่างนี้ของรุ่นก่อน) และISO/IEC 15504 (SPICE – การปรับปรุงกระบวนการซอฟต์แวร์และการประมาณความสามารถ ). ไม่เหมือนกับ CMM ของ SEI โมเดลวุฒิภาวะของ OPM3 อธิบายวิธีทำให้กระบวนการจัดการโครงการสามารถดำเนินการได้สำเร็จ สม่ำเสมอ และคาดการณ์ได้ เพื่อบังคับใช้กลยุทธ์ขององค์กร

การจัดการการผลิตโครงการ

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

การวางแผนตามผลิตภัณฑ์

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

กลุ่มกระบวนการ

ระยะการพัฒนาโครงการ[34]

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

  • การเริ่มต้น
  • การวางแผน
  • การผลิตหรือการดำเนินการ
  • การตรวจสอบและการควบคุม
  • ปิด

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

การเริ่มต้น

การเริ่มต้นกระบวนการกลุ่มกระบวนการ[34]

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

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

การวางแผน

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

การวางแผนโครงการโดยทั่วไปประกอบด้วย[37]

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

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

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

กำลังดำเนินการ

กำลังดำเนินการกระบวนการกลุ่มกระบวนการ[34]

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

เอกสารโครงการ

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

การตรวจสอบและการควบคุม

การติดตามและควบคุมกระบวนการกลุ่มกระบวนการ[34]

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

การตรวจสอบและการควบคุมรวมถึง: [38]

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

กลไกหลักสองอย่างสนับสนุนการตรวจสอบและควบคุมในโครงการ ในอีกด้านหนึ่งสัญญาเสนอกฎเกณฑ์และสิ่งจูงใจซึ่งมักได้รับการสนับสนุนจากบทลงโทษและการลงโทษที่อาจเกิดขึ้น[39]ในทางกลับกัน นักวิชาการในธุรกิจและการจัดการให้ความสนใจกับบทบาทของผู้รวมระบบ (เรียกอีกอย่างว่าหัวหน้าโครงการ) เพื่อให้บรรลุวัตถุประสงค์ของโครงการ[40] [41]ในทางกลับกัน การวิจัยล่าสุดในการจัดการโครงการได้ตั้งคำถามถึงประเภทของการมีปฏิสัมพันธ์ระหว่างสัญญาและผู้รวมระบบ บางคนแย้งว่ากลไกการเฝ้าติดตามทั้งสองนี้ทำงานแทน[42]เนื่องจากองค์กรประเภทหนึ่งจะลดข้อดีของการใช้อีกกลไกหนึ่ง ในขณะที่บางคนแนะนำว่าสามารถเสริมซึ่งกันและกันได้[43]

ในโครงการหลายเฟส กระบวนการตรวจสอบและควบคุมยังให้ข้อเสนอแนะระหว่างขั้นตอนของโครงการ เพื่อดำเนินการแก้ไขหรือป้องกันเพื่อให้โครงการสอดคล้องกับแผนการจัดการโครงการ

การบำรุงรักษาโครงการเป็นกระบวนการต่อเนื่อง และรวมถึง: [35]

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

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

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

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

ปิด

กระบวนการกลุ่มกระบวนการปิด [34]

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

ระยะนี้ประกอบด้วย: [35]

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

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

ระบบควบคุมโครงการและระบบควบคุมโครงการ

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

  • การสร้างโครงสร้างพื้นฐานสำหรับการจัดหาข้อมูลที่ถูกต้องและการอัพเดท
  • การจัดตั้งวิธีสื่อสารความแตกต่างของพารามิเตอร์โครงการ
  • การพัฒนาเทคโนโลยีสารสนเทศโครงการตามอินทราเน็ตหรือการกำหนดระบบตัวบ่งชี้ประสิทธิภาพของโครงการ (KPI)
  • การวิเคราะห์ความแตกต่างและการสร้างข้อเสนอสำหรับกฎระเบียบของโครงการที่อาจเกิดขึ้น[46]
  • การจัดตั้งวิธีการเพื่อให้บรรลุโครงสร้างโครงการที่เหมาะสม องค์กรเวิร์กโฟลว์โครงการ การควบคุมโครงการและการกำกับดูแล
  • การสร้างความโปร่งใสระหว่างพารามิเตอร์โครงการ[47]

การปฏิบัติตามและการดำเนินงานเหล่านี้สามารถทำได้โดยใช้วิธีการเฉพาะและเครื่องมือในการควบคุมโครงการ สามารถใช้วิธีการควบคุมโครงการดังต่อไปนี้:

  • บทวิเคราะห์การลงทุน
  • การวิเคราะห์ผลประโยชน์ค่าใช้จ่าย
  • การวิเคราะห์ผลประโยชน์มูลค่า
  • แบบสำรวจผู้เชี่ยวชาญ
  • การคำนวณจำลอง
  • การวิเคราะห์โปรไฟล์ความเสี่ยง
  • การคำนวณค่าธรรมเนียม
  • การวิเคราะห์แนวโน้มก้าวสำคัญ
  • การวิเคราะห์แนวโน้มต้นทุน
  • เป้าหมาย/เปรียบเทียบจริง[48]

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

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

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

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

ลักษณะโครงการ

ลักษณะสำคัญของโครงการมีห้าประการ (i) ควรมีวันที่เริ่มต้นและสิ้นสุดที่เฉพาะเจาะจงเสมอ (ii) ดำเนินการและเสร็จสิ้นโดยกลุ่มคน (iii) ผลลัพธ์คือการส่งมอบผลิตภัณฑ์หรือบริการที่ไม่ซ้ำใคร (iv) พวกเขามีลักษณะชั่วคราว (v) ค่อยเป็นค่อยไป ตัวอย่าง ออกแบบรถใหม่ เขียนหนังสือ

ความซับซ้อนของโครงการ

ความซับซ้อนและลักษณะของมันมีบทบาทสำคัญในด้านการจัดการโครงการ แม้จะมีการอภิปรายในเรื่องนี้เป็นจำนวนมาก แต่การศึกษาชี้ให้เห็นถึงการขาดคำจำกัดความและความเข้าใจที่สมเหตุสมผลเกี่ยวกับความซับซ้อนที่เกี่ยวข้องกับการจัดการโครงการที่ซับซ้อน [50] [51]

ความซับซ้อนของโครงการเป็นคุณสมบัติของโครงการซึ่งทำให้เข้าใจ คาดการณ์ และควบคุมพฤติกรรมโดยรวมได้ยาก แม้จะให้ข้อมูลที่ครบถ้วนตามสมควรเกี่ยวกับระบบโครงการก็ตาม [52] การระบุโครงการที่ซับซ้อนมีความสำคัญเป็นพิเศษต่อสภาพแวดล้อมทางวิศวกรรมหลายโครงการ [53]

เนื่องจากการพิจารณาความซับซ้อนของโครงการและประสิทธิภาพของโครงการมีความเกี่ยวข้องกันอย่างใกล้ชิด จึงเป็นสิ่งสำคัญในการกำหนดและวัดความซับซ้อนของโครงการเพื่อให้การจัดการโครงการมีประสิทธิผล [54]

ความซับซ้อนสามารถ:

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

บนพื้นฐานของกรอบ Cynefin , [56]โครงการที่ซับซ้อนสามารถจัดเป็น:

  • โครงการ ระบบ หรือบริบทที่เรียบง่าย (หรือชัดเจน ชัดเจน เป็นที่รู้จัก) สิ่งเหล่านี้มีลักษณะเฉพาะด้วยความสัมพันธ์ที่ทราบกันดีอยู่แล้ว มีเสถียรภาพ และความสัมพันธ์ของเหตุและผลที่ชัดเจน สามารถแก้ไขได้ด้วยขั้นตอนการปฏิบัติงานมาตรฐานและแนวปฏิบัติที่ดีที่สุด
  • ซับซ้อน : โดดเด่นด้วยสิ่งที่ไม่รู้จัก ระบบที่ซับซ้อนคือผลรวมของส่วนต่างๆ โดยหลักการแล้ว มันสามารถแยกส่วนออกเป็นส่วนประกอบที่เรียบง่ายกว่าได้ ในขณะที่ปัญหาที่ยากและซับซ้อนสามารถแก้ไขได้ในทางทฤษฎีด้วยทรัพยากรเพิ่มเติม ด้วยความเชี่ยวชาญเฉพาะด้าน ด้วยการวิเคราะห์ การลดทอน การทำให้เข้าใจง่าย เทคนิคการสลายตัว ด้วยการวางแผนสถานการณ์ และการปฏิบัติตามแนวทางปฏิบัติที่ดี [57] [58]
  • ซับซ้อน : โดดเด่นด้วยสิ่งที่ไม่รู้จักและการเกิดขึ้น สามารถเปิดเผยรูปแบบได้ แต่ไม่ชัดเจน ระบบที่ซับซ้อนสามารถอธิบายได้โดยคำกล่าวของอริสโตเติลว่าทั้งหมดเป็นมากกว่าผลรวมของส่วนต่างๆ
  • โครงการที่ซับซ้อนจริงๆหรือที่รู้จักว่าซับซ้อนมาก หรือ โกลาหล: มีลักษณะเฉพาะที่ไม่สามารถเข้าใจได้ ไม่มีรูปแบบใดที่มองเห็นได้ในโครงการที่ซับซ้อนจริงๆ เหตุและผลไม่ชัดเจนแม้ในการหวนกลับ การถอดความอริสโตเติลระบบที่ซับซ้อนจริงๆ แตกต่างจากผลรวมของส่วนต่างๆ

โดยการนำการค้นพบนี้ไปใช้ในการวัดความซับซ้อนของงานตามที่อธิบายไว้ในRequisite Organizationและ Stratified Systems Theory ดร. Elliott Jaques ได้จำแนกโครงการและงานโครงการ (ขั้นตอน งาน) ออกเป็น 7 ระดับพื้นฐานของความซับซ้อนของโครงการตามเกณฑ์เช่นช่วงเวลาของดุลยพินิจและความซับซ้อนของ ผลลัพธ์ของโครงการ: [59] [60]

  • โครงการระดับ 1 – ปรับปรุงผลลัพธ์โดยตรงของกิจกรรม (ปริมาณ คุณภาพ เวลา) ภายในกระบวนการทางธุรกิจโดยมีเวลาเสร็จสิ้นตามเป้าหมายสูงสุด 3 เดือน
  • โครงการระดับ 2 – พัฒนาและปรับปรุงการปฏิบัติตามกระบวนการทางธุรกิจโดยมีเป้าหมายให้เสร็จสิ้นภายในเวลา 3 เดือนถึง 1 ปี
  • โครงการระดับ 3 – พัฒนา เปลี่ยนแปลง และปรับปรุงกระบวนการทางธุรกิจโดยมีเป้าหมายให้เสร็จสิ้นภายในเวลา 1 ถึง 2 ปี
  • โครงการระดับ 4 – พัฒนา เปลี่ยนแปลง และปรับปรุงระบบการทำงานโดยมีเป้าหมายให้เสร็จภายในเวลา 2 ปีถึง 5 ปี
  • โครงการระดับ 5 – พัฒนา เปลี่ยนแปลง และปรับปรุงกลุ่มระบบการทำงาน/หน้าที่ธุรกิจโดยมีเป้าหมายระยะเวลาดำเนินการให้แล้วเสร็จจาก 5 ปี เป็น 10 ปี
  • โครงการระดับ 6 – พัฒนา เปลี่ยนแปลง และปรับปรุงห่วงโซ่คุณค่าเดียวทั้งหมดของบริษัทโดยมีเป้าหมายเวลาดำเนินการให้เสร็จสิ้นตั้งแต่ 10 ถึง 20 ปี
  • โครงการระดับ 7 – พัฒนา เปลี่ยนแปลง และปรับปรุงห่วงโซ่คุณค่าที่หลากหลายของบริษัทโดยมีเป้าหมายให้สำเร็จลุล่วงได้ตั้งแต่ 20 ปี ถึง 50 ปี [61]

ประโยชน์จากการวัดความซับซ้อนของโครงการคือการปรับปรุงความเป็นไปได้ของบุคลากรในโครงการโดย: [62]

  • จับคู่ระดับความซับซ้อนของโครงการกับเวลาที่เป้าหมายสำเร็จของโครงการ
  • จับคู่ระดับความซับซ้อนของโครงการกับระดับความสามารถตามลำดับของผู้จัดการโครงการ
  • จับคู่ระดับความซับซ้อนของงานโครงการกับความสามารถที่เกี่ยวข้องของสมาชิกโครงการ

บวก เหมาะสม (จำเป็น) และความซับซ้อนเชิงลบ

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

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

ผู้จัดการโครงการ

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

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

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

Randall L. Englund และ Alfonso Bucero ผู้จัดการโครงการที่สมบูรณ์ซึ่งกำหนดโดย Dr. Robert J. Graham ในการจำลองของเขา พวกเขาอธิบายถึงผู้จัดการโครงการที่สมบูรณ์ว่าเป็นคนที่โอบรับหลายสาขาวิชา เช่น ความเป็นผู้นำ อิทธิพล การเจรจา การเมือง การเปลี่ยนแปลงและการจัดการความขัดแย้ง และอารมณ์ขัน สิ่งเหล่านี้ล้วนเป็นทักษะด้านบุคลากรที่ "อ่อนน้อม" ซึ่งช่วยให้ผู้นำโครงการมีประสิทธิภาพมากขึ้นและบรรลุผลลัพธ์ที่สอดคล้องกันและเหมาะสมที่สุด

กรอบงานและเกณฑ์ความสำเร็จหลายระดับ

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

เกณฑ์ในเบื้องต้นไม่ได้กล่าวถึงผลลัพธ์หลังเสร็จสิ้นโครงการที่สำคัญกว่า ซึ่งประกอบด้วยสี่ระดับ ได้แก่ ความสำเร็จของผลลัพธ์ (ผลิตภัณฑ์) ความสำเร็จของผลลัพธ์ (ประโยชน์) และความสำเร็จ (เชิงกลยุทธ์) ผลกระทบ (เชิงกลยุทธ์) ในระหว่างวงจรชีวิตผลิตภัณฑ์ เกณฑ์ความสำเร็จภายหลังเหล่านี้บ่งชี้ถึงการวัดประสิทธิภาพของผลิตภัณฑ์ บริการ หรือผลลัพธ์ หลังจากเสร็จสิ้นโครงการและส่งมอบ กรอบความสำเร็จหลายระดับที่ครอบคลุมของโครงการ โปรแกรม และพอร์ตโฟลิโอนี้ได้รับการพัฒนาโดย Paul Bannerman ในปี 2008 [64]กล่าวอีกนัยหนึ่งว่าโครงการประสบความสำเร็จเมื่อประสบความสำเร็จในการบรรลุกรณีธุรกิจที่คาดหวังซึ่งจำเป็นต้องระบุและกำหนดไว้อย่างชัดเจนในระหว่างการเริ่มต้นและคัดเลือกโครงการก่อนเริ่มขั้นตอนการพัฒนา กรอบงานความสำเร็จหลายระดับนี้สอดคล้องกับทฤษฎีของโครงการในฐานะการเปลี่ยนแปลงที่บรรยายว่าเป็นกระบวนการอินพุต / กิจกรรม - ผลลัพธ์ - ผลลัพธ์ - ผลกระทบ เพื่อสร้างมูลค่าตามที่ตั้งใจไว้ Emanuel Camilleri ในปี 2011 จำแนกปัจจัยความสำเร็จและความล้มเหลวที่สำคัญทั้งหมดออกเป็นกลุ่มๆ และจับคู่ปัจจัยแต่ละอย่างเข้ากับเกณฑ์ความสำเร็จหลายระดับเพื่อสร้างมูลค่าทางธุรกิจ [65]

การบริหารความเสี่ยง

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

โครงสร้างการแบ่งงาน

โครงสร้างการแบ่งงาน (WBS) เป็นโครงสร้างที่แสดงให้เห็นว่าการแบ่งของกิจกรรมที่จำเป็นเพื่อให้บรรลุวัตถุประสงค์ - ตัวอย่างผลงานโปรแกรมโครงการและสัญญา WBS อาจเป็นฮาร์ดแวร์ ผลิตภัณฑ์ บริการ หรือกระบวนการ (ดูตัวอย่างในโครงสร้างการรายงานของ NASA (2001) ) [67] นอกจาก WBS สำหรับการจัดการขอบเขตของโครงการมีการจัดโครงสร้างองค์กรสลาย (กราฟ)โครงสร้างต้นทุนการสลายและโครงสร้างการสลายความเสี่ยง

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

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

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

มาตรฐานสากล

มีมาตรฐานการจัดการโครงการหลายประการ ได้แก่ :

  • มาตรฐานISO ISO 9000ตระกูลมาตรฐานสำหรับระบบการจัดการคุณภาพ และISO 10006 :2003 สำหรับระบบการจัดการคุณภาพและแนวทางสำหรับการจัดการคุณภาพในโครงการ
  • มาตรฐาน ISO 21500 : 2012 - คำแนะนำเกี่ยวกับการบริหารจัดการโครงการ นี่เป็นมาตรฐานสากลฉบับแรกที่เกี่ยวข้องกับการจัดการโครงการที่เผยแพร่โดย ISO มาตรฐานอื่น ๆ ในครอบครัว ได้แก่ 21500 21503: 2017 คำแนะนำเกี่ยวกับการบริหารจัดการโครงการ ; 21504:2015 คำแนะนำเกี่ยวกับการจัดการพอร์ตโฟลิโอ ; 21005:2017 แนวทางการกำกับดูแล ; 21506:2018 คำศัพท์ ; 21508:2018 ได้รับการจัดการมูลค่าในโครงการและการจัดการโปรแกรม ; และ 21511:2018 โครงสร้างการแบ่งงานสำหรับการจัดการโครงการและโปรแกรม
  • ISO 31000 :2009 – การจัดการความเสี่ยง
  • ISO/IEC/IEEE 16326:2009 – วิศวกรรมระบบและซอฟต์แวร์—กระบวนการวงจรชีวิต—การจัดการโครงการ[68]
  • พื้นฐานความสามารถส่วนบุคคล (ICB) จาก International Project Management Association (IPMA) [69]
  • Capability Maturity Model (CMM) จากสถาบันวิศวกรรมซอฟต์แวร์
  • GAPPS, Global Alliance for Project Performance Standards – มาตรฐานโอเพ่นซอร์สที่อธิบายความสามารถสำหรับผู้จัดการโครงการและโปรแกรม
  • วิธี HERMES วิธีการจัดการโครงการทั่วไปของสวิส เลือกใช้ในลักเซมเบิร์กและองค์กรระหว่างประเทศ
  • กรอบตรรกะวิธี (LFA) ซึ่งเป็นที่นิยมในองค์กรพัฒนาระหว่างประเทศ
  • คู่มือ PMBOKจากสถาบันการจัดการโครงการ (PMI)
  • PRINCE2จากAxelos
  • ทีมงานซอฟท์แวกระบวนการ (TSP) จากสถาบันวิศวกรรมซอฟต์แวร์
  • Total Cost Management Framework, AACE International's Methodology for Integrated Portfolio, Program and Project Management.
  • V-Modelวิธีการพัฒนาระบบดั้งเดิม

การจัดการโปรแกรม

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

การจัดการพอร์ตโครงการ

องค์กรจำนวนมากขึ้นกำลังใช้สิ่งที่เรียกว่าการจัดการพอร์ตโครงการ (PPM) เป็นวิธีการเลือกโครงการที่เหมาะสมแล้วใช้เทคนิคการจัดการโครงการ[70]เป็นวิธีการส่งมอบผลลัพธ์ในรูปแบบของผลประโยชน์ให้กับการปฏิบัติงาน องค์กรภาครัฐ เอกชน หรือไม่แสวงหาผลกำไร PPM มักจะดำเนินการโดยทีมผู้จัดการเฉพาะที่จัดภายใน Enterprise Project Management Office (PMO) ที่นำโดยผู้อำนวยการ PMO ซึ่งมักจะอยู่ในองค์กร ดังนั้นตำแหน่งที่รับผิดชอบ PPM สามารถกำหนดเป็นหัวหน้าเจ้าหน้าที่โครงการหรือหัวหน้าเจ้าหน้าที่เทคโนโลยี ในกรณีที่ความคิดริเริ่มเชิงกลยุทธ์ขององค์กรก่อตัวเป็นกลุ่มของ PPM หัวหน้าของ PPM จะได้รับตำแหน่งเป็นหัวหน้าเจ้าหน้าที่ฝ่ายริเริ่ม

ซอฟต์แวร์การจัดการโครงการ

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

การจัดการโครงการเสมือนจริง

การจัดการโปรแกรมเสมือน (VPM) คือการจัดการโครงการที่ทำโดยทีมเสมือนแม้ว่าจะไม่ค่อยหมายถึงโครงการที่ใช้สภาพแวดล้อมเสมือน[73] สังเกตว่าการจัดการโครงการเสมือนนั้นแตกต่างจากการจัดการโครงการแบบดั้งเดิม[74 ]รวมข้อกังวลของการสื่อสารโทรคมนาคมและการทำงานร่วมกันทั่วโลก (วัฒนธรรม เขตเวลา ภาษา) [75]

ดูเพิ่มเติม

อ้างอิง

  1. ^ (2003). PMP การบริหารจัดการโครงการคู่มือการศึกษามืออาชีพ McGraw-Hill Professional, 2003. ISBN  0-07-223062-2 p.354
  2. ^ บา รัตตา, แองเจโล (2006). "ข้อจำกัดสามเท่าภาพลวงตา" . พีเอ็มไอ. สืบค้นเมื่อ22 ธันวาคม 2020 .
  3. ^ The Definitive Guide to Project Management . นอคส์, เซบาสเตียน. กศน. ลอนดอน (Financial Times / Prentice Hall): 2007 ISBN 978-0-273-710am97-4  ข้อผิดพลาดในพารามิเตอร์ {{ ISBN }}: ไม่ถูกต้องISBN 
  4. ^ "การบริหารโครงการคืออะไร" . สถาบันบริหารโครงการ. สืบค้นเมื่อ2014-06-04 .
  5. ^ Paul C. Dinsmore et al (2005)โครงการที่ถูกต้องทำถูกต้อง! John Wiley and Sons, 2005. ISBN 0-7879-7113-8 . หน้า 35 และต่อไป 
  6. ^ Cattani, G.; Ferriani, S.; เฟรเดอริคเซ่น, L.; Florian, T. (2011). ตามโครงการการจัดการและการบริหารเชิงกลยุทธ์ ความก้าวหน้าในการจัดการเชิงกลยุทธ์ 28 . มรกต. ISBN 978-1780521930.
  7. ^ Dennis Lock (2007) Project Management (9th ed.) Gower Publishing, Ltd., 2007. ISBN 0-566-08772-3 
  8. ^ ยัง-ฮุน กวัก (2005). "ประวัติโดยย่อของการบริหารโครงการ". ใน:เรื่องราวของการจัดการโครงการ . Elias G. Carayannisและคณะ (9ฉบับ ), Greenwood Publishing Group, 2005. ISBN 1-56720-506-2 
  9. เดวิด ไอ. คลีแลนด์ ,โรแลนด์ กาเรส์ (2006). คู่มือการบริหารจัดการโครงการทั่วโลก "บทที่ 1: "วิวัฒนาการของการจัดการโครงการ" McGraw-Hill Professional, 2006. ISBN 0-07-146045-4 
  10. มาร์ติน สตีเวนส์ (2002). เส้นทางสู่การบริหารจัดการโครงการ สมาคมการจัดการโครงการ APM Publishing Limited, 2002 ISBN 1-903494-01-X p.xxii 
  11. เอ็ดเวิร์ด อาร์. มาร์ช (1975) "ฮาร์โมโนแกรมของ Karol Adamiecki". ใน:วารสาร Academy of Management . ฉบับที่ 18 ฉบับที่ 2 (มิ.ย. 2518), น. 358. (ออนไลน์ )
  12. ^ มอร์เกนวิตเซล (2003) ห้าสิบตัวเลขที่สำคัญในการบริหารจัดการ เลดจ์, 2003. ISBN 0-415-36977-0 . NS. 96-101. 
  13. เดวิด ไอ. คลีแลนด์ , โรแลนด์ กาเรส์ (2006). คู่มือการบริหารจัดการโครงการทั่วโลก McGraw-Hill Professional, 2006. ISBN 0-07-46045-4 . p.1-4 ระบุว่า: "ในปี 1950 เมื่อการจัดการโครงการได้รับการยอมรับอย่างเป็นทางการว่าเป็นผลงานที่ชัดเจนซึ่งเกิดขึ้นจากระเบียบวินัยการจัดการ " 
  14. Malcolm, DG , Roseboom, JH, Clark, CE, & Fazar, W. (1959). การประยุกต์ ใช้ เทคนิค เพื่อ ประเมิน ผล โครงการ วิจัยและพัฒนา . การวิจัยปฏิบัติการ, 7(5), 646-669.
  15. ฟลอริดา แฮร์ริสัน, เดนนิส ล็อค (2004). การบริหารจัดการโครงการขั้นสูง: วิธีการโครงสร้าง Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8 . หน้า 34 
  16. ^ Saladis, FP (2006). นำคู่มือ PMBOK® มาสู่ชีวิต เอกสารนำเสนอที่ PMI® Global Congress 2006—อเมริกาเหนือ ซีแอตเทิล รัฐวอชิงตัน Newtown Square, PA: สถาบันการจัดการโครงการ. ได้ที่ https://www.pmi.org/learning/library/bringing-pmbok-guide-life-practical-8009
  17. ^ "ใบรับรองผู้จัดการฝ่ายก่อสร้าง" . ซีเอ็มเอ. สืบค้นเมื่อ23 พฤศจิกายน 2556 .
  18. ^ "ใบรับรองการบริหารโครงการเทคโนโลยีชีวภาพ" . มหาวิทยาลัยวอชิงตัน. สืบค้นเมื่อ23 พฤศจิกายน 2556 .
  19. ^ เอส เซลิงค์, เบิร์ต (2000). คู่มือปฏิบัติเพื่อโลคัลไลเซชัน อัมสเตอร์ดัม/ฟิลาเดลเฟีย: John Benjamins Publishing Company. NS. 428. ISBN 978-9-027-21956-5.
  20. ^ ยุ่ง, โอลิเวียร์. (2017). ความเป็นไปได้ของโครงการ – เครื่องมือสำหรับเปิดเผยจุดอ่อน นิวยอร์ก นิวยอร์ก: เทย์เลอร์และฟรานซิส สำนักพิมพ์ซีอาร์ซี 546 หน้า ไอ9 781498 757911 . 
  21. ^ cf เลย The Bridger (บล็อก), "การจัดการโครงการ: PMP, Prince 2 หรือตัวแปร Iterative หรือ Agile"
  22. ^ เซอร์รา CEM; Kunc, M. (2014). "การจัดการผลประโยชน์ให้เกิดประโยชน์และอิทธิพลที่มีต่อความสำเร็จของโครงการและการดำเนินกลยุทธ์ทางธุรกิจ" . วารสารการจัดการโครงการนานาชาติ . 33 (1): 53–66. ดอย : 10.1016/j.ijproman.2014.03.011 .
  23. ^ Hass, Kathleen B. (คิตตี้) (2 มีนาคม 2010) "การจัดการโครงการที่ซับซ้อนที่ใหญ่เกินไป ยาวเกินไป และแพงเกินไป" . PM ไทม์ สืบค้นเมื่อ2017-06-27 .
  24. ^ คอนฟอร์ โต อีซี; สลัม, เอฟ.; อามารัล ดีซี; ดา ซิลวา, SL; Magnanini de Almeida, L. F (มิถุนายน 2014). "การจัดการโครงการแบบ Agile สามารถนำมาใช้ในอุตสาหกรรมอื่นที่ไม่ใช่การพัฒนาซอฟต์แวร์ได้หรือไม่" วารสารบริหารโครงการ . 45 (3): 21–34. ดอย : 10.1002/pmj.21410 . S2CID 110595660 . 
  25. ^ Patel, Himanshu (20 เมษายน 2018) "แบบจำลองน้ำตกในการบริหารโครงการอธิบาย" . อิทคุรุ. สืบค้นเมื่อ2017-04-20 .
  26. ^ Snowden, เดวิดเจ ; บูน, แมรี่ อี. (พฤศจิกายน 2550). "กรอบผู้นำสำหรับการตัดสินใจ" . รีวิวธุรกิจฮาร์วาร์ด. สืบค้นเมื่อ2017-06-27 .
  27. ^ "สแตนฟอการศึกษาวิจัยพบนวัตกรรมด้านวิศวกรรมเป็นจริง 'แหกคุกนวัตกรรม' ระบบ" ข่าว IE 20 มิถุนายน 2560 . สืบค้นเมื่อ2017-08-11 .
  28. ^ Wysocki โรเบิร์ต K (2013) การจัดการโครงการอย่างมีประสิทธิภาพ: ดั้งเดิม ปรับตัวได้ สุดขั้ว (ฉบับที่เจ็ด) จอห์น ไวลีย์ แอนด์ ซันส์ . ISBN 978-1118729168.
  29. วินสตัน ดับเบิลยู. รอยซ์ (1970) "การจัดการการพัฒนาระบบซอฟต์แวร์ขนาดใหญ่" เก็บถาวร 2016-03-15 ที่ Wayback Machineใน:เอกสารทางเทคนิคของ Western Electronic Show and Convention (WesCon) 25–28 สิงหาคม 1970 ลอสแองเจลิสสหรัฐอเมริกา
  30. อรรถเป็น ข ส เตลแมน แอนดรูว์; กรีน, เจนนิเฟอร์ (2005). การบริหารจัดการโครงการซอฟแวร์ประยุกต์ โอเรลลี่ มีเดีย. ISBN 978-0-596-00948-9. เก็บถาวรจากต้นฉบับเมื่อ 2015-02-09.
  31. ^ McCaffer โรนัลด์; แฮร์ริส, แฟรงค์ (2013). การจัดการการก่อสร้างที่ทันสมัย ไวลีย์-แบล็คเวลล์. NS. 5. ISBN 978-1118510186. OCLC  834624541 .
  32. ^ สำนักงานการค้าของรัฐบาล (1996) การจัดการโครงการที่ประสบความสำเร็จด้วย PRINCE2 , p14
  33. ^ OGC – PRINCE2 – พื้นหลัง
  34. ^ a b c d e f "คู่มือการบริหารโครงการ" (PDF) . VA สำนักงานสารสนเทศและเทคโนโลยี . พ.ศ. 2546 เก็บถาวรจากต้นฉบับเมื่อ 14 มกราคม 2552 CS1 maint: unfit URL (link)
  35. ^ a b c PMI (2010). คู่มือการจัดการโครงการองค์ความรู้ p.27-35
  36. ปีเตอร์ นาธาน, เจอรัลด์ เอเวอเร็ตต์ โจนส์ (2003). รับรอง PMP สำหรับ Dummies น.63
  37. ^ แฮโรลด์ Kerzner (2003) การจัดการโครงการ: แนวทางระบบเพื่อการวางแผน การจัดกำหนดการ และการควบคุม (ฉบับที่ 8) ไวลีย์. ISBN 0-271-22577-0.
  38. ^ เจมส์พีลูอิส (2000) การอ้างอิงโต๊ะทำงานของผู้จัดการโครงการ: : คู่มือที่ครอบคลุมเกี่ยวกับการวางแผนโครงการ การจัดกำหนดการ การประเมิน และระบบ หน้า185
  39. ^ เอ็กเซิล, โรเบิร์ต (1981) "Quasifirm ในอุตสาหกรรมก่อสร้าง" . วารสารพฤติกรรมเศรษฐกิจและองค์การ . 2 (4): 335–357. ดอย : 10.1016/0167-2681(81)90013-5 . ISSN 0167-2681 . 
  40. ^ เดวีส์ แอนดรูว์; Hobday, ไมเคิล (2005). ธุรกิจโครงการ: การจัดการนวัตกรรมในผลิตภัณฑ์และระบบที่ซับซ้อน . สำนักพิมพ์มหาวิทยาลัยเคมบริดจ์. ISBN 978-0-521-84328-7.
  41. ^ แกนน์ เดวิด; พ่อค้าเกลือ แอมมอน; ดอดจ์สัน, มาร์ค; ฟิลิปส์, เนลสัน (2012). "ภายในโลกของโครงการ บารอน" . MIT Sloan ทบทวนการบริหารจัดการ 53 (3): 63–71. ISSN 1532-9194 . 
  42. ^ เหมิง, เซียนไห่ (2012). "ผลของการบริหารความสัมพันธ์ต่อผลการดำเนินโครงการในการก่อสร้าง" . วารสารการจัดการโครงการนานาชาติ . 30 (2): 188–198. ดอย : 10.1016/j.ijproman.2011.04.002 .
  43. ^ Oliveira, Nuno; ลูมิโน, แฟบริซ (2017). "วิถีการประสานงานมีอิทธิพลต่อประสิทธิภาพของเครือข่ายโครงการระหว่างองค์กรอย่างไร" . องค์การ วิทยาศาสตร์ . 28 (6): 1029–1060. ดอย : 10.1287/orsc.2017.1151 . ISSN 1047-7039 . 
  44. ^ โคเฮนชิเอส Rozenes เอสและเบนแกลลอน I. (2016) "การบริหารจัดการตรวจสอบโครงการที่คาดว่าจะขึ้นอยู่กับระยะเวลาเอนโทรปี" (PDF) ในเอนโทรปี 2020, 22, 905 CS1 maint: multiple names: authors list (link)
  45. ^ Jörgเบกเกอร์, มาร์ติน Kugeler ไมเคิล Rosemann (2003) การจัดการกระบวนการ: คู่มือสำหรับการออกแบบกระบวนการทางธุรกิจ ISBN 978-3-540-43499-3 หน้า 27. 
  46. ^ Bernhard Schlagheck (2000) Objektorientierte Referenzmodelle สำหรับ Prozess- und Projektcontrolling กรุนด์ลาเกน – คอนสตรัคชั่นเนน – อันเวนดุงสโมกลิกเคเทิน ไอ978-3-8244-7162-1 . หน้า 131 
  47. ^ โจเซฟ อี. รีดล์ (1990). โครงการ – การควบคุมใน Forschung und Entwicklung ไอ978-3-540-51963-8 . หน้า 99 
  48. ^ Steinle, Bruch ละว้า (1995) การจัดการโครงการ FAZ Verlagsbereich Wirtschaftsbücher หน้า 136–143
  49. ซินเทีย สไนเดอร์, แฟรงค์ พาร์ธ (2006). ความรู้เบื้องต้นเกี่ยวกับการจัดการโครงการไอที หน้า 393-397
  50. ^ Abdou, Saed M; ยง, กวน; โอธมาน, โมฮัมเหม็ด (2016). "อิทธิพลของความซับซ้อนของโครงการที่มีต่อประสิทธิภาพการจัดการโครงการ – มุมมองของมาเลเซีย" . เว็บ MATEC ของการประชุม 66 : 00065. ดอย : 10.1051/matecconf/20166600065 . ISSN 2261-236X . 
  51. ^ มอร์คอฟ สเตฟาน; พินเทลอน, ลิเลียน; Kusters, ร็อบ เจ. (2020). "ความหมายลักษณะและมาตรการไอทีโครงการความซับซ้อน - ต่อระบบการทบทวนวรรณกรรม" (PDF) วารสารนานาชาติระบบสารสนเทศและการจัดการโครงการ . 8 (2): 5–21. ดอย : 10.12821/ijispm080201 .
  52. อรรถเป็น มาร์ล แฟรงค์; วิดัล, ลูโดวิช-อเล็กซานเดร (2016). ผู้จัดการคอมเพล็กซ์โครงการมีความเสี่ยงสูง - คู่มือการพื้นฐานและการบริหารจัดการโครงการขั้นสูง ลอนดอน: Springer-Verlag.
  53. ^ วิดัล, ลู-Alexandre; มาร์ล, แฟรงค์; บ็อกเกต์, ฌอง-คล็อด (2554). "การวัดความซับซ้อนของโครงการโดยใช้กระบวนการลำดับชั้นของการวิเคราะห์" วารสารการจัดการโครงการนานาชาติ . 29 : 718–727.
  54. ^ วิดัล, ลู-Alexandre; มาร์ล, แฟรงค์ (2008). "ความซับซ้อนของความเข้าใจโครงการความหมายในการบริหารจัดการโครงการ" (PDF) ไคเบอร์เนเตส . 37 (8): 1094–1110. ดอย : 10.1108/03684920810884928 .
  55. ^ Baccarini, D. (1996). "แนวคิดเรื่องความซับซ้อนของโครงการ การทบทวน". วารสารการจัดการโครงการนานาชาติ . 14 (4): 201–204.
  56. ^ Snowden, เดวิดเจ .; บูน, แมรี่ อี. (2007). "กรอบผู้นำสำหรับการตัดสินใจ" . รีวิวธุรกิจฮาร์วาร์ด . 85 (11): 68–76.CS1 maint: multiple names: authors list (link)
  57. ^ เมาเร่อ, ไมค (2017). การจัดการความซับซ้อนในการออกแบบทางวิศวกรรม – ไพรเมอร์ เบอร์ลิน, ไฮเดลเบิร์ก: สปริงเกอร์.
  58. ^ เคิร์ตซ์ CF; สโนว์เดน, เดวิด เจ. (2003). "พลวัตใหม่ของกลยุทธ์: การสร้างความรู้สึกในโลกที่ซับซ้อนและซับซ้อน" ระบบ IBM วารสาร 42 (3): 462–483. ดอย : 10.1147/sj.423.0462 .CS1 maint: multiple names: authors list (link)
  59. ^ G. , Morris, Peter W. (1994). การจัดการโครงการต่างๆ ลอนดอน: ต. เทลฟอร์ด NS. 317. ISBN 978-0727725936. OCLC  30437274
  60. ^ Gower คู่มือคนในการจัดการโครงการ . ล็อค, เดนนิส., สก็อตต์, ลินด์ซีย์, 1974-. Farnham, Surrey: สำนักพิมพ์ Gower 2013. พี. 398. ISBN 978-1409437857. OCLC  855019788 .CS1 maint: others (link)
  61. ^ "ป.ป.ช." . www.theprojectmanager.co.za . สืบค้นเมื่อ2018-03-01 .
  62. ^ ค่าคอมมิชชั่น บริการสาธารณะของออสเตรเลีย "เฟรมเวิร์ก APS สำหรับโครงสร้างการจัดการที่เหมาะสม" . สืบค้นเมื่อ2018-03-01 .
  63. ^ มอร์คอฟ สเตฟาน; พินเทลอน, ลิเลียน; Kusters, ร็อบ เจ. (2020). "ไอทีโครงการซับซ้อนของการจัดการบนพื้นฐานของแหล่งที่มาและผลกระทบ: เป็นบวกเหมาะสมและ Negative" (PDF) การดำเนินการของโรมาเนียศึกษา - ซีรีส์ 21 (4): 329–336.
  64. ^ Bannerman, PL (2008) การกำหนดความสำเร็จของโครงการ: กรอบงานหลายระดับ บทความที่นำเสนอในการประชุมวิจัย PMI®: การกำหนดอนาคตของการจัดการโครงการ กรุงวอร์ซอ ประเทศโปแลนด์ Newtown Square, PA: สถาบันการจัดการโครงการ. สามารถดูได้ที่ https://www.pmi.org/learning/library/defining-project-success-multilevel-framework-7096
  65. ^ เอ็มมานู Camilleri โครงการที่ประสบความสำเร็จ: ปัจจัยที่สำคัญและพฤติกรรมโกเวอร์ Publishing, Ltd. 2011
  66. ^ "DoDD 5000.01" (PDF) . กระทรวงกลาโหมสหรัฐ. สืบค้นเมื่อ20 พฤศจิกายน 2550 .
  67. ^ a b NASA NPR 9501.2D . 23 พฤษภาคม 2544
  68. ^ ISO/IEC/IEEE 16326-2009 – วิศวกรรมระบบและซอฟต์แวร์--กระบวนการวงจรชีวิต--การจัดการโครงการ ธันวาคม 2552 DOI: 10.1109/IEEESTD.2009.5372630 ISBN 978-0-7381-6116-7 
  69. ^ ส่วนบุคคลความสามารถพื้นฐานสำหรับโครงการโครงการและบริหารการลงทุน (PDF) สมาคมการจัดการโครงการระหว่างประเทศ (IPMA) 2015. ISBN  978-94-92338-01-3.
  70. อัลเบิร์ต แฮมิลตัน (2004). คู่มือขั้นตอนการบริหารโครงการ TTL Publishing, Ltd. ISBN 0-7277-3258-7 
  71. ^ PMBOK 4h เอ็ด . 2551. หน้า. 443. ISBN 978-1933890517.
  72. ทอม เคนดริก. ชุดเครื่องมือการจัดการโครงการ: 100 เคล็ดลับและเทคนิคในการทำให้งานสำเร็จลุล่วงฉบับที่ 3 หนังสือ AMACOM, 2013 ISBN 9780814433454 
  73. ^ Curlee แวนด้า (2011) เสมือนสำนักงานบริหารโครงการ: Best Practices, วิธีการพิสูจน์
  74. ^ Khazanchi, ดีพัค (2005). รูปแบบของการบริหารจัดการโครงการที่มีประสิทธิภาพในโครงการเสมือน: การศึกษาสำรวจ สถาบันบริหารโครงการ. ISBN 9781930699830. เก็บถาวรจากต้นฉบับเมื่อ 2013-10-23 . สืบค้นเมื่อ2013-10-22 .
  75. ^ Velagapudi, Mridula (13 เมษายน 2012) "เหตุใดคุณจึงไม่สามารถหลีกเลี่ยง Virtual Project Management 2012 เป็นต้นไป" .

ลิงค์ภายนอก