Lindstrom 1

To: From: Date: Re:

Professor Roger Aucoin Nate Lindstrom 06/26/2011 Project Review and Revisions

Dear Professor, Looking back through the various documents that detail the development of the project I did for this course, and taking into account what I have learned from you throughout this class, I now see several areas where I would like to make revisions.

Vendor Selection Process
The vendor selection process set forth in the Project Technical Background Report document is, I now believe, unrealistic. Most companies have a definitive hardware source for their computer infrastructure, and in the event systems weren t available on time from the vendor, introducing a different vendor into the mix poses a number of problems. Worse, depending upon a number of subtle issues surrounding differences in the hardware, a significant refactoring of the IT support infrastructure might be required. The better approach, I believe, is to build sufficient time info the project to reasonably accommodate delivery delays and to provide sufficient moneys in the contingency fund to cover the higher cost of paying for rush assembly and delivery. That the vendor might not deliver equipment on the promised date should definitely be included in the Risk Assessment.

Progress Reports
The progress reporting frequency I initially chose in the Formal Project Proposal, wherein the PM was responsible 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. This suggests to me that the project would be better served by the PM sending daily status updates.

Risk Assessment
In the Formal Project Proposal I give the likelihood of the server hardware not being delivered on schedule as low. I now think it should be moderate, as looking at the results of several actual IT projects and having a number of conversations with PMs have shown that vendors often miss their delivery dates. Additionally, the trigger of notification from the vendor that the shipment date has slipped or

Lindstrom 2 been missed is itself a risk; what if (as seems likely) the vendor does not send any such notification? I would like to replace it with a new trigger of the hardware not arriving on the scheduled day, and make sure that the scheduled day is included in the project with sufficient lead time that slippage does not have any immediate adverse impact.

Quality Control
While there is a data validation phase during the project, more quality control steps should have been included throughout the width and breadth of the project. For example, after building the servers, they should have been made to pass a quality control check before the project moved on to the next phase. Discovering what was at one point a small quality problem late in the project makes it instantly into a major quality problem, as issues like that are almost always much more costly and difficult to solve late in the project.

On the critical path of this project is the data migration and testing tasks, and I realized that while I have two system administrators assigned to this as resources, I only assigned a single DBA as a resource. I think it would be prudent to have two DBAs, as a significant disruption to the databases would cripple the project, as would the unexpected unavailability of the sole DBA resource. With two assigned the work might not proceed any faster, but at least a level of redundancy and thus reduced risk would be insured. I suppose the same argument could be made about Chander Kant, the resource assigned to user training; but (a) his job is more easily filled than the specialized role of DBA, and (b) user training is not on the critical path.

One particularly important practice which I need to incorporate into my earlier memos, and which I have been putting to use with great success in my job outside of college, is that of giving a deadline by which I ll follow up with a person if I haven t received their input, decision, etc. As you ve pointed out, omitting this when asking someone for something leaves it open-ended, and makes it easy for them to shelve your request indefinitely. In conclusion, I ve learned a lot about project management through this class, and these represent the more egregious examples of things that I d like to change. Respectfully, Nate Lindstrom

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.