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?"
Just keep the IT staff off slashdot and pr0n sites all day, and things should take care of themselves.
Yell loud. Yell even louder to make things happen quicker.
I've been involved as PM for a number of years in the operations and implementation space. The most common practices out there are related directly to PMI/PMP and ITIL standards...
"The Practice of System and Network Administration" by Limoncelli and Hogan.
The book I wish I'd had when I started doing this 35 years ago.
"Security Engineering" by Ross Anderson.
Even if you think you don't need it. Especially if you think you don't need it.
"If you always do what you've always done, you'll always get what you've always got."
The biggest problem you'll face is that people hate change. They worry about learning new things, about being replaced by computers, about all sorts of things.
The key to success is getting your users to accept the changes, and for that you need to communicate with them. Explain why the changes are needed, how it will affect them and how they are going to be assisted in dealing with the new setup.
The communication needs to be a two way thing as well. Ask them questions, ask if THEY'VE got any questions. Get their feedback and get them onside. If you can do that, you've only got to worry about getting the new system set up.
If ignorance is bliss, knock the smile off my face.
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.
--(())
ITIL
There is absolutely no substitute for intelligent, capable people. Even the best process is worthless if the people doing the work don't have a clue.
Personally, I'm a fan of treating every project uniquely. The process you use for a five minute report is vastly different than a system upgrade or a new web application.
This is a set of books on different aspects of IT Operations, and is widely used in the industry. Of course, some people misuse it to create a straight-jacket (MS, for one), and others use it to make a sarong (Sun, SGI), but the basic cloth is there (:-))
It's orthogonal to the CMU maturity model.
-dave
davecb@spamcop.net
ITIL stands for IT Infrastructure Library, and defines an IT Service Management structure that can be applied to IT Operations as an effective framework. There are two main areas within ITIL, Service Delivery and Service Support.
Service Delivery includes:
Service Level Management
Capacity Management
Availability Management
Financial Management
IT Service Continuity
Service Support includes:
Service Desk
Incident Management
Problem Management
Change Management
Release Management
Configuration Management (arguablely also part of Service Delivery)
If you apply an ITIL methodology throught IT Operations you will find that the IT operational projects are run more smoothly in a well controlled environment. You can google for a lot more information on ITIL, but I recommend certification, at least to Foundation level for anyone seriously interested in implementation. See also BS15000, the British Standard associated with ITIL which is expected to become an ISO (International Standard) in the future.
-- Pete.
Monochrome - Probably the UK's largest internet BBS
Here in the UK we use the PRINCE2 methodology (at least in out public bodies). Its a bit heavy on documentation... does the job well though.. http://www.ogc.gov.uk/prince2/
I work in the UK Civil Service, and we use (a loose form of) PRINCE2 as recommended by the Office of Government Commerce.
However, the trick is to know what of it to use and what not to. That comes with practice, experience and common sense. No methodology, however good, can replace these.
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
1. Obviously beta test the new system with a select group of people who will use the new system.
2. Explain the rollout of the new system during a company meeting and why you're doing it and what benefit it is to everyone. Explain that the first week on the system may be a bumpy ride, and that you're not afraid nor ashamed to revert to the old system if things get too messy.
Don't use broadcast email to communicate about major rollouts unless you don't mind that only 30% of the company bothered to skim through your email and among them only 10% of what they read made any sense to them. People have better things to do then thoruoughyl digest mundane IT announcements. Important to you, boring to them.
3. Hard rollout: Use a weekend to rollout the new system. This may include backups, installing clients on desktops you have access to, etc. Come Monday morning the old system is not available (but can be switched back on in a hurry) and only the new system is available. You have wisely forewarned the bosses that Monday might be a low productivity day as people get used to the new system.
4. Bumpy landing: Expect that people will complain, be confused, ask questions, blame random errors on the new system rollout, misc coworkers can't install the new client. Everyone should expect the next several days to iron out the kinks.
5. Fallback if necessary: As you warned during the company meeting do not be afraid to revert back to the old system if the new system is not cutting it.
Someone can't do hyperlinks. You'd trust him:
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
You are either working on a project or you are working on operations. A project has a defined scope, time frame, is temporary and has a unique deliverable. Operations is on-going and repetitive.
If you are tasked with upgrading something, by definition, you are working on a project.
The Project Management Institute literature and methodology is quite clear and applies to all work sectors - IT, engineering, manufacturing, etc... It's a project or it's operations. Never both.
Projects can turn into operations upon completion of particular milestones. Operations can spawn projects for upgrades, etc. There is a relationship and there are dependencies but they are not one and the same.
Daily system maintenance of your database = operations. Patching of your database = project.
This may sound pedantic to IT people for something as "trivial" as a small upgrade, but when you scale it out to massive infrastructure work - be it expanding a data center or building a new refinery - the separation is the only way you can plan and then properly execute the work.
The Master Plan Always Fails
Yeah, it is a tad tough not to manage a project perfectly when you've got Donald "I never employed you but I can fire you" Trump breathing down your back.
Speaking of those apprecticeses (as Ellen calls them), I'd manage Audrey's projects anytime. To quote Greg Roelofs, "yowza!"
You can hold down the "B" button for continuous firing.
Any advice on managing the customer's expectation of change, and convincing them of the need to step back and re-write at a certain point?
:)
Yep, put it in terms of money.
It'll take some research on your part, (and the results you come up with may surprise you so don't try to massage the facts too much), but the best way to get any point across to a huge, soulless company is by showing them how they're going to lose money.
The key here is that all of those random changes are being driven by... you guessed it! Making money!
To clarify my earlier point about surprising results of cost/benefit analysis - I have on several occasions seen similar situations where further examination revealed that the nasty, evil way of doing things which had the developers pulling their hair out actually was the cheapest and most "efficient" way in the grand scheme of things.
Heh, an intelligent AC post followed by an intelligent AC reply. I guess we both moderated in this thread.
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.
Try "How to Manage Projects" by Hooman Katirai from MIT I've seen this methodology repeatedly outperform the one you find in textbooks. What I like about it is that it is light, and it was born out of hi-tech, but has been applied in a lot of other contexts.
With the obvious onset of rapid global warming, it has been determined that we must evacuate the planet. A suitable alternate planet has been located, and the first transport ship has already been prepared! As Project Managers play such an important role in keeping things running smoothly and efficiently, you have been selected to go on the first ship!
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.
... make three envelopes.
Mit der Dummheit kämpfen Götter selbst vergebens.
Or are you accusing me of modding him (or you) offtopic? In that case you should also do some background reading: if you post to a thread, your moderation is undone.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Of course if you don't care about a smooth transition to the new..... or if you are throwing out the old and runnning parellel with all new foreign systems, you could lay me off and how you do it is your problem.
I've distilled the 9 knowledge areas from PMI into plain english.
0 69945X/qid=1109447541/sr=8-1/ref=pd_bbs_1/103-8164 264-6245456?v=glance&s=books&n=507846
What are we doing?
Who wants it?
What could go wrong?
Who's gonna do it?
How long is it gonna take?
How much is it gonnna cost?
To get it done, what all do we have to buy?
How are we gonna make sure that stuff works?
How are we gonna bring this whole mess together?
Recite that to yourself every day and you've covered the 9 PMBoK knowledge areas.:
Scope
Communications
Risk
HR
Schedule
Cost
Procurement
Quality
Integration
Also, get the PMBoK Guide
http://www.amazon.com/exec/obidos/tg/detail/-/193
As mentioned already by someone else, Prince2 is fast becoming the defacto project management standard in Europe. I wouldn't be surprised if it would become the defacto standard in the world because Prince2 focuses so much on viability of a project.
At each phase Prince2 checks whether the reason for doing the project in the first place are still valid. If not, a the project is halted or even shutdown. This way, Prince2 tries to assure that projects are done with a valid businesscase. Not only before the start of a project, but also while running the project.
Prince2 can be quite daunting and it's not recommended when all you're doing is upgrading the local Exchange server. But projects with a budget above 100K dollars could benefit from running them with Prince2.
And no, Prince2 is not just for IT projects. Although it started life in the IT world it has become a generic method that can be used in any line of business.
Thus it surely must all be bad.
IANAL but write like a drunk one.
Its useful to note that these practices only take root at organizations with lots of money to waste...money generated by a small group of kick-ass people who probably ignored anything process-oriented and just delivered.
3.Make it incredibly hard (and let people know it will be) to change
Yup, that says Government money to me.