Quartier International de Montréal

เหตุเกิด ณ เมืองมอนทรีออล แคนาคา … ในช่วงปี 2000 ไม่มีใครอยากจะอาศัยอยู่ในบริเวณพื้นที่ประมาณ 66 เอเคอร์ที่มีชื่อว่า Quartier International De Montreal เพราะว่าอะไรหนะหรอ? ก็เพราะพื้นที่ตรงนั้นเป็นเหมือนแหล่งเสื่อมโทรมของเมืองจากการวางตัวที่ไม่เป็นระเบียบเรียบร้อยของถนนและทางด่วนต่างๆ รวมถึงความทรุดโทรมของตึกรามบ้านช่อง

แต่หลังจากนั้น 5 ปี (2005) ด้วยโครงการฟื้นฟูเมืองขนาดยักษ์ ที่ดินผืนเดียวกันนี้กลับกลายมาเป็นสถานที่ที่หมายปองของทั้งชาวเมือง นักธุรกิจและนักท่องเที่ยว อสังหาริมทรัพย์ก็ขยายตัวอย่างต่อเนื่องด้วยตัวเลขจำนวนห้องพักและสถานที่อาศัยกว่า 1,000 ยูนิต (ทั้งสร้างเสร็จแล้วและอยู่ระหว่างการดำเนินการ) ราคาคอนโดมิเนียมที่ซื้อขายกันตอนนั้นต้องมี 2.5 ล้านเหรียญสหรัฐเป็นอย่างต่ำ โดยรวมแล้วการฟื้นฟูเมืองครั้งนี้ทำให้เกิดโครงการก่อสร้างต่างๆมากมายรวมเป็นเงินถึง 700 ล้านเหรียญสหรัฐ


ทั้งหมดนี้ต้องยกให้เป็นความดีความชอบของโครงการที่ชื่อว่า Quartier International De Montreal (QIM) ซึ่งนำโดย Clement Demers ที่สามารถบริหารจัดการเงินทุน 90 ล้านเหรียญสหรัฐกับเวลา 5 ปีทำให้เกิดสิ่งดีๆเหล่านี้ได้

• จัดการกับทางด่วน
• ยกเครื่องระบบท่อน้ำเสียและสะพานส่งน้ำ
• เพิ่มทางเท้าขึ้นอีก 40%
• ฟื้นฟูจัตุรัสวิกตอเรีย (Victoria Square)
• สร้างจัตุรัสสาธารณะแห่งใหม่ที่ชื่อ Place Jean-Paul-Riopelle
• ปลูกต้นไม้ใหญ่ 500 ต้น
• บูรณาการงานศิลปะและรูปปั้น
• ขยายโครงข่ายถนนคนเดินในร่ม

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

ด้วยความตั้งใจจริงของทีมงาน บวกกับความสามารถของ Demers ทำให้ Quartier International De Montreal เสร็จตรงเวลาและทำได้ตามวัตถุประสงค์ที่ตั้งไว้ทุกอย่าง จนในท้ายที่สุด Project นี้ก็ได้รับเลือกให้เป็น Project แห่งปี โดย Project Management Institute (PMI) ในปี 2005

ความท้าทาย

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

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

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

สุดท้าย เรื่องของงบประมาณจากภาครัฐที่จำกัดทำให้ QIM ต้องพยายามหาเงินเพิ่มเพื่อมาสนับสนุน Project นี้

QIM จัดการกับความท้าทายเหล่านี้อย่างไร?

เตรียมตัวอย่างดี

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

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

แบ่งงานเป็นส่วนย่อย

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

ส่วนที่สองคือ Demers แบ่งงานใน Project จริงๆออกเป็นส่วนย่อยๆอีกครั้งเพื่อให้งานต่อการบริหารจัดการ งานที่ถูกแบ่งออกมามีดังนี้ครับ

1. โครงสร้างพื้นฐานใต้ดิน เช่น ระบบกำจัดน้ำเสีย และระบบส่งน้ำ
2. โครงสร้างในชั้นใต้ดินและพื้นผิวดิน เช่น ที่จอดรถชั้นใต้ดิน ทางเดินเท้า ทางด่วน และช่องทางเชื่อมต่อระหว่างรถไฟใต้ดิน
3. โครงสร้างบนดินและงานศิลปะ เช่น สวนสาธารณะต่างๆ และการจัดการกับงานศิลปะของเมือง
4. โครงการพัฒนาอสังหาริมทรัพย์

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

ตรงนี้น่าสนใจนะครับ เราไม่จำเป็นต้องยึดติดกับการทำงานแบบใดแบบหนึ่งไปตลอดหรอกครับ ถ้าเห็นว่าอะไรไม่ดีไม่งามก็แก้ไขซะ ไม่ต้องรอไปแก้ใน Project หน้า มันไม่ทันกาลแล้วแบบนั้น Demers หัวสมัยใหม่นะครับ การทำแบบนี้คือหลักการ Agile Development เลยหละ (ปี 2000 Agile ยังไม่เกิดครับ)

จัดการเงินงบประมาณแบบใหม่

Project ต้องใช้เงินประมาณ 90 ล้านเหรียญสหรัฐ ตอนนั้นผู้สนับสนุนหลักคือรัฐบาลกลางแคนาดาและรัฐบาลรัฐควิเบกมีเงินให้แค่คนละ 30 ล้านเหรียญสหรัฐ บวกกับงบประมาณจากเมืองมอนทรีออลเองอีก 14 ล้านเหรียญสหรัฐ ยังขาดอยู่อีก 16 ล้านเหรียญสหรัฐแหนะครับ ทำยังไงดี?

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

