"You expect R&D give you the date for software release then let you have plan can start communication to NEC. But if we do not clearly know the bug how to plan the software release plan? is that my rough guess, and let you tell NEC later on change schedule after clarify need more time to debugging?
I cannot agree that without communication or understanding from NEC, then give a plan to you without solid support.
Or only start the communication with NEC after all on-hand bug finish debugging."
Here is an example of language barrier. Prior to this email, VC had discussed with HK on conference call about a rough delivery schedule contingent on getting debugging information in a timely manner from NEC. Then VC emailed: "Please do not ask me for a daily report or conf call when you have other bugs you can fix and there is no bottlenecks. When you have no more bugs, no more tests and you are waiting for me then we have a problem. Either I am not doing my job or the Software team is super fast and experienced in fixing SIP bugs."
For me, VC is clearly saying whatever firmware delivery schedule he gives to NEC, will depend on NEC providing the debugging information. Meaning he's setting expected deadline for NEC. While 3rd parties cannot be controlled easily, at least we can set their expectations and also CYA when Super VP cracks the whip. Meanwhile, there are other bugs HK can work on so they are not sitting around making no progress. They should work on finishing the bugs they can fix, and when the NEC information comes in, they should only have to address the NEC-dependant bugs before releasing the software
This concept of target schedule and dependencies seems to be as old as project management, and there are all sorts of tools like Gantt charts to map this dependency, yet I keep hearing the question over and over again. What's the disconnect here?
Source: Gantt Chart Biz
No comments:
Post a Comment