วิวัฒนาการการจัดการโครงการ: การเริ่มต้นกับองค์กร

การเริ่มต้นเล่นโป๊กเกอร์ บริษัท ใหญ่ ๆ เล่นหมากรุก

คำพูดนี้โดย Don Dodge ผู้สนับสนุนนักพัฒนาของ Google สรุปความแตกต่างระหว่างการเป็นผู้จัดการโครงการในการเริ่มต้นกับองค์กร

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

ไม่ใช่ขาวดำทั้งหมด

ข้อแม้ประการหนึ่งก่อนที่เราจะเจาะลึกในหัวข้อนี้คือมีบริษัททุกประเภท คุณสามารถเรียกบริษัทที่มีพนักงาน 100 คนเป็นสตาร์ทอัพอีกต่อไปได้หรือไม่? จะเกิดอะไรขึ้นหากพนักงานเติบโตถึง 200 หรือ 300 คน บางครั้ง Uber ก็ยังถูกเรียกว่าเป็นสตาร์ทอัพในสื่อ อย่างไรก็ตาม ปัจจุบัน Uber มีพนักงาน 12,000 คน ความแตกต่างอีกประการหนึ่งคือการเริ่มต้นที่เริ่มต้นโดยนักศึกษาระดับปริญญาตรีนั้นแตกต่างจากการเริ่มต้นโดยผู้ประกอบการต่อเนื่องที่มีประสบการณ์กว่า 20 ปีในวิชาชีพที่อาจเคยทำงานในองค์กรมาก่อนและได้นำแนวปฏิบัติที่ดีที่สุดกลับมาสู่การเริ่มต้นใหม่

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

สตาร์ทอัพ vs. องค์กร

ด้วยข้อแม้นี้ ให้พยายามกำหนดสองสุดขั้วเพื่อวางพื้นฐานสำหรับการสนทนาของเรา สำหรับวัตถุประสงค์ของบทความนี้ ลักษณะของการ เริ่มต้น คือ:

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

ในอีกด้านของสเปกตรัม องค์กร จะมีลักษณะดังนี้:

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

การจัดการโครงการเริ่มต้น

ผู้จัดการโครงการ ≈ ผู้จัดการผลิตภัณฑ์

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

โอกาสสำหรับผู้จัดการโครงการในสตาร์ทอัพ

การตัดสินใจอย่างรวดเร็วและผลกระทบขนาดใหญ่

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

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

สิ่งต่าง ๆ ทำได้เร็ว

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

ง่ายต่อการปรับเปลี่ยนหรือหมุน

ความเร็วในการจัดส่งที่เท่ากันและการขาดการพึ่งพาช่วยให้ทีมเริ่มต้นสามารถเปลี่ยนหลักสูตรได้อย่างรวดเร็ว ตัวอย่างที่มีชื่อเสียงคือ PayPal ในช่วง 15 เดือนแรกนับตั้งแต่เริ่มก่อตั้งเป็นโซลูชัน "การเข้ารหัสสำหรับโทรศัพท์" Paypal ได้พลิกโฉม 5 ครั้ง ตลาดสำหรับการชำระเงินมีการเปลี่ยนแปลงอย่างรวดเร็ว และ PayPal ก็สามารถเอาชนะ eBay ได้ ซึ่งกำลังพัฒนาโซลูชันการชำระเงินของตนเองที่เรียกว่า Billpoint ความคล่องตัวของ PayPal ช่วยให้ผู้ซื้อและผู้ขายของ eBay สามารถดึงดูดผู้ซื้อและผู้ขายได้ดียิ่งขึ้น ส่งผลให้ eBay ได้รับ Paypal ในที่สุด

กระบวนการของไหล

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

ความท้าทายสำหรับผู้จัดการโครงการในสตาร์ทอัพ

ความรับผิดชอบไม่ได้ถูกกำหนดไว้อย่างสมบูรณ์

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

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

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

อำนาจต่อรองที่อ่อนแอ

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

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

ทางลัดสร้างปัญหาเดิม

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

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

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

ผลบวกลวง

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

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

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

การจัดการผู้มีส่วนได้ส่วนเสีย

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

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

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

การจัดการโครงการในองค์กร

ผู้จัดการโครงการ ≠ ผู้จัดการผลิตภัณฑ์

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

สำนักงานบริหารโครงการ (อปท.)

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

ในฐานะผู้จัดการโครงการในองค์กร คุณจะต้องติดต่อกับ PMO PMO แต่ละแห่งมีความแตกต่างกัน แต่สิ่งที่คุณอาจเผชิญคือ:

• กรอกแบบฟอร์มต่างๆ เพื่อเริ่มต้นและปิดโครงการ
• กำลังส่งงบประมาณเพื่อตรวจสอบ
• ให้การอัปเดตความคืบหน้าเป็นประจำ
• รับการลงชื่อออกจากเหตุการณ์สำคัญหรือขั้นตอนกระบวนการต่างๆ

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

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

โอกาสสำหรับผู้จัดการโครงการในองค์กร

ความน่าเชื่อถือ

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

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

ง่ายต่อการรวบรวมความต้องการ

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

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

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

สร้างหรือซื้อ

โอกาสที่ไม่สามารถใช้ได้กับสตาร์ทอัพคือการเติบโตผ่านการควบรวมและซื้อกิจการ (M&A) ปี 2018 ได้เห็นข้อตกลง M&A ที่สูงเป็นประวัติการณ์แล้วทั่วโลก ส่วนใหญ่ของแนวโน้มนี้คือข้อตกลงขนาดใหญ่เช่นการเข้าซื้อกิจการ Time Warner ล่าสุดของ AT&T ด้วยมูลค่า 85 พันล้านดอลลาร์ อย่างไรก็ตาม ข้อตกลงบางส่วนมีขนาดเล็กในแง่ของการประเมินมูลค่า และสร้างผลตอบแทนที่ดีกว่า ตามการศึกษาของ Harvard Business Review มีบริษัทสตาร์ทอัพขนาดเล็กจำนวนมากที่มีโซลูชันแบบจุดเดียวอยู่ที่นั่น และผู้จัดการโครงการในองค์กรควรระลึกไว้เสมอว่าบางครั้งการซื้อกิจการเหล่านั้นก็อาจสมเหตุสมผล แทนที่จะพยายามคัดลอกโซลูชันของตน ผู้จัดการโครงการอาจไม่ใช่ผู้ตัดสินใจในสถานการณ์ดังกล่าว แต่สามารถเป็นคนนำตัวเลือกนี้ไปใช้ในตารางได้

ความท้าทายสำหรับผู้จัดการโครงการในองค์กร

การอนุมัติใช้เวลานานกว่า

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

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

สื่อสารผิดพลาด

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

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

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

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

เคลื่อนไหวอย่างช้าๆ และอย่าทำลายสิ่งใดๆ

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

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

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

บทสรุป

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

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

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

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

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

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