นำเสนอผลการศึกษาถึงความคุ้มค่าของ Project นี้ให้กลุ่มคนเหล่านี้ดูอีกครั้ง ถ้า Project นี้ประสบความสำเร็จ Quartier International de Montréal จะกลายเป็นศูนย์กลางทางเศรษฐกิจแห่งใหม่ ไม่ใช่เฉพาะกับเมืองมอนทรีออล ไม่ใช่เฉพาะกับแคนาดา แต่ในระดับนานาชาติเลยทีเดียว และแน่นอนธุรกิจจะรุ่งเรื่อง และราคาที่ดินจะปรับตัวสูงขึ้นอย่างคาดไม่ถึงเลยครับ … รู้แบบนี้แล้ว ยอมจ่ายทุกคนครับ

ดูแลพนักงานอย่างดีที่สุด

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

ตัวอย่างที่ชัดเจนคือการที่ Demers จัดตั้งคณะกรรมการพัฒนาบุคคลกรของ QIM ขึ้นมาเพื่อช่วยพัฒนาทักษะการทำงานของพนักงานครับ พนักงานบางคนได้โอกาสเรียนรับทุนศึกษาต่อปริญญาโทจนจบ ในขณะที่บางคนเลือกที่จะสอบ Project Management Professional (PMP) ทั้งหมดนี้ทำให้ระดับความพึงพอใจของพนักงานต่องานอยู่ในระดับสูงมาก หลักฐานคือไม่มีใครในทีม QIM ลาออกเลยตลอดระยะเวลาห้าปีของ Project (สุดยอดไปเลย)

สร้างแรงจูงใจในการทำงาน

ข้อนี้เป็นความชื่นชมส่วนตัวของผมที่มีต่อ Demers ครับ ปรัชญาที่ Demers ใช้ในการทำงานคือ

“If you cut into the dream at the first difficulty, it will no longer be an inspiring project.”

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

Demers ไม่ยอมแพ้ต่ออุปสรรคที่เกิดขึ้นและเค้าพยายามอย่างเต็มที่ที่จะรักษาเป้าหมายที่ตั้งไว้ให้ได้เพื่อเป็นการสร้างแรงดลใจในการทำงานให้กับทีมงานที่เหลือทุกคน เหตุการณ์จริงที่เจอกับ QIM คือ จากวัตถุประสงค์ของ Project การออกแบบต้องยอดและวัตถุดิบที่ใช้ต้องเยี่ยม ทั้ง “ยอด” และ “เยี่ยม” ต้องใช้เงิน “เยอะ” ด้วยครับ (ฮ่าๆ) และแน่นอนเรื่องนี้เป็นการวัดใจ Demers ว่าจะเอายังไงในเมื่อมีทางเลือกแบบนี้

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

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

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

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

บทเรียนที่มีค่า

บทเรียนที่ดีที่สุดผมได้รับจาก Quartier International de Montréal คือเรื่องการไม่ยอมแพ้ต่ออุปสรรคนี่แหละครับ โดนใจที่สุดแล้ว หันมามองตัวเองแล้วถามว่า กับอะไรที่ทำอยู่แล้วเรารู้สึกว่าไปไม่ถึงไหน ไม่ประสบความสำเร็จอะไรเท่าไรเลย มันเป็นเพราะอะไร? เพราะเราตั้งความหวังไว้ต่ำ ไม่สร้างแรงจูงใจให้ตัวเอง แล้วก็ยอมแพ้อะไรง่ายๆใช่มั้ย?

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

หวังว่าเพื่อนๆจะได้เรียนรู้สิ่งดีๆจาก Quartier International de Montréal เหมือนกันครับ

ต่อจากบทความที่แล้วครับ วันนี้ลองมาดูวิธีป้องกันไม่ให้ Project ถูกยกเลิกกัน

Project Termination กับแนวทางการป้องกัน

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

เรื่องที่เกี่ยวข้องกับธุรกิจ (Business)

• ขาดแคลนทรัพยากร — Lack of resources
• ขาดการสนับสนุนจากผู้บริหาร — Lack of executive support
• ไม่มีความต้องการทางการตลาด — Absence of need

เรื่องที่เกี่ยวข้องกับลูกค้า (Customer)

• ไม่ได้รับความร่วมมือจากลูกค้า — Lack of user involvement
• ความคาดหวังที่เกิดจริง — Unrealistic expectations
• ไม่มีความต้องการทางการตลาด — Absence of need

เรื่องที่เกี่ยวข้องกับความต้องการ (Requirement)

• ความต้องการของลูกค้าไม่สมบูรณ์ — Incomplete requirement
• การเปลี่ยนแปลงความต้องการ — Changing requirements

เรื่องที่เกี่ยวกับการจัดการภายใน (Internal Process)

• ขาดการวางแผน — Lack of planning
• ขาดการบริหารจัดการที่ดี — Lack of IT management
• ขาดความเข้าใจในเทคโนโลยี — Technology illiteracy

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

Business — By Monitoring Business Assumption

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

