After 30 odd years of being in the field of Information Technology; one might have guessed that I had picked up a thing or two.

 

When a project does not go as planned something called a root cause analysis needs to be performed.  Basically why did the project fail?   Was it poorly planned, poorly funded, poorly thought out, were the deliverable s too much or too little? 

 

 

There are a host of things that should be considered before embarking on any project.  One really needs to play the “what if” game.  We are not striving for analysis to paralysis here but, we do need to know that everything is well thought out and a fallback plan is in place.

 

Is the project necessary? 

What are the driving factors for the project?

What are the deliverables?

What will the TCO (total cost of ownership) be?

What is the (Return on investment), ROI? 

How long to implement? 

What impediments to business will the project cause, if any? 

Are those impediments accounted for with workarounds?

What are the risk?

Are the milestones clearly defined and; expectations set with all members of the project?

Are the tasks clearly defined and assigned?

Is there a test plan to determine feasibility as well as to determine a baseline?

Is adequate documentation of the project occurring?

Are key players involved through a process like a change control committee?

Will training be necessary and if so; has that documentation been planned for and prepped?

If tweaking was necessary, what was it and why?

Did the project perform as expected, if not why not?

Did the project come in at or under budget?  If not why not?

 

 

Some manager’s think that upgrading to the newest latest greatest is the thing to do and press on.  I for one, have learned never be on the bleeding edge of technology.  I always wait until a service pack has been released, especially if Microsoft is any part of the equation. Never load Rev.0 into a production environment, unless you really don’t like your job or company as you will most certainly have to explain why as it most likely will fail.  As the sysadmin you really have to be able to tell your manager “no,” and back it up with sound logic and reasons.  Some will ask for the .0 not realizing the inherent dangers that go along with that.  You will be the one with the arrows in your back from the users, and the owners / manager  and CEO.  They wont see the software bugs as the issue, they most likely will blame you and or your staff, or anyone that had their hands in it.

 

The hallmark of a PM is to be able to communicate every aspect of the project with everyone involved.  To be able to manage their resources in such a way as to not have any wasted dollars or time.  The project should be on track and on budget at each and every milestone.  Having a good Gantt chart, or at the very least a good plan of the project in excel will help to keep you from getting off track.  There are no good surprises in business and hardly ever any good surprises with projects!

 

-Best to you and those that you care about.