เล่าเรื่องตอนที่ 2 > Planning & Design

หลังจากที่ผู้บริการ Sign-Off Project Proposal ส่งกลับมาให้ PM แล้ว สิ่งที่ PM จะทำต่อคือ

• Kick-Off Meeting คือการเรียกประชุมผู้ที่เกี่ยวข้องทั้งหมดเพื่อให้ข้อมูลโครงการที่จะทำทั้งหมดและตอบข้อซักถาม
• บางหน่วยงาน(เช่นที่บริษัทฯ)จำเป็นต้องแจ้งฝ่ายที่ดูแล IT Security ให้มาร่วม Review เอกสารและขั้นตอนต่างๆด้วย เสมือนทำ IT Internal Audit
• PM เป็นผู้ให้ข้อมูลและตอบข้อซักถาม
• แจ้ง Timeline และวัน Go Live ให้ทีมรับทราบ

หลังจาก Kick-Off Project ไปแล้ว, สิ่งต่อมาที่ PM ต้องทำคือการทำ Planning & Design




PLANNING

1. Communication Management
2. Role and Responsibilities Management
3. Risk Management
4. Procurement Management
5. Financial  Management
6. Quality Management
7. Resource Management
8. Roll out Approach Management
9. Change Management

DESIGN

1. System Diagram
2. Context Diagram
3. ER Diagram
4. Prototype

การ Planning เป็นการทำแบบ Pro-Active หรือการกำหนดวิธีการแก้ปัญหาล่วงหน้า, หากเกิดปัญหาขึ้นเราจะแก้ไขตามที่เรา Plan ไว้, ตามแต่สถานะการณ์ เรามักกำหนด Template คร่าวๆดังนี้

Communication Management - Template 

Template นี้จะอธิบายว่า PM จะสื่อสารเนื่องในโอกาสอะไรบ้าง, จะทำอย่างไร และใช้ช่องทางการติดต่ออย่างไร

Fields Description
Topics > หัวข้อเรื่อง
Deliverable > สิ่งที่ต้องทำหรือนำเสนอ
Description > คำอธิบาย, อ้างอิงหรือแตกรายละเอียดจากหัวข้อ Deliverables
Delivery Method > รูปแบบหรือช่องทางการนำเสนอ เช่น Meeting, E-Mail etc
Frequency > รอบหรือระยะเวลาในการทำ By Case, By Weekly or By Monthly
Owner > ผู้ที่ต้องทำ
Audience > ใครคือผู้รับฟังหรือผู้รับข้อมูล

ยกตัวอย่าง
Project Kick-Off > PM จะเรียกทุก Stakeholders ที่เกี่ยวข้องเพื่อ Brief รายละเอียดของโครงการทั้งหมดให้ฟังและตอบข้อซักถาม
Project Review > PM อาจขอนัดประชุมทุกเดือนเพื่อ Review Project (ทำหรือไม่ทำก็ได้แล้วแต่ความเหมาะสม)
Incidents > เป็นหน้าที่ของ Lead IT แต่ละส่วนที่ต้องรายงานทุก Incidents ที่กระทบกับ Time/Cost ให้ PM รับทราบ อาจจะทาง E-Mail หรือโทรศัพท์ก็ได้
Project Status > เป็นการ Update Status ให้ทุก Stakeholders รับทราบ อาจส่งเป็นรายงานผ่านทาง E-Mail เป็น Weekly หรือ Monthly แล้วแต่ความเหมาะสม

Role and Responsibilities Management - Template 

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

Fields Description
Position > ตำแหน่งงานในโครงการ
Role & Responsibility > งานที่ต้องทำหรือรับผิดชอบ

Risk Management - Template

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

Fields Description
Category > แยกเป็นแต่ละ Events ที่จะเกิดขึ้นได้
Description > อธิบายรายละเอียดของ Events นั้นๆ
Critical Impact > Events นั้นๆกระทบกับโครงการขนาดไหน Low, Medium หรือ High
Method > ช่องทางที่จะใช้ในการติดต่อ E-Mail, Call, Meeting etc
Make Decision > ใครจะเป็นผู้ตัดสินใจ Events นั้นๆ