เรื่องนี้จะเน้นไปที่การติดตามความต้องการ ความเปลี่ยนแปลง และแนวโน้มทางธุรกิจ ซึ่งผมมองว่าคนที่ต้องรับผิดชอบนั้นมีมากกว่า Project Manager แน่นอน อย่างน้อยๆต้องมี Product Manager และหัวหน้าของฝ่ายอื่นๆในบริษัท เช่น Sales, Marketing, Research and Development (R&D) และ Vice President หรือ CEO นู่นเลยครับ ทุกคนที่กล่าวมาควรจะต้องมีการประชุมกันสม่ำเสมอ (อาจจะทุกเดือนหรือทุกสามเดือน) เพื่อวิเคราะห์ธุรกิจ มองหาโอกาสและความเสี่ยงต่างๆ แล้วเปรียบเทียบสิ่งเหล่านั้นกับสถานะปัจจุบันของบริษัทและสินค้าที่มี สุดท้ายมองหากลยุทธ์ใหม่ๆที่ตอบสนองความเปลี่ยนแปลงทางธุรกิจนั้น ทั้งหมดนี้คือการบริหารจัดการกลยุทธ์ (Strategic Management) ครับ

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

1. การวิเคราะห์สถานการณ์ปัจจุบัน (Strategic Analysis)

ขั้นตอนนี้จะเน้นไปที่การวิเคราะห์สถานการณ์ปัจจุบันทั้งในส่วนของปัจจัยภายนอก (External Environment) และปัจจัยภายใน (Internal Evnironment) ที่มีความเกี่ยวข้องกับเรื่องธุรกิจและกลยุทธ์ของบริษัทครับ ผลลัพธ์ที่ต้องการจากขั้นตอนนี้คือข้อมูลที่บอกเราได้ว่าโอกาสและความเสี่ยงทางธุรกิจใหม่ๆมีอะไรบ้าง แล้วตอนนี้บริษัทเรามีข้อดีข้อเสียและความพร้อมระดับไหนในการตอบสนองปัจจัยภายนอกเหล่านั้น

1.1 ปัจจัยภายนอก (External Environment)

ปัจจัยภายนอกสามารถวิเคราะห์ได้อยู่สองระดับดังนี้ครับ

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

• ปัจจัยทางเศรษฐกิจ (Economic Factor)
• ปัจจัยทางสังคม (Social Factor)
• ปัจจัยทางการเมือง (Political Factor)
• ปัจจัยทางเทคโนโลยี (Technological Factor)
• ปัจจัยทางสิ่งแวดล้อม (Ecological Factor)

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

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


Industry Environment: เป็นการวิเคราะห์ที่เข้ามาใกล้ตัวนิดนึงครับเพราะมันเกี่ยวกับธุรกิจของเราโดยตรง ผลลัพท์ที่ต้องการก็เหมือนเดิมครับมองหาโอกาสและความเสี่ยง หลักการที่นิยมมากเลยคือ Five Forces Model ของ Michael E. Porter ครับ หลายคนคงคุ้นเคยแล้วเนอะ

1. ความเสี่ยงจากผู้เล่นรายใหม่ในธุรกิจ (Threat of New Entrants)

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

2. อำนาจต่อรองของผู้ขาย (Power of Supplier)

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

3. อำนาจต่อรองของผู้ซื้อ (Power of Buyer)

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

4. ความเสี่ยงจากสินค้าทดแทน (Threat of Substitute Products)

มีโอกาสแค่ไหนที่สินค้าหรือบริการของเราจะถูกแทนที่ด้วยสินค้าชนิดอื่น เช่น ปากกากับดินสอ แท๊กซี่กับรถไฟใต้ดิน MS Office กับ Open Office และอื่นๆอีกมาก ปัจจัยข้อนี้อันตรายมากครับ บางครั้งอาจจะทำให้บริษัทเราจบเห่ได้เลย จำตัวอย่างจากกรณีเพจเจอร์กับโทรศัทพ์มือถือได้มั้ยครับ? นั่นแหละฮะเพจเจอร์มีช่วงรุ่งๆอยู่ได้ไม่นาน สุดท้ายก็หายไปแบบเงียบๆเพราะการมาของโทรศัทพ์มือถือ

5. ความเข้มข้นในการแข่งกันกันในธุรกิจ (Intensity of Rivalry among Competitors)

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

1.2 ปัจจัยภายใน (Internal Environment)

ผมว่าแทบทุกคนต้องเคยได้ยินคำว่า SWOT ใช่ปะ? SWOT Analysis เป็นเครื่องมีที่ช่วยในการวิเคราะห์บริษัทเทียบกับธุรกิจที่โด่งดังมากครับ SWOT ย่อมาจาก Strengths (S) + Weaknesses (W) + Opportunities (O) + Threats (T) ครับ จริงๆแล้วเราหา O กับ T ได้แล้วหละครับ ก็จากการวิเคราะห์ปัจจัยภายนอกไง ตอนนี้ก็เหลือแค่ S กับ T ซึ่งเป็นเรื่องภายในของบริษัทเราล้วนๆ

การวิเคราะห์หาจุดแข็งและจุดอ่อนของเรานั้นควรจะพิจารณาไปที่หลายส่วนหลายปัจจัยครับ เช่น ความสามารถพิเศษ (Core Competencies) วัฒนธรรมองค์กร (Corporate Culture) การตลาด (Marketing) การเงิน (Finance) การวิจัยและพัฒนา (Research and Development) การบริหารจัดการบุคลากร (Human Resource) เป็นต้นครับ ผมคงจะไม่ขยายความส่วนนี้ไปมากกว่านี้นะครับ เข้าใจว่าทุกคนคงมองเห็นภาพแล้ว

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

2. การวางแผนและมองหากลยุทธ์ใหม่ๆ (Strategic Formulation)

