Slashdot Mirror
Project Management Methodology for IT Operations?
sleeperservice asks: "There are a multitude of books, tools, and educational programs that deal with managing development projects. Whether you subscribe to IBM's Rational Unified Process or maybe SEI's Capability Maturity Model, whether you read Tom DeMarco's Peopleware or possibly Brooks' Mythical Man Month, there's something out there for you. However, most of these deal with projects that have a heavy amount of development, often new development associated with them. What about the folks in Operations? Let's say you need to upgrade your Oracle-based data management system for 1000 non-technical users? Or maybe you need to migrate your enterprise off of Outlook/Exchange and onto an alternative? What pointers are out there that Slashdot readers have used in such situations?"
One methodology that is gaining popularity for larger organizations is IT Service Management. It started in the uk, and is now being followed internationally. From the bit I've seen of it, it doesn't look harmful. Jury's still out on whether it's helpful.
--(())
In Germany the Government developed a "V Modell", that has to be used in Governmental projects. Very complicated but useful for software development. Teutonic cruelity.
And the first sentence says: "There are a multitude of books, tools, and educational programs that deal with managing development projects."
Am I the only one who thinks that development projects and operations are so different that they're mutually exclusive?
Indeed, one definition of a project I heard is anything that isn't operations.
At the bottom of the
Based on my experience in the software industry, you don't have to go as far as to pick one of these pre-packaged development ideologies. You really need just three things, and in my experience, nobody bothers to even go this far.
(You can see how well I live up to my own standards here.)
To get a team of programmers to work together, one must actually implement the physical communication they need to mesh together and produce something that's greater than the sum of the parts. That means you need a method for bringing new programmers up to speed, and for allowing existing programmers to change projects or to contribute to projects, in a way that doesn't rely on other programmers (especially if those other programmers no longer work there). The three items listed above are all you really need.
The key is to actually do these things...in my 12 years in the software industry, I've seen these things done properly exactly zero times, and was even fired once after the company president told me they were never going to do anything like this, and that it wasn't needed anyway. Eeek.
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
Now the actual process itself isn't horrible, it actually probably will end up giving you a better end product if you are attempting to keep a large development team organized and productive ...the only problem is:
...the only problem is the Rational Tools make these tasks near impossible.
Rational Tools Suck. Badly.
The entire Rational Toolset is bloated, unintuitive, and you will probably spend more time in beasts such as Requisite Pro and Clear Quest than you do actually programming or fixing bugs.
Yes, specs are important, bug tracking is important, design and modeling are important
ce n'est pas un Sig.
It's wise to remember that we're working in a field which is fundamentally engaged with the question of how to build things from zeroes and ones. In effect, we're defining the physics of a new universe. Thus we're bound to create new ways of talking about what that means, and since language is based on metaphor, we typically proceed by adapting terms from other disciplines.
So, in the case of methodology for example, it's quite accurate to say that we are making a "study of methods," even if that fact happens not to be apparent to some of the people using the term. When it comes to application, the term has come to mean "a body of related methods," which in its own way seems a distinctive and useful extension of the original meaning. And, by the way, we can no longer simply use the word method since that has acquired its own distinctive meaning in object-oriented programming.
But yeah, "apply a methodology?" Probably doesn't mean what the speaker thinks it means.
Parity: What to do when the weekend comes.
You are correct, but the scale is a bit more fined-grained than that.
I think that many people in the IT business have some kind of project-itis because the only type of operations management (yes, one of the "sciences" under which projects as well as mass production resides) strategy seems to be in project form.
If I was to look for more material outside the thin and narrow environment of software production, I would look into the older and more established industries. They have been doing some kind of organized operations management for somewhere around 100 years now and might have a clue on what to do (and not do).
Other hints may also be provided by the modern, but rooted [privilege access joke goes here], quality assurance community.
The problem is finding the intelligent, capable people, and convincing them to stay at the job. At least in a big organisation I used to work just after uni, where grads would get rotated to different functions across IT, the best people would opt for development roles and quit really fast if put in operations/support.
Of course this is not meant to degrade ops people or the work they do. It's just that the work doesn't have the glamour associated with coding, at least in the eyes of recent compsci grads.