ยกตัวอย่าง
Task Delay > เกิดความล่าช้าในงานที่ทำ เช่น Coding น่าจะเสร็จไม่ทันตามกำหนด Developer ต้องรายงานไปยัง Team Lead หรือ System Analyst จะทาง E-Mail หรือทางโทรศัพท์ก็แล้วแต่ และ Team Lead หรือ System Analyst ก็รายงานตรงไปยัง PM, PM เองก็ต้องบันทึก Log ไว้และหาทางแก้ปัญหาต่อไป บางเรื่องที่ Critical เป็น Low หรือ Medium ตัว PM อาจหาวิธีแก้ปัญหาหรือ Work Around ได้ แต่บางเรื่องที่เป็น High อย่างที่บอกถ้ากระทบทั้งเรื่องเวลาและ Cost ต้อง Escalate ปัญหาขึ้นไปให้ Project Owner หรือ Project Sponsor รับทราบและให้คำตัดสินใจลงมา
Out of Resource > เป็นเรื่องใหญ่ เพราะบางโครงการถ้า Internal Resource มีปัญหาเรื่องเวลา, ทำให้ไม่ทัน ทางผู้มีอำนาจอาจฟันธงว่าให้ทำโอที หรือ Worst Case มากกว่านั้นก็ให้ Outsource เข้ามาทำแทนเลย Case By Case

Procurement Management - Template

Template นี้จะแสดงรายละเอียดการจัดซื้อต่างๆที่โครงการต้องใช้ โดยแสดงรายละเอียด, ระยะเวลาที่ต้องดำเนินการ

Fields Description
Category > หมวดหมู่ที่เราต้องจัดซื้อมีอะไรบ้าง HW, SW หรืออื่นๆ
Description > แจงรายละเอียดให้เข้าใจว่าคืออะไร
Period > ช่วงระยะเวลาที่ต้องดำเนินการ (ตรงส่วนนี้จะเป็นประโยชน์กับทาง บช.ที่ต้องเตรียมเงินเพื่อชำระหนี้จะได้ไม่กระทบ Cash Flow ของบริษัทฯ)
Notes > หากมีเงื่อนไขการชำระเงินอื่นๆให้ระบุให้ครบ เช่น เครดิต 30 วัน, 60 วัน เพื่อฝ่ายการเงินจะได้นัดชำระเงินได้อย่างถูกต้อง).

Financial  Management - Template

Template นี้จะคล้ายๆ Procurement Management แต่จะ Details ไปในรายละเอียดปลีกย่อยของการจ่ายเงินจริงๆ เช่น กลุ่มที่ต้องมีการจ่ายแบบ Partial แบ่งจ่ายเป็นงวดๆ อย่างการจ้าง Outsource ที่มีการจ่ายเงินตาม Phase

Fields Description
Category > หมวดหมู่ที่เราต้องการจ่าย แยกเป็นเรื่องๆที่ต้องจ่ายทั้งหมดตลอดโครงการ
Description > รายละเอียดเพิ่มเติมเพื่อให้เข้าใจว่าเป็นการจ่ายค่าอะไร ถ้าสามารถระบุลึกลงไปว่าจ่ายให้แก่ใครก็จะยิ่งดี
Est.Amount > จำนวนเงินที่เราต้องจ่ายเมื่อถึงกำหนดชำระ
Pay Period > ช่วงระยะเวลาที่เราต้องชำระ (เพื่อให้ บช.เตรียม Cash Flow ให้เกิดสภาพคล่อง)

Quality Management - Template

Template นี้จะบอกขั้นตอนที่เราใช้ในการควบคุมคุณภาพของงานที่เราจะทำ เพื่อให้โครงการมี Deliverable ที่มีคุณภาพ, ลดความผิดพลาดที่จะเกิด ทำให้โครงการสามารถ Go Live ได้โดยไม่มีปัญหาหรือมีน้อยที่สุด

Fields Description
To Do > สิ่งที่เราจะทำเพื่อควบคุมคุณภาพงาน
Description > ขยายความสิ่งที่เราจะทำหรือเหตุผลที่เราต้องทำ
Handle By > ควบคุมดูแลโดยใคร (ผู้รับผิดชอบ)