หลังจากได้ข้อมูลมาแล้ว เราก็มามองหาว่าเราจะวางกลยุทธ์ต่อไปอย่างไร เรื่องใหญ่มากครับ เราอาจจะต้องมองกลับไปที่วิศัยทัศน์ (Vision) ของบริษัทกันเลยทีเดียวว่ามันตอบสนองความเปลี่ยนแปลงทางธุรกิจได้มั้ยแล้วค่อยมองหาแนวทางของกลยุทธ์เช่น การพัฒนาสินค้าตัวใหม่ (Product Development) การพัฒนาตลาดใหม่ (Market Development) การสร้างนวัตกรรมใหม่ (Innovation) การควบกิจการกับคู่แข่ง (Horizontal Integration) การร่วมมือพัฒนาสินค้ากับบริษัทอื่น (Joint Venture) และอื่นๆอีกมากครับ

ผมไม่ขอลงรายละเอียดนะครับ ดูว่ามันจะเกินขอบเขตของบทความไปไกล ฮ่าๆ

3. การเปลี่ยนแผนให้เป็นการทำงานจริง (Strategic Implementation)

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

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

Customer — By Customer Expectation Management

ทั้งหมดของเรื่องนี้คือการสื่อสาร (Communication) ครับ สำคัญมาก ขอเล่าเหตุการณ์ที่เกิดกับตัวเองให้เป็นตัวอย่างเล็กน้อยครับ

ตื่นเช้ามาอย่างแรกที่ผมทำคือ … ล้างหน้า แปรงฟัน (แหงหละ) แล้วจากนั้นท้องจะร้องทันทีครับ ฮ่าๆ ที่บ้านผมจะมีน้องสาวกับแม่ที่ไปตลาดเป็นประจำซึ่งกิจวัตรที่ผมต้องทำอย่างตรงเวลา (7.15 น.) คือลงมาบอกน้องว่า

ผม: ฝากซื้อข้าวหน่อยดิ

น้องผม: จะกินอะไรหละ?

ผม: อืม … มีอะไรขายบ้าง?

น้องผม: ก็เหมือนเดิมนั่นแหละ โจ๊ก ข้าวมันไก่ หมูปิ้ง ข้าวเหนียวส้มตำ

ผม: เลือกยากหวะ … เอาโจ๊กละกัน ไม่ใส่ไข่นะ รีบมาแล้วกัน หิวมากกกก

ผมดูทีวีรอประมาณครึ่งชั่วโมง น้องก็กลับมา … มือเปล่า

ผม: (ตอนนั้นเริ่มเครียดล่ะ) โจ๊กอะ?

น้องผม: ไม่ขาย

ผม: แล้วไม่ได้ซื้ออย่างอื่นมาเลย?

น้องผม: ป่าว

จบบทสนทนาแต่เพียงเท่านี้

จากเหตุการณ์นี้ ความคาดหวังของผม (ในฐานะลูกค้า) คือ 1. โจ๊กนะ 2. ถ้าไม่มี เอาอะไรมาก็ได้ (หิวววว) แต่สิ่งที่ผมสื่อสารออกไปมีแค่ “โจ๊ก” สุดท้ายก็เลยไม่ได้กินอะไรซักกะอย่างเลย แล้วแบบนี้น้องผมผิดมั้ย? ก็ไม่นะ ผิดที่ผมมากกว่าที่ไม่ระบุความต้องการไปให้ชัดเจน คราวนี้ทีหลังผมเลยบอกเพื่อไว้สองอย่างตลอดเลยครับ จะได้ไม่ต้องทนหิวนาน

ความคาดหวัง (Expectation) กับความต้องการ (Requirement)

กับงานของเรา เราต้องให้ความสำคัญของความคาดหวังของลูกค้ามากๆครับ ขอย้ำอีกทีว่าความคาดหวัง (Expectation) นะครับไม่ใช่ความต้องการ (Requirement) เพราะผมคิดว่าความคาดหวังเป็นอะไรที่มากกว่าความต้องการครับ

ตัวอย่างจากเหตุการณ์ที่เกิดขึ้นจริงกับเพื่อนผมเองครับ เพื่อนผมรับเขียนโปรแกรมจำพวก Customer Relationship Management (CRM) – Help Desk ให้บริษัทหนึ่ง คือไปรับ Outsource มาจากเค้าอีกทีหนะครับ งานที่ทำออกมาได้ตาม Requirement ที่ระบุมาหมดเลยนะครับ แต่พอเอาไปนำเสนอลูกค้า เพื่อนผมเจอประโยคนี้ “นึกว่าจะเหมือน Siebel นะเนี่ยะ รู้จักป่าว Siebel หนะ” เพื่อนผมก็คิดในใจ อือ หือ แม่คุณเอางั้นเลยนะ (ฮ่าๆ) โชคยังดีครับที่ลูกค้าไม่ได้โวยวายอะไรมาก แต่ผมกำลังจะชี้ให้เห็นว่าถ้าเรามองข้ามความคาดหวังของลูกค้าในช่วงแรก เราอาจจะต้องน้ำตาตกในตอนหลังได้ครับ

การจัดการกับความคาดหวังของลูกค้า

ก็เห็นๆกันแล้วครับว่า ถ้าสิ่งที่ได้รับไม่ตรงกับสิ่งที่คาดหวังปัญหาก็ตามมา ดังนั้นเรามาลองหาทางป้องกันไม่ให้เหตุการณ์แบบนี้เกิดขึ้นกันดีกว่าครับ

1. มองหาความคาดหวังที่แท้จริง

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

2. ให้คำจำกัดความของความคาดหวังที่ชัดเจน

