What is a good standard set of IT Infrastructure Project Milestones?

August 11, 2014 8:01 AM

I've been tasked with developing a set of standard IT Infrastructure Project Milestones and I'm kind of at a loss on coming up with a standard. Basically we have weekly status slides (PPTs) that we fill out for EVERY project that's in flight at our company. I'm the PM for Infrastructure. I was using something pretty generic like: 1. Project Kick-Off 2. Requirements Review/Sign Off 3. Design 4. Development or Set Up/Configuration 5. Test Unit & UAT (Regression & System If Applicable) 6. Deploy (Pilot * Deploy Where Applicable) 7. Warranty All you IT gurus out there (and PMs!) can you help me develop something better that can be used as a standard?
posted by PetiePal to Technology (6 answers total)

Hmmm - have you reviewed either:

- ITIL
- MOF

They might be helpful.
posted by jkaczor at 9:35 AM on August 11, 2014

This one is new to me:

http://opensdlc.org/

The main problem, IMO is - do you want one process/framework to coordinate everything - jumping between Infrastructure/Operations and then into Development? How do you then handle product "customization" and/or "governance" instead of custom development?

Questions I ask fairly frequently, so still do not have all the answers....
posted by jkaczor at 9:38 AM on August 11, 2014

IT PM here - so I'd say that there are as many version of this type of thing as there are companies out there. Every place I've been does something a little different, all basic variations on what you've outlined above - with more or less detail depending on the culture of the organization, the regulatory environment in which you work (banking and healthcare have a lot of Info Security-related milestones, as you might expect), organizational maturity, etc. What I'm getting at is the answer should really come from within your organization - what are the key deliverables that various departments/functions provide to each project? Those should become the basis for defining your milestones.

You'll also find that they won't remain static - there will always be an exception to the rule, and over time some milestones will become less important while others spring up. If I were in your shoes, I'd schedule a few working session with key players in each functional area as well as some of your leadership team, and facilitate developing those milestones together. This method has the added benefit of including the people who will have to answer for them later!
posted by gorbichov at 12:56 PM on August 11, 2014

Seconding gorbichov's comment. Our structure is pretty close to what you show above, but of course, there are frequent exceptions.
posted by Chrysostom at 1:10 PM on August 11, 2014

Let's start with the scope: how big is this project?
posted by tgrundke at 1:54 PM on August 11, 2014

Is there a large variance in the size of projects where you are? A structure like that is great if the projects your place does is all of similar size, but I'm working at a place now where there are three large, year-long, dozens-of-people projects going on and several projects that are 3-4 days long for 1-2 people.

For a lot of the smaller efforts, imposing a structure like you propose may be more work than it's worth; for instance, many of the smaller projects at my place essentially combine design and development, since there's only one of each of us (I'm design and I sit right by the developer).

What you lay out is perfectly reasonable, but it should be able to be scaled down for smaller efforts if that's a thing at your work.
posted by pdb at 2:07 PM on August 11, 2014