Professor Roger Aucoin
Project Review and RevisionsDear Professor,Looking back through the various documents that detail the development of the project I did for thiscourse, and taking into account what I have learned from you throughout this class, I now see severalareas where I would like to make revisions.
Vendor Selection Process
he vendor selection process set forth in the Project
echnical Background Report document is, I nowbelieve, unrealistic. Most companies have a definitive hardware source for their computerinfrastructure, and in the event systems werent available on time from the vendor, introducing adifferent vendor into the mix poses a number of problems. Worse, depending upon a number of subtleissues surrounding differences in the hardware, a significant refactoring of the I
support infrastructuremight be required.
he better approach, I believe, is to build sufficient time info the project to reasonably accommodatedelivery delays and to provide sufficient moneys in the contingency fund to cover the higher cost of paying for rush assembly and delivery.
hat the vendor might not deliver equipment on the promiseddate should definitely be included in the Risk Assessment.
he progress reporting frequency I initially chose in the Formal Project Proposal, wherein the PM wasresponsible for sending a weekly status update, is too infrequent given the duration of the project.Based on the granularity of the tasks, I think the project could go from being on-track to being in need of de-escalation inside of a week.
his suggests to me that the project would be better served by the PMsending daily status updates.
In the Formal Project Proposal I give the likelihood of the server hardware not being delivered onschedule as
. I now think it should be
, as looking at the results of several actual I
projectsand having a number of conversations with PMs have shown that vendors often miss their deliverydates. Additionally, the trigger of notification from the vendor that the shipment date has slipped or