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?"
"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.
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.
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.
Use your brain.
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.
Huh. We must have never worked together. Or maybe you were on the development side of the house.
1. Create an impact analysis document (how is what we are about to do going to affect current operations). This should tell you if what you are planning to do is possible and should have all of the systems affected listed. You may have to travel out to the field and interview people directly.
2. Develop the specifications before implementation (programming) begins. Having those battles at this point (before coding) is better than having them while you are coding. Create prototype reports and screenshots and have people sign them if you have to...
3. Make it incredibly hard (and let people know it will be) to change the specifications once they have been agreed to (this will help with scope creep).
4. Document, document, document. Program based off of the documentation. These documents, completed as you go, will bring new team members up to speed on what is happening.
5. Have team members check each other. Have people read other people's documentation.
6. Test, test, test (use the documentation as a basis to develop test plans). Preferably have someone who didn't write or implement the code test it based off of an independently developed test plan.
7. Create backout procedures (make it so that you can get out of trouble as fast as you go into it).
8. Communicate the installation date/time to operational units. Try not to do the whole company at once (pilot it at typical sites or locations). Do not hesitate to back it out if your end users report trouble. Backout first and figure out what went wrong later.
9. After all units are up to date, do one final install to the entire company to make sure that the codebase is consistent.
10. Follow up.
Customer service and communication are critical to the success of any systems change that will affect operations.
Why should you listen to me? I did manufacturing and planning applications maintainence for a Fortune 100 company for 6 and half years and all the plant managers loved me, because I follow this method. I never interrupted a facility's operations, ever -- and neither did anyone whose work I supervised.
Best of luck.
...then you have no business being in charge of anything!
All that is great if you have a patient and understanding management/customer.
If you are working for a "I need this by tommorow" kind of guy all that flies out the window.
evil is as evil does
Thus it surely must all be bad.
IANAL but write like a drunk one.