เล่าเรื่องตอนที่ 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 นี้ขอจบแค่ตรงนี้ก่อน..