Schedule a meeting across several time zones

I am assuming that most of the people who are working with world wide clients, vendors, and colleagues must have the knowledge of time zone and time difference.

Now let's have a quick view on how to pick a proper time to schedule a meeting across several time zones.

The first thing you need to know is which time zone each attender is located. I am in GMT+8, Mumbai is in GMT+5.5, Luton is in GMT, Bellevue is in PST (GMT-8).

Then, prepare a timing sheet like below:

And pick a proper time for the meeting.
The cells with red background mean they are pretty bad timing for the people located there. So if I pick up the time 21:00~22:00 in Taipei time, it probably is the best time to have all the people to meet together. Some of them need to get up earlier, and some need to rest later.

In this case, guys in US Washington state need to join the meeting at 6 AM, guys in Japan will have the meeting at 10 PM to 11 PM.

Some more thought about Quality-Cost-Delivery

Quality, Cost, and Delivery (Schedule), the three most important elements for a project, become a triangle force form inside a circle.

Ideally the full-balance force form looks like below:

Imagine cost is not an issue, quality is the most important, and the schedule is flexible. Then the force form become below:

But normally client is pushing the deliver date, or client delay the handoff but still want the package to be handed-back at the same time. Which means the delivery date is not negotiable. Then how worse the project could be? Add more resource to ensure the quality? Keep the same resource but loss some part of quality?

工程師在專案開始前該提供什麼協助

最近一個新的專案要開始之時，管理階層指派了一位未曾執行過該類型專案的管理者來負責該專案。幾位熟稔該類型專案的工程師被指派協助分析該專案的預期工作量。

這專案與過去做過的專案類似，因此沒有新專案的不明確性，但它又不是完全與過去專案一模一樣的專案，因此也有些不明元件必須被分析與了解。

工程師該提供什麼資訊？

1. 元件類型總表：詳列各種不同類型的元件，並說明這些元件屬性
2. 各元件的產品總數
3. 某些特殊元件下各個項目所具有的子元件數及總數
4. 各種不同元件的預期產能（平均每人每小時可以產出多少單位的元件）
   
5. 如果時間允許，列出所有特殊元件的問題，以使專案團隊了解所有不確定性以及風險

基本上1~4點一定樣詳盡，第五點通常不宜太早進行，除非該專案已經篤定會進行，並且離專案真正開始還有足夠的時間。

然而，偶爾我會見到某些工程師過於執著於提供第五點的資訊，第1~4的資訊卻未能及時完整的提供，導致專案的明確度不能提早確定，於是專案團隊對於所給定的時間是否合理，應該投入多少設備與人力來進行，遲遲無法有信心的完成分析與規劃配置，想要添購設備或招募人力，也無法及早進行。

被指派協助分析的工程師，應該要有一種體認，了解自己的角色是什麼，了解專案團隊在哪些時刻需要的資訊是什麼。在此刻，工程師就好比業務跑客戶端推銷業務時所搭配的 pre-sales 一般，是來輔助專案團隊及管理者，補足專案管理者在技術細節上的弱點，提供完整且可信的資訊與數據，好讓專案的分析與規劃能夠儘早且正確的被完成。

何謂專案

有些人對於專案的定義不是很清楚，甚至容易與常態性的管理事物混淆在一起。簡單的說，專案是指在一定時間內，為了完成特定目標的組織活動。好比說一家做進出口貿易的中小企業，如果老闆擬定了一個目標，要業務與相關行銷人員針對年終至隔年農曆過年期間進行某一產品的進口促銷方案，這就可以被當作一個專案來看待。

因此，專案包含了以下的幾個特性：

1. 明確的目標
2. 特定的時間（明確的開始與結束時間）
3. 非重複性（非日常例行姓事務）
4. 特定的人員
   

視應用的領域不同，專案的複雜度與組成要素也會有不同。小至學校裏的各班可自由發揮的校慶園遊會，雖比較像個活動事件，但也可用專案的角度來加以管理；大至一項新產品的開發至成品產出，或是一棟摩天大樓的規劃至完工，都可用專案管理的方式加以有效率的管控。

哪些事務不屬於專案管理的範疇？例行性事務，例如公司總務或行政人員每日每日的例行性事務，發放薪水、三節禮金、勞健保管理等；系統管理員每日的系統維運工作；學校老師年覆一年的教學工作等。簡言之，屬於重複的例行性工作事務並不屬於專案管理的範疇。

如果看一個產品的某一版本，他的規劃直至產出的過程是一個專案；但如果把焦點放在這個產品線是會持續延續下去，例如 2.0 版開發將至最後完工階段，便會開始研發下一個 3.0 的新版，那麼這個產品線本身應屬於一個計畫（Program）而不是專案。

Triangle of project QCD

When a project is running, what will you do to balance the triangle of QCD?
Q=Quality, C=Cost, and D=Delivery

We all know we wanna make more money from a project. But if the quality is too bad, you probably won't get any money.

When the project is phasing into another stage, you probably find out you'd better to add some more human resources or hardware resources. But it will bring more cost.

If you can not add more resource, but also need to remain the higher quality, then it might bring some impacts on the delivery date.


For a project management, there are many phases and tasks need to be take care. But the most simple way is to balance the QCD triangle.

What do you think about that?

The Killing Point of a Project

Joseph Philips, the Director of Education for Project Seminars, has an interesting description for the project phase deliverables and examing the project status and project advancement. He said, "The idea of killing a project at phases is why phase completion is also called a kill point."

Well, I do think it's quite interesting. The point to kill a project, project team, or the project manager?