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?"

Comments

IT Service Management

[(nil)]

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.

--(())

Start with SIMPLE, FUNCTIONAL methodology...

[ulatekh]

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.

1. Design documentation (i.e. what we're supposed to do)
2. Source-code comments (i.e. what we did)
3. Commit e-mails (i.e. how it changed over time)

(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.

RUP = The Devil.

[newdamage]

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:

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 ...the only problem is the Rational Tools make these tasks near impossible.

Re:Methodology == "Study of Methods"

[starfishsystems]

I'm inclined to agree. Technical language can be embarrassingly ponderous, especially when used imprecisely by management and others who don't quite know what a term means but want to give the impression of expertise. My current favorites are:

• utilize - You mean "use"?
• architecture - A fairly precise term in system engineering, its common meaning, like art, merely invites debate.
• granular - As in "a more granular approach." Used correctly, means that the granules are more evident, ie larger. In recent practice, intended to mean that the granules are smaller, for which the correct term is fine-grained.
• leverage - The verb "to leverage." Commonly used to demonstrate that the speaker is illiterate.
• going forward - The prepositional phrase. Can be safely removed from any context without loss of meaning.

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.