ยกตัวอย่าง
Analyze Requirements > คือการเอา Requirements ที่ Key Users บอกมาวิเคราะห์หาแนวทางหรือข้อสรุปเพื่อแก้ปัญหา บางครั้ง Requirements หลายๆอย่างอาจแก้ปัญหาได้ด้วย Solution เพียงอันเดียว, ทำให้ไม่เกิดความซ้ำซ้อน และประหยัดเวลาการทำงานขึ้น
Unit Testing > การทดสอบการทำงานเป็น Unit ย่อยๆ เพื่อให้ควบคุมความถูกต้องโดยรวมได้ดีขึ้น
Prototype > มีการทำตัวอย่างเพื่ออธิบายภาพรวมให้ Key Users เข้าใจ, เพื่อให้เข้าใจประเด็นตรงกัน ลดความผิดพลาดในการสื่อสาร
Sign-Off > เพื่อเป็นการยืนยันการทำงานใน Phase ต่างๆโดยยอมรับกันทุกฝ่าย
Issue Log > เป็นการ Confirm ว่าแต่ละ Issue ที่เกิด PM ไมได้มองข้าม พร้อมจะเคลียร์และแก้ปัญหาที่คั่งค้างให้หมดไปก่อนจะ Go Live

Resource Management - Template

เป็นTemplate ที่คอนข้างซับซ้อน เพราะเราต้องกรอกข้อมูลของแต่ละ Resource ดังนี้

• สีเขียว > สำหรับช่วงเวลาที่กำหนดให้กับ Project ได้
• สีเหลือง > 50:50 อาจจะได้หรือไม่ได้ ขึ้นกับ Load ของ Resource นั้นๆ
• สีแดง > ช่วงเวลาที่ไม่สามารถให้กับ Project ได้

หลังจากที่เราได้ Template นี้ต้องเอาไป Map กับ WBS (Work Breakdown Structure) ของแต่ละงานที่ Require Resource เพื่อดูว่า Resource ณ.ช่วงเวลนั้นเพียงพอที่จะทำงานต่อหรือไม่?

Roll out Approach Management - Template

Template นี้จะแสดงวิธีการที่เราจะ Roll Out ระบบใหม่ไปยัง User ได้อย่างไร, แต่ละวิธีมีข้อดีข้อเสียและความเสี่ยงในระดับที่ต่างกัน PM จะต้องวางแผนในการ Roll Out ให้เป็นอย่างดี โดยคำนึงถึงความเป็นไปได้ให้มากที่สุด

Fields Description
Method > วิธีการที่จะ Roll Out ระบบ
Method Description > อธิบายลายละเอียดเชิงลึกให้ผู้อ่านเข้าใจวิธีการมากขึ้น
Critical Impact&Risk > ระดับผลกระทบกับโครงการและความเสี่ยง
Time > ระยะเวลาในการดำเนินการ

ยกตัวอย่าง
Big Bang Adoption > คือการเปลี่ยนแบบหน้ามือเป็นหลังมือ, เปลี่ยนจากระบบเก่าเป็นระบบใหม่เลย เป็นวิธีการที่รวดเร็วแต่มีความเสี่ยงสูง หากระบบนั้นๆมีการทำงานที่ไม่เหมือนเดิมและไม่ได้อบรมการใช้งานแก่ User อย่างเพียงพอ
Parallel Adoption > คือการเปลี่ยนแบบคู่ขนานคือทำงานทั้งระบบเก่าด้วยและระบบใหม่ เกิดความซ้ำซ้อนในการทำงานเพราะต้องทำงานอย่างเดียวกันทั้งสองระบบ แต่มีความเสี่ยงต่ำ หากระบบใหม่ล้มเหลว ก็ยังสามารถกลับมาทำระเก่าต่อไปได้
Pilot Conversion > คือการเอาระบบใหม่ไปทดสอบใช้งานกับบางหน่วยงานที่เลือกขึ้นมาก่อน หากล้มเหลวจะมีผลกระทบกับบางหน่วยงานเท่านั้น
Phase  Adoption > คือการเอาระบบใหม่เพียงบางระบบติดตั้งใช้งานก่อนและเปิดให้ใช้ หลังจากนั้นจึงทยอยระบบต่อๆไปเพิ่มเข้ามาใน Phase ต่อๆไปจนจบ

