BUT!
I went to school at Purdue and we did have to take a series of classes on the Systems Development Life Cycle. Back then it was just called SDLC and was an ongoing process of Analyze, Design, Implement, Test, and Evaluation. Then Evaluation could cycle back into Analysis. It’s a logical thought process for how to develop/deploy new systems or projects:
Purdue was good in that they taught us how to build systems, how to write the code, how to support the hardware, how to do the network, etc, etc. It was a very well rounded education and in your last year or so you picked your direction and went with it. I picked Systems Administration, and this was before learning how to use Windows was a matter of course. (I was the last year who had to learn COBOL for the programming language.) But they did give us a pretty good rundown of how to run projects and how to build things. Being logic-minded this came very natural to me and I’ve used it pretty extensively over the 14 years since.
I’ve run major projects at large companies doing implementations and migrations from existing technology, mainly through tools like MS Project and Visio. Everyone has their own way they use SDLC and one of the ways I’ve always used it (and seen it used) is to add a last step to go back and talk to your stakeholders periodically and go “Hey, you told us you wanted full redundancy for your mail servers. We’re doing X, Y, and Z and here’s how it does it. Does that meet the needs you were asking for?”.
NOT going back to the person who requested the project is a great way to ensure failure.
That being said, sometimes you have hard and fast requirements and your stakeholders truly don’t understand what they’re asking for. For example, one of my prior companies went through a rebranding process where we renamed the company and they wanted “everything” with the old name to be renamed. Of course, our internal AD domain was xyz.prv. You CAN technically rename a Windows domain, but who have you ever run into who thought that was a good idea?
We took the opportunity to go through a major re-architecture of the entire environment (globally), built out a whole new AD environment on what was then new technology (2008), putting everyone into a new global Exchange environment (2010), and move all servers/workstations into the domain. In other words, completely changed scope and turned what marketing people thought would be a 30 second change into a multi-year project. But it needed to be done and after presenting our findings we were able to get management to agree.
That’s where MS Project comes in and you start tasking out everything that needs to be done: ensure no duplicate names exist, come up with new AD design, new Exchange design, migration plan, concurrent running plan, etc. etc. Or “scope-creep” as we like to say 🙂
I couldn’t have run this project without knowing the SDLC and how to manage a project. I later learned that my process of Project Management was actually called Waterfall these days and it’s what most people are doing.
I guess the point of this article is to introduce you to SDLC/Waterfall and Project Management and that I think Sys Admins need to wear the many hats. Sure you can go on forever without knowing how to run a project, but if you expect to move up the tree of life and get promoted and expect to run things, you should probably know how to do things that are not traditionally part of your job. Another great example of this is scripting. You can say you’re not a programmer, but if you don’t know how to script or write Powershell, you’re probably hurting your career.
Next week, I’ll start talking about Agile and its use in Project Management. I’m not a fan, so it won’t be pretty.
Technical Savant 