อย่าลืมครับว่าความคาดหวังนั้นมีความหมายกว้างกว่าความต้องการ ดังนั้นใน Project ของเรานอกเหนือจาก Requirement แล้ว เราต้องสื่อสารกับลูกค้าให้ชัดเจนในเรื่องของวันส่งงาน (Schedule) งบประมาณ (Cost) รวมไปถึงการบริการหลังการขายทั้งหลายแหล่ เช่น Service ต่างๆ, การทำ Maintenance และ Support, เมื่อมี Version Upgrade จะฟรีมั้ย? สำคัญมากครับ

3. สร้างความเข้าใจที่ตรงกันภายในบริษัท

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

4. ทำข้อตกลงทั้งหมดให้เป็นทางการ

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

5. เก็บความคาดหวังและความเปลี่ยนแปลงลงในเอกสารที่จับต้องได้

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

ดังนั้นไม่ว่าความเปลี่ยนแปลงจะมาจากที่ไหนพยายามจับลงเอกสารไว้ครับ เช่น Status Reports, Change Request, Meeting Minute หรือแม้แต่คำพูดและข้อความจากการสนทนาตัวต่อตัวหรือโทรศัพท์เราก็ควรจะสรุปออกมาเขียนเป็นอีเมล์ แล้วที่สำคัญคือเอกสารเหล่านี้ต้องถูกส่งให้ผู้มีส่วนได้ส่วนเสีย (Stakeholder) ใน Project ของเราทุกคนเพื่อแจ้งให้ทราบถึงความเปลี่ยนแปลงอันนี้ด้วยครับ

Requirement — By Operational Concept and Incremental Commitment

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

ส่วนในเรื่องของ Requirement Change อันนี้ผมพูดถึงหลายรอบแล้ว ซึ่งวิธีการที่ปรับใช้ได้ผลค่อนข้างดี (ทดลองมาแล้วด้วยตัวเองครับ) ก็คือการทำงานแบบ Incremental โดยเราควรพิจารณา Software Development Life Cycle แบบที่ยืดหยุ่นต่อการเปลี่ยนแปลง เช่น ถ้า Waterfall ไม่ตอบสนองเราในเรื่องนี้ได้ดีนัก ลองมองถึง Iterative หรือ Agile ดูครับ

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

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

Internal Process — By Project Management Office (PMO)

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

จากการสำรวจโดย KPMG นั้นเป็นที่น่าประหลาดใจว่าสาเหตุหลักที่ทำให้ Project ล้มเหลวคือการไม่มีการทำงาน Project Management ที่เป็นมาตรฐานถึง 32% มากกว่าปัจจัยที่เกี่ยวกับเทคโนโลยีโดยตรงด้วยซ้ำ และนี่คือข้อยืนยันถึงความสำคัญของมาตรฐานในการทำงานครับ

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

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

• Project Planning: แน่นอนครับ ไม่มีแผนงานจะทำงานให้เสร็จตรงเวลาได้อย่างไร? PMO ควรต้องกำหนดแนวทางการทำ Project Planning ของบริษัทก่อนครับว่า จะต้องมี Input/Output อะไรบ้าง เอกสารมีกี่ฉบับ หน้าตาเป็นอย่างไร ใครมีอำนาจหน้าที่ในการตรวจสอบและเซ็นอนุมัติ เป็นต้น
• Risk Management: เป็นส่วนที่คนมักจะมองข้ามเป็นประจำ แต่ Risk Management เป็นเรื่องสำคัญมากๆครับ เราต้องมีการระบุว่าใน Project นี้มีความเสี่ยงอะไรบ้าง เราต้องมองหาแนวทางป้องกัน (Mitigation) แนวทางแก้ไข (Contingency) แนวทางการจัดการกับความเสี่ยงแต่ละตัว (Risk Response) ไว้ด้วย เราจะได้มีภูมิคุ้มกันอีกชั้นนึงครับ
• Project Tracking: วางแผนทำงานแล้วต้องติดตามผลด้วยครับว่างานไปถึงไหน มีปัญหาอะไรเกิดขึ้นบ้างระหว่างการทำงาน เราควรมีมาตรฐานที่ดีในเรื่องนี้ว่าเราจะมีการประชุมเพื่อติดตามผลบ่อยแค่ไหน ใช้อะไรเป็นเกณฑ์วัดความคืบหน้าของงาน เอกสารที่เกี่ยวข้องจะมีหน้าตาอย่างไร เป็นต้น
• Development Guideline: อยากให้มีเอกสารที่จะบอกถึงการพัฒนาซอฟท์แวร์ที่ดีและเป็นระบบควรทำอย่างไร เริ่มตั้งแต่ Requirement, Design, Coding, Testing, Deployment, จนถึง Maintenance กันเลยครับ การทำงานจะได้มีคุณภาพสม่ำเสมอ

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

สรุป

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

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

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

ขอบคุณครับ

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

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

Project Termination กับ Project Failure

“Termination” แปลว่า การยกเลิก การสิ้นสุด เมื่อมารวมกับคำว่า “Project” ความหมายที่สื่อออกมามันค่อนข้างจะเป็นไปในทางไม่ดีนะครับ “การยกเลิกโครงการ” ฟังดูแล้วน่ากลัวจังเลย แต่ในความเป็นจริงแล้วนั้น การยกเลิกไม่ได้แปลว่าความล้มเหลวเสมอไป

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

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

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

เหตุการณ์สมมติกับชีวิตจริงก็ไม่ต่างกันมากนักครับ เมื่อมีเหตุการณ์ไม่คาดฝันหรือการเปลี่ยนแปลงอะไรขึ้นมา การยกเลิกโครงการ (Project Termination) เป็นเรื่องที่เกิดขึ้นได้ตลอดเวลาครับ

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