Change Management - Template

Template ที่บอกขอบเขตการทำ Change Management ว่าระดับไหนใครต้องทำ

Fields Description
Method > การทำโดยวิธีไหน เช่น เข้า Change Management Team หรือโดยตัว PM เองเท่านั้น
Scope of Work > อะไรบ้างที่ต้องดำเนินการ แตกรายละเอียดเป็นข้อๆไปในแต่ละ Method นั้น
Critical Impact > ระดับผลการทบขนาดไหน เพื่อให้สามารถระบุ Method ที่จะทำได้

ยกตัวอย่าง
Change Management Team > หมายถึง Change นั้นต้องมีผลกระทบตั้งแต่ระดับ Medium และ High คือมีผลกระทบทั้งเรื่อง Time และ Cost ทำให้ Scope ของโครงการเปลี่ยนไป จึงต้องให้ Change Management Team มาพิจารณาว่าสมควรจะทำ Change Management หรือไม่?
PM > คือการที่ PM วิเคราะห์ดูแล้วเป็น Change เล็กๆที่อาจมีผลกระทบบ้างเล็กน้อย เป็นที่ยอมรับได้ ใน Case ที่กระทบอาจสามารถขอคำแนะนำจาก Project Owner เพื่อขอ Authorized ดำเนินการต่อด้วยเหตุผลอันสมควร


System Diagram

เป็น Diagram แรกที่ PM จะใช้ Brief ให้ Stakeholders เข้าใจระบบการทำงานหรือระบบงานที่จะทำขึ้น เพื่อให้ทุกฝ่ายเข้าใจตรงกัน PM อาจทำขึ้นมาเองหรือให้ทีม Developer ช่วยทำขึ้นมาให้ก็ได้

Context Diagram

Diagram ที่แสดงการไหลของข้อมูลไปยัง Entities ต่างๆเพื่อให้เข้าใจระบบงานที่จะทำออกมามากขึ้น

ER Diagram

เป็นการแตกย่อย Context Diagram ให้ลึกลงไป เพื่อ Review การทำงานภายใต้ Module ย่อยๆ

Prototype 

เป็นการ Draft Output เช่น Screen Layout หรือ Reports Layout ออกมาดูคร่าวๆ เพื่อให้ทีม Review และอาจปรับแก้บางส่วนตามความเหมาะสม

หรือ Case ที่ Output เป็น Web ก็คือการทำ Web Mock up

อย่างที่บอก..ใน Phase ของการทำ Planning นี้เป็น Pro-Active คือการวางแผนเพื่อรองรับกับปัญหาที่จะเกิด เพื่อลดความขัดแย้ง เพื่อเพิ่มความเข้าใจในสิ่งที่จะทำ Templates ที่ยกตัวอย่างเป็นแค่บางส่วน บางคนอาจมี Templates ที่ใช้มากกว่านี้ซึ่งก็แล้วแต่ความเหมาะสมหรือการใช้งานขององค์กรนั้นๆเอง

Phase นี้ขอจบแค่ตรงนี้ก่อน..

เล่าเรื่องตอนที่ 1 > PMP/PMO คืออะไรกันน่ะ ???

Project Management Professional                (การบริหารโครงการอย่างมืออาชีพ)

คอร์สนี้บริษัทส่งไปเรียน..ค่าอบรมแพงมาก เกือบหกหมื่นบาท/คน สำหรับการอบรม 3 วันรวม Workshop ผู้สอน(Instructor) ต้องมีใบ Certificate ถึงจะสอนได้ ตอนที่เรียนไม่มีคอร์สภาษาไทย, อังกฤษล้วนๆฟังหูซ้ายเข้าไปวนในสมองกลวงๆ3-4รอบแล้วค่อยออกหูขวา.. คนสอนเป็นคนจีนมาเลเซียหรือจีนสิงคโปร์นี่แหละ บินมาสอน 3 วัน, สอนเสร็จบินกลับ ค่าตัวน่าจะแพง แต่ค่าเรียนที่จ่ายก็ไม่เบาเหมือนกัน เฉพาะที่บริษัทฯส่งมาเรียนก็ 6 คนเข้าไปแล้ว รวมอาหารกลางวันในโรงแรมด้วย..เรียนฟรีแถมอิ่มสบายท้อง แค่ปวดหัวตึบๆๆๆตอนเรียนแค่นั้น เรียนก็ยากพอแล้ว ต้อง Translate ความรู้เข้าสมองเป็นภาษาไทยอีก..

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

อีกคำคือ PMO - Project Management Office เป็นการบริหารโครงการหลายๆโครงการในเวลาเดียวกัน เสมือนเป็น Upper Level ของ PMP คือการจัดสรรทรัพยากรให้เพียงพอต่อการทำโครงการต่างๆ ณ.เวลาเดียวกัน โดยอาศัยข้อมูลของแต่ละโครงการมาวิเคราะห์เพื่อจัดการทรัพยากรที่มีอยู่ให้มีประสิทธิ์ภาพมากที่สุด ซึ่งจะยังไม่ขอกล่าว..

Project Life Cycle 

ทั้งที่เรียนมา.. ทั้งใน Web หรือที่อ่านเจอ, บางทีก็บอกมา 5 บางอันก็บอกว่า 6 การแบ่ง Phase ต่างๆใกล้เคียงเหมือนๆกัน ขออธิบายตาม Phase ที่ทำงานจริงละกัน..อันเนี้ย Work สุดและ กระชับ ไม่เยิ่นเย้อ

• Initial Management
• Planning Management
• Execution Management
• Monitor and Controlling Management
• Closing Management

Project ที่ทำๆมาแบ่ง Phase การจัดการออกเป็น 5 Phase แค่นี้ ขออธิบายแต่ละ Phase ให้ฟังว่าต้องทำอะไรบ้าง หลังจบ Phase ต้องได้อะไรออกมา

ก่อนจะพูดถึง Phase ต่างๆขอยกตัวอย่างแหล่งที่มาของ Project หรือ Project Source ก่อน คือมีมาจาก

1. BU หรือหน่วยธุรกิจ/ฝ่ายต่างๆ Request ขึ้นมา
2. Road Map ขององค์กรเองหรือ Road Map ของแผนก IT ทั้งระยะสั้นและระยะยาว
3. ฟ้าประทาน ที่บริษัทฯจะใช้คำนี้เมื่อได้รับคำสั่งตรงให้ทำ ซึ่งมักกระทบกับ Project Plan ที่เราทำอยู่ เพราะต้องมาจัดสรรทรัพยากรที่มีอยู่จำกัดและ Project Timeline ต่างๆที่ต้องโดนเบียด

เมื่อเราได้ Project ที่ต้องทำมาแล้ว, เราต้องเอาแต่ละ Project มาเริ่มทำทั้ง 5 Phases โดยต้องอาศัยเครื่องไม้เครื่องมือเข้ามาช่วยจัดการ เริ่มขั้นตอนที่ 1

เป็น Phase แรกที่ต้องเริ่มทำ, งานส่วนใหญ่เริ่มที่ Project Manager เราจะเริ่มจาก

• คุยกับผู้บริหาร BU นั้นๆในสิ่งที่เค้าต้องการหรือปัญหาที่เกิดขึ้นในแผนก
• คุยกับ Key Users ถึง Daily Operations หรือวิธีการที่เค้าทำอยู่

2 ขั้นตอนแรกนี้, วิธีการเก็บข้อมูลขึ้นกับแต่ละบุคคลอาจใช้วิธีการจด การเขียน แต่สำหรับอิชั้นใช้เครื่องมือตัวนึงคือ MindMap แตกแขนงปัญหาและความต้องการต่างๆแทนการจด

รูปที่ 1 - ตัวอย่าง MindMap

ConceptDraw V. 8.0.2 เป็น Tools ตัวหนึ่งที่มี Features การเขียน Mindmap , Project Management และทำ Chart ต่างๆในตัวเดียวกัน

