Slashdot Mirror

← Back to Stories (view on slashdot.org)

Project Management Methodology for IT Operations?

Posted by Cliff on from the transcending-the-programmer's-cubicle dept.

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

15 of 163 comments (clear)

  1. IT Operations Process Simplified.... by hugesmile · · Score: 5, Funny

    Just keep the IT staff off slashdot and pr0n sites all day, and things should take care of themselves.

  2. I know this one, my boss taught me. by Amiga+Lover · · Score: 4, Funny

    Yell loud. Yell even louder to make things happen quicker.

  3. IT Operations PM by Anonymous Coward · · Score: 4, Informative

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

    1. Re:IT Operations PM by meburke · · Score: 4, Informative

      This is correct, IMO. See Baseline Magazine for examples of how people are manageing their IT projects.

      With today's Project Management software it's easier to track the progress of a project. (I've been doing PERT/CPM since the early '70's, and then I had to draw my diagrams by hand and update my task lists on a typewriter.) Unless the project is massive, Microsoft Project or Primavera SureTrack should be more than sufficient. The PMI (project Management Institute) has standards for Project Management in .pdf for download. They offer a certification, but Novell already proved that certification is no guarantee of competency. Knowing the best practices is very helpful, even if you don't intend to get the cert.

      A wrinkle in the Project Management model showed up with the Goldratt Institute's publication of "Critical Chain". This book attempts to answer the question, "Why don't well-managed projects finish on time?" Unfortunately, the answer is partly contained in the process discoverd in the books, "The Goal" and "It's Not Luck" by Eli Goldratt. You would probably have to read all three books to understand critical chain logic, and you would still have to know something about PERT/CPM to understand the difference. I's only worth it if you are committed to a business-wide policy of excellence.

      Don't confuse Project Management with other tools, such as Rational Rose, which are resources, not project management. On the other hand, good use of these type of tools are helpful in keeping a project mananged. I've adopted the approach used in "Tried and True Object Development" by Aalto, et al., which describes a very good use of UML as practiced at NOKIA.

      Good luck.

      --
      "The mind works quicker than you think!"
  4. Operations books by Checkered+Daemon · · Score: 5, Informative

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

  5. Communication Is The Key by garwil · · Score: 5, Insightful

    "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.
  6. IT Service Management by (nil) · · Score: 5, Interesting

    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.

    --(())

  7. ITIL, from the UK by davecb · · Score: 4, Informative
    See the the IT Infrastructure Library site at http://www.itil.org.uk

    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
  8. ITIL by Pete+(big-pete) · · Score: 5, Informative

    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
  9. Start with SIMPLE, FUNCTIONAL methodology... by ulatekh · · Score: 4, Interesting

    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.

    --
    "Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
    1. Re:Start with SIMPLE, FUNCTIONAL methodology... by Etienne+Steward · · Score: 5, Insightful

      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.

  10. Hard rollout, bumpy landing, fallback if necessary by Kurt+Gray · · Score: 5, Insightful

    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.

  11. Projects vs. Operations by masterplanorg · · Score: 4, Informative

    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
  12. Earth is dying! by homesteader · · Score: 4, Funny

    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!

  13. PMBoK in plain english by sdanic · · Score: 5, Informative

    I've distilled the 9 knowledge areas from PMI into plain english.

    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/-/1930 69945X/qid=1109447541/sr=8-1/ref=pd_bbs_1/103-8164 264-6245456?v=glance&s=books&n=507846