Project termination doesn’t equal project failure.

~ Barry Boehm, University of Southern California

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

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

สาเหตุที่ Project ถูกยกเลิก

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

1. ความต้องการของลูกค้าไม่สมบูรณ์ — Incomplete requirement (13.1 percent)

Project ที่ถูกยกเลิกด้วยสาเหตุนี้ให้อาจจะเกิดจากการจัดการที่ไม่ดีครับ เพราะว่า Requirement ยังไม่ชัดเจนทั้งในแง่ของการทำงานและลำดับความสำคัญก็ตะลุยทำงานไปก่อนแล้ว หรือในอีกกรณีหนึ่งคือ Project Manager รู้สึกมั่นใจกับ Requirement ว่าพร้อมจะเอาไปพัฒนาต่อได้แล้ว แต่ Project Manager จับสัญญาณความผิดปกติที่ว่าลูกค้าไม่ยอมที่จะยอมรับหรือตกลงเรื่อง Requirement ให้อย่างเป็นทางการซักที (ไม่ยอม Sign-Off) แถมดูๆแล้วลูกค้าคงไม่ยอมง่ายๆด้วยก็เลยเลือกที่จะยกเลิก Project ไปซะเลยก่อนที่จะเสียเวลาทำมาหากินไปมากกว่านี้ แบบนี้ถือว่ามีการบริหารจัดการที่ดีนะครับ

2. ไม่ได้รับความร่วมมือจากลูกค้า — Lack of user involvement (12.4)

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

3. ขาดแคลนทรัพยากร — Lack of resources (10.6 percent)

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

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

4. ความคาดหวังที่เกินจริง — Unrealistic expectations (9.9 percent)

สาเหตุนี้เกิดขึ้นได้กับทั้ง Project ที่มีการจัดการที่ดีและไม่ดีครับ สำหรับการจัดการไม่ดี Project นั้นก็ล้มเหลวในการประเมินและตรวจสอบระดับความพึงพอใจและความคาดหวังของลูกค้า เช่น ลูกค้าอยากให้ระบบ Enterprise Resource Planning (ERP) ของเราทำงานได้ใกล้เคียงกับ SAP ทางเราก็ดันตกลงกับลูกค้าเฉยเลย (ผมว่าเวอร์ไปเยอะนะครับนี่) ถูลู่ถูกังทำไปไม่นานก็ต้องเจ็บตัวเพราะลูกค้าไม่ปลื้มกับงาน

ในบางครั้ง Project ที่มีการจัดการที่ดีก็เสร็จได้เหมือนกันครับ แต่ส่วนใหญ่จะไม่เจ็บตัวมากนักเพราะว่าในระหว่างที่เราศึกษาความเป็นไปได้ของงานเทียบกับความคาดหวังของลูกค้า เราจะเห็นปัจจัยบางอย่างที่ทำให้เราต้องยกเลิก Project เช่น เทคโนโลยียังไม่พร้อม หรือมีสินค้าที่พร้อมใช้งาน (Commercial Off-The-Shelf: COTS) วางขายอยู่ในตลาดอยู่เยอะแล้ว (ทำไปก็ไม่คุ้ม) ครับ

5. ขาดการสนับสนุนจากผู้บริหาร — Lack of executive support (9.3 percent)

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

6. การเปลี่ยนแปลงความต้องการ — Changing requirements (8.7 percent)

ส่วนใหญ่แล้ว Project ที่ต้องถูกยกเลิกด้วยสาเหตุนี้มันมาจากการที่ใครคนใดคนหนึ่ง (บริษัทหรือลูกค้า) ไม่ยอมรับความจริงที่ว่าการเปลี่ยนแปลงทุกอย่างมีราคา เมื่อ Requirement หรือ Scope เพิ่มหรือเปลี่ยนแปลง ไม่ Schedule (เวลา) หรือ Resources (คนและงบประมาณ) ก็ต้องเปลี่ยนแปลงตามไปด้วย ซึ่งหลายครั้งลูกค้าไม่เข้าใจและไม่พยายามจะเข้าใจว่านี่คือความจริงที่เกิดขึ้น เช่น ขอเพิ่มงาน (Scope) แล้วไม่ยอมให้เลื่อนเวลาเสร็จ (Schedule) และ/หรือคน (Resource) เลย แบบนี้ก็ลำบากครับ

อีกมุมหนึ่งสำหรับ Project ที่มีการจัดการที่ดีจะถูกยกเลิกก็ต่อเมื่อมีการวิเคราะห์อย่างละเอียดแล้วว่าค่าใช้จ่ายจากการเปลี่ยนแปลงนั้น (Cost) มากกว่าประโยชน์ที่จะได้รับจากการเปลี่ยนแปลงนั้น (Benefit) ครับ

7. ขาดการวางแผน — Lack of planning (8.1 percent)

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

8. ไม่มีความต้องการทางการตลาด — Absence of need (7.5 percent)

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

9. ขาดการบริหารจัดการที่ดี — Lack of IT management (6.2 percent)
ข้อนี้ง่ายมากครับ Project ที่มีการบริหารจัดการไม่ดี (หรือไม่มีเลย) ควรจะถูกยกเลิกไป เช่น การวางแผนไม่มี การจัดการคนไม่มี การตรวจสอบติดตามผลการดำเนินงานไม่มี ไม่มีอะไรเลยแบบนี้ รับรองได้ว่าทำต่อไปก็ล้มเหลวแน่นอน 100 % ครับ

10. ขาดความเข้าใจในเทคโนโลยี — Technology illiteracy (4.3 percent)
ข้อสุดท้ายคือการที่ Project Manager หรือลูกค้าไม่มีความเข้าใจในเทคโนโลยีของงานที่ทำ ซึ่งถ้าจะมองกันจริงๆแล้ว Project นี้ไม่ควรได้รับการอนุมัติให้ทำตั้งแต่แรกแล้วด้วยซ้ำ

แล้วยังไงต่อ?

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

บทความหน้าเรามาว่ากันด้วยเรื่องวิธีการป้องกันไม่ให้ Project ถูกยกเลิก หรือถ้าเลี่ยงไม่ได้ก็ขอให้ยกเลิกอย่างสวยงามกันครับ

ขอบคุณครับ

ผมทำงานกับ Software Development Project มาเกือบ 8 ปีแล้วครับ งานหลักที่ทำมาตลอดจนถึงตอนนี้ก็เป็น Programmer แต่ช่วงประมาณ 3-4 ปีหลังมานี้ก็เพิ่มงานในส่วน Project Management เข้ามาด้วย แรกๆก็สนุกมากเลยนะครับ บอกกับตัวเองว่านี่แหละ … งานในฝัน

แต่ช่วงเวลาที่ผ่านมาผมก็เจอเหตุการณ์อะไรๆหลายอย่าง มันเริ่มทำให้ผมรู้สึกว่า Project Management เป็นเรื่องน่าเบื่อไม่ใช่เล่นเลยนะเนี่ยะ … อะไรทำให้ผมรู้สึกแบบนั้น

Changes

ผมขอยกให้เรื่องนี้เป็นเรื่องน่าเบื่ออันดับหนึ่งในดวงใจเลยครับ เพราะต่อให้เราใช้เวลาทำ Requirement Gathering กับ Requirement Analysis มากแค่ไหน หรือพยายามปรับใช้เทคนิคอะไรมาช่วยยังไง เราก็ยังหยุดยั้ง Change ไม่อยู่

ที่ผมเจอมามีทั้ง Change ตั้งแต่ Requirement Change, Design Change ขนาดว่า Technology Change ก็มีครับ มิหนำซ้ำ Change มาเกิดเอาตอนทำงานไปแล้วเกินครึ่งอีก ตัวอย่างจริงที่เจ็บปวดของผมเลยคือว่า เมื่อประมาณสามปีที่แล้ว ระบบที่ผมดูแลอยู่มีการเปลี่ยนแปลงครั้งใหญ่โดยเปลี่ยนจาก Windows Application มาเป็น Web Application

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

YOU will be responsible for ANY problems that happen because of it. …

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

เค้าให้เหตุผลว่าในช่วงเวลานั้น AJAX ยังเป็นเทคโนโลยีที่ใหม่และไม่ค่อยเสถียรเท่าไร ซึ่งทางทีมผมก็โอเคๆ ไม่ใช้ก็ไม่ใช้(วะ) สุดท้ายก็ต้องออกแบบหน้าเวปด้วยอะไรที่โบราณสุดๆ ใช้ยากมากๆ จนสุดท้าย …

ผ่านไปเกินครึ่งทาง (ครึ่งปีหลังจากนั้น) ท่านเค้าก็ทนไม่ไหวกับความห่วยของหน้าเวปก็เลยส่งเมล์มาบอกอีกรอบประมาณว่า

You are approved to use AJAX. Please apply it to our web as much as you can. …

เห็นเมล์นี้แล้วก็ … เพื่อนๆคงพอนึกสภาพตอนนั้นออกนะฮะว่าผมและคนในทีมจะวุ่นวายขนาดไหน นี่ยังไม่ต้องนับความเซ็งเป็ดส่วนตัวอีก นี่แหละครับหนึ่งในสาเหตุที่ทำให้ผมเบื่อ Project Management

Communication

งานที่ผมทำอยู่เป็นงานที่ต้องติดต่อกับเพื่อนร่วมงานที่อยู่ต่างประเทศครับ คือมี Development Team อยู่สองที่ ก็เลยมีอยู่บ่อยๆ (เกือบทุกวัน) ที่ต้องเขียนอีเมล์ส่งไปมาระหว่างกัน แน่นอนครับ ใช้ภาษาอังกฤษ แรกๆก็ดีนะฮะ เหมือนว่าได้ฝึกภาษาไปด้วยทำงานไปด้วย แต่พอเวลาผ่านไปนานเข้าๆ เริ่มเบื่อครับ ยิ่งถ้าต้องอธิบายอะไรในเชิง Technical ด้วยแล้ว … เศร้าครับ ผมเคยใช้เวลาครึ่งวันในการเขียนอีเมล์เพื่ออธิบายการทำงานของระบบกับชี้ให้เห็นถึงปัญหาใน Source Code ส่วนที่เค้าเขียนมา เหนื่อยมากครับ เขียนแล้วต้องตรวจทาน นั่งรีวิวกับเพื่อน แก้ไข วนไปวนมาหลายรอบกว่าจะแน่ใจว่าเค้าจะอ่านรู้เรื่อง ฮ่าๆ เหนื่อยครับ

ที่ยิ่งกว่านั้น ทุกสัปดาห์ทีมที่กรุงเทพกับทีมที่อยู่ต่างประเทศจะมีการประชุมทางไกลผ่านโทรศัพท์ (Teleconference) กันครับ นี่ก็ช่วงเวลาที่ทรมานเหมือนกัน เพราะต้องเข้าไปฟังอย่างตั้งใจและใช้ความพยายามอย่างมากที่จะจับให้ได้ว่าเค้าพูดอะไร ถามอะไร ต้องการจะสื่อสารอะไร ที่ยากคูณสองเพราะเพื่อนร่วมงานของผมเกือบทุกคนไม่ได้มาจากประเทศที่ใช้ภาษาอังกฤษอย่างเป็นภาษาหลัก นั่นหมายความว่าสำเนียงของเขาและเธอ สุดแสนจะบรรยาย แถมบางคนพูดเร็วยิ่งกว่าจรวด … ฟังไม่ทันครับ บางครั้งผมและเพื่อนก็นั่งมองหน้ากันแล้วก็ยิ้มๆ … เค้าจะเอาอะไรวะ? ฮ่าๆๆ

เป็น Project Manager ก็ต้องเตรียมตัวเตรียมใจรับสถานการณ์แบบนี้ด้วยครับ … นี่ก็เป็นสาเหตุว่าทำไม Project Management ถึงเป็นเรื่องน่าเบื่อสำหรับผม

Customer is god.

เราเคยได้ยินประโยคนี้บ่อยๆเลยใช่มั้ยครับ “ลูกค้าคือพระเจ้า” ผมหละเบื่อกับประโยคนี้จริงๆ ขอบอกก่อนว่างานที่ผมทำอยู่ผมไม่มีโอกาสได้เจอลูกค้าที่เป็น End User ที่ใช้ระบบจริงๆหรอกครับ ระบบผมไม่มีขายในเมืองไทยครับ ลูกค้าส่วนใหญ่อยู่ที่ทวีปอเมริกาเหนือกับยุโรป แล้วลูกค้าที่ผมพูดถึงคือใคร? ทีมผมให้ความหมายของคำว่าลูกค้าไว้ว่า ลูกค้าคือเพื่อนร่วมงานที่อยู่ต่างประเทศซึ่งทำหน้าที่เป็นคนดูแลพวก Requirement, Design และคอย Review งานให้ครับ เมื่อไม่เจอลูกค้าตัวจริงก็เลยคิดซะว่าคนกลุ่มนี้แหละคือลูกค้าที่เราต้องพยายามทำอะไร(ก็ตาม)ที่สนองความต้องการของเค้าได้อย่างไม่ขาดตกบกพร่อง

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

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

Don’t talk to me about management

เออ เอาเข้าไป แบบนี้ก็มีแต่งานเพิ่มขึ้นๆ น้อยครั้งมากๆที่จะบอกว่า “อันนี้ไม่ต้องทำนะ” จะว่าไป “ไม่ต้องทำ” นี่ก็ใช่ว่าจะดีนะครับ ในกรณีที่เราเสียเวลาทำไปแล้ว … มันจะเซ็งมากๆไม่แพ้กันแหละ ฮ่าๆ

… เฮ้อ นี่ก็เป็นสาเหตุว่าทำไม Project Management ถึงเป็นเรื่องน่าเบื่อสำหรับผม

Unrealistic Plan

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

มาตรฐานที่ว่าก็คือ CMMi อะไรพวกนั้น ต้องมีเอกสาร ต้องมี Peer Review ต้องมีการเก็บหลักฐานข้อมูลสถิติอะไรมากมาย ต้องมี Design Document ที่ผ่านการ Peer Review แล้วถึงจะเริ่มเขียนโค๊ดได้ หรือถ้าเจอว่ามี Bug เกิดขึ้นหนึ่งตัวก็ต้องกรอกข้อมูลลงระบบ Defect Tracking System … งานที่เป็น Administrative Task เยอะขนาดนี้แล้วจะเอาเวลาที่ไหนไปทำ Requirement กันหละครับเนี่ยะ

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

No Power, No Authority

ใครว่า Project Manager มีอำนาจล้นฟ้า? ผมขออนุญาตไม่เห็นด้วย(อย่างยิ่ง)ครับ หน้าที่หลักของ Project Manager คือเรื่องการสื่อสาร (Communication)และการอำนวยความสะดวก (Facilitation) ให้งานใน Project เป็นไปได้ด้วยดี Project Manager ไม่มีลูกน้องใต้บังคับบัญชาของตัวเอง และแน่นอนไม่มีอำนาจโดยตรงที่จะไปสั่งงานใครด้วย เพราะอำนาจและหน้าที่ทั้งหมดเป็นของ Functional Manager หรือที่เราเรียกกันว่า Line Manager นั่นแหละครับ

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

คิดไปคิดมา อาจจะเป็นเพราะ Leadership Skill ของผมห่วยแตกก็ได้นะ ฮ่าๆๆ แต่นี่ก็เป็นอีกสาเหตุหนึ่งที่ทำให้ผมเบื่อๆเซ็งๆในบางครั้งเวลาทำงานพวก Project Management

เบื่องานที่ทำอยู่กันมั้ยครับ?

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

เพื่อนๆหละครับ เคยเจออะไรที่ทำให้เบื่องานกันบ้าง ไม่จำเป็นต้องเกี่ยวข้องโดยตรงกับ Project Management ก็ได้นะครับ ถ้าอยู่ในเรื่องที่เป็น Software Development Project ก็ได้ เช่น เป็น Developer อาจจะเบื่อเขียนโค๊ด เบื่อทำ Unit Test ถ้าเป็น QA ก็อาจจะเบื่อเวลาเทสแล้วเจอบั๊กกระจาย หรือเบื่อลูกค้า เบื่อหัวหน้า เบื่อลูกน้อง เบื่อ …

ลองแลกเปลี่ยนกันดูนะครับ ผมมั่นใจว่ามีคนรู้สึกเหมือนกันเพียบเลย