• เริ่มทำ Project Proposal หรือเอกสารนำเสนอโครงการเพื่อให้ผู้บริหารอนุมัติ โดยต้องมีรายละเอียดคร่าวๆในเอกสารดังนี้
• Background - อธิบายความเป็นมาคร่าวๆของระบบเดิมที่ทำอยู่ว่า คือระบบอะไร ทำอะไรได้บ้าง เกี่ยวข้องกับใคร ผลลัพท์คืออะไร ใครเอาไปใช้งานต่อ เป็นต้น..
• ปัญหา/อุปสรรค - แจกแจงว่าระบบที่ทำอยู่มีปัญหาหรืออุปสรรคอะไรบ้างที่ทำให้ใช้เวลาและทรัพยากรบุคคลในการทำงานมากขึ้น
• Objectives - อธิบายเป้าหมายหรือวัตถุประสงค์ที่เราต้องทำโครงการนี้ขึ้นมาด้วย ว่าทำเพื่ออะไร?
• User Requirements - เขียนความต้องการของ BU เป็นข้อๆทั้งหมด
• แนวทางการแก้ปัญหา - PM เองต้องวิเคราะห์ปัญหา/อุปสรรคดังกล่าวว่ามี Solution ใดบ้างที่จะเข้ามาช่วยแก้ปัญหา อาจมีแค่วิธีเดียวหรือหลายวิธีก็ได้, PM จะต้องแจกแจง Solution ทั้งหมดที่แก้ปัญหาได้เพื่อเป็นข้อมูลในการตัดสินใจของผู้บริหาร (พึงระลึกเสมอว่า PM ไม่ใช่คนตัดสินใจเลือก Solution ที่จะมาแก้ปัญหา)
• Project Scope - ต้องบอกขอบเขตที่ชัดเจนว่าขอบเขตของโครงการอยู่ตรงไหน, ทำแค่ไหน โดยที่หากมี Request เพิ่มเติมเข้ามา เราจะมาดูว่ายังอยู่ในขอบเขตที่เรากำหนดหรือไม่? หากไม่ สิ่งนั้นเป็นสิ่งที่จำเป็นต้องทำหรือเปล่า? นั่นคือการทำ Change Management ในลำดับต่อไป มีผลกระทบกับเวลาและงบประมาณหรือเปล่า? ถ้ากระทบ ต้องเข้าที่ประชุมเพื่อหาข้อสรุป
• Deliverable - อธิบายว่าอะไรคือผลลัพท์หรือ Output ที่จะได้หลังจากโครงการสำเร็จหรือ Go Live ออกไปแล้ว เช่น 
• จะมี HW อะไรเพิ่มขึ้นมาบ้าง(Server, Clients), Application
• SW อะไรติดตั้งเพิ่มขึ้นมา (Web, Application etc..)
• Training Course อบรมการใช้งานแก่ใครบ้าง
• Service ที่จะเกิดขึ้น
• System Diagram - PM ควรเขียน System Diagram เพื่อให้ผู้อ่านเข้าใจในระบบที่จะทำได้ดียิ่งขึ้น
• ER Diagram - หรือ Data Flow Diagram ก็เป็นอีกอันหนึ่งที่ PM ควรมีไว้ในเอกสาร เพื่อให้ผู้อ่านเข้าใจการไหลของข้อมูลไปยัง Entities ต่างๆ
• Project Organization - PM ต้องจัดวางโครงสร้างของผู้ที่เกี่ยวข้องกับโครงการในตำแหน่งต่างๆเพื่อให้ผู้บริหารเห็นชอบ เพื่อจะกำหนด Role/Responsibilities ของแต่ละตำแหน่งต่อไป  
  
• Contact Person Info. - ลงรายละเอียดชื่อนามสกุล/ตำแหน่ง/เบอร์โทรศัพท์/E-Mail ของทุก Stakeholders ที่อยู่ในโครงการ เพื่อการติดต่อประสานงาน (รวมทั้ง Vender ด้วยถ้ามี)
• Timeline - เพื่อบอกช่วงเวลาต่างๆของแต่ละ Phase ว่าจะเริ่ม/เสร็จสิ้นช่วงใด
• Cost - บอกค่าใช้จ่ายคร่าวๆโดยประมาณที่ต้องใช้ในโครงการทั้งหมด (มันแสดงเฉพาะฝั่งของค่าใช้จ่ายทั้งโครงการเท่านั้น)
• Business Case - จริงๆมันก็คือการแสดงค่าใช้จ่ายทั้งหมดของโครงการ เพียงแต่แยกให้เห็นรายละเอียดของทั้ง Benefits และ Expenses ที่ได้รับและต้องจ่ายในช่วงระยะเวลา 3 ปี) 
• Benefits - หมายถึงถ้าโครงการนี้สำเร็จ บริษัทฯจะได้รับผลประโยชน์อะไรบ้าง? โดยต้องคำนึงถึงทั้งที่วัดได้และวัดไม่ได้ เช่น ทำงานได้เร็วขึ้น เราก็ต้องประมาณว่าเร็วขึ้นแล้วคำนวณเป็นเงินคร่าวๆได้เท่าไหร่? 
• Expenses - ค่าใช้จ่ายทั้งหมดที่โครงการต้องจ่าย

Deliverable ใน Initial Phase ก็คือ Project Proposal โดยมีหน้าสุดท้ายเป็นฟอร์มที่มีช่อง Approve พร้อม ให้ผู้บริหารเซ็นต์ Approve ให้เริ่มทำโครงการได้

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

Project Proposal จึงเป็นเอกสารฉบับแรกของโครงการที่เกือบทั้งหมดจัดทำขึ้นโดย PM

• ระยะเวลาในการจัดทำไม่ควรเกิน 2 Weeks 
• เผื่อเวลา 1 Week สำหรับการ Approve (ที่บริษัทฯเรียก Sign-Off Project Proposal)
• การแก้ไขต่างๆใน Project Proposal จะยังไม่บันทึก Log 
• การที่ผู้บริหาร Sign-Off Project Proposal หมายถึงการยอมรับในรายละเอียดของ Project Proposal ทุกหัวข้อ, PM สามารถใช้อ้างอิงขอบเขตการรับผิดชอบในภายหลังได้ 
• ในทางปฏิบัติ.. PM ฝ่าย IT และ PM ฝ่าย BU จะ Sign-Off ทุกหน้าของ Project Proposal(ปกติมีประมาณ 10-15 หน้า) เพื่อเป็นการยืนยันต้นฉบับ และหน้าสุดท้ายจะเป็นการ Sign-Off ของ Project Sponsor และ Project Owner ถึงจะถือว่า Project ได้รับการ Approve แล้ว

PM ฝ่าย IT >Project Manager ที่ดูแล Resource ทางฝ่าย IT เช่น เจ้าหน้าที่ไอที, Application 

PM ฝ่าย BU >Project Manager ที่มีอำนาจสั่งการให้ Key Users ฝั่ง BU เข้าร่วมหรือให้ความเห็นได้

Project Owner >หมายถึง Director หรือผู้บริหารระดับสูงที่ดูแล BU นั้นๆ

Project Sponsor >หมายถึงผู้บริหารระดับสูง, ผู้มีอำนาจในการสนับสนุนงบประมาณให้แก่โครงการ

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

นอกเรื่อง..
ตอนที่มาร่วมทีม Project ใหม่ๆ ก็ดูเอกสารเดิมๆที่เค้าทำกันมาพบว่า

• แยกแต่ละเรื่องเป็น Excel 
• ไม่มีการทำ Project Proposal 
• ใช้เวลา Meeting กันมากเกิน, เพราะไม่มีการบันทึกเป็น Log File 
• กรณี PM คนเก่าออก, คนใหม่ที่มารับงานก็งานเข้า กว่าจะปรับตัวหรือ Update เพื่อทำต่อ ยากมากเพราะไม่มี Background ให้อ่านเลย

เลยเข้ามาปรับวิธีการใหม่, คนอื่นทำไงไม่รู้ ตัวเองนำร่องก่อนแล้วแชร์ให้ PM คนอื่นอ่าน ได้ผล มีคนเริ่มเห็นความสำคัญและทำตาม ก็เริ่มจากทำเหมือน IS แหละ ทำเอกสารตัวแรก Project Proposal หลังจากได้ Sign-Off จะเริ่มเอกสารตัวที่ 2 ที่ใช้เวลาทำนานสุด(จนจบโครงการ) นั่นคือ Project Document

Project Document 

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

End..