Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Businesses IT

Project Management Methodology for IT Operations? 163

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

Project Management Methodology for IT Operations? More

Project Management Methodology for IT Operations?

Comments Filter:

  • IT Operations Process Simplified.... (Score:5, Funny)

    by hugesmile ( 587771 ) on Saturday February 26, 2005 @01:43PM (#11787849)
    Just keep the IT staff off slashdot and pr0n sites all day, and things should take care of themselves.

    • Re:IT Operations Process Simplified.... (Score:3, Funny)

      by Anonymous Coward
      Just keep the IT staff off slashdot and pr0n sites all day

      For begginers, try an easier project first like turning back the sea. For advanced managers, turn lead into gold, cure all disease and make the world a good and happy place.

    • Re:IT Operations Process Simplified.... (Score:4, Funny)

      by EnronHaliburton2004 ( 815366 ) on Saturday February 26, 2005 @03:31PM (#11788528) Homepage Journal
      Mark in IT: "Hey Jeb, it says here that you are supposed to keep me from reading Slashdot."

      Jeb in IT: "Oh yeah, Mark... stop reading Slashdot. And I think you are supposed to stop *me* from reading Slashdot".

      Mark in IT: "Ok. Jeb... stop reading Slashdot."

      Mark & Jeb together: "Bwahha haha ahahahahahaaaa".

      Mark & Jeb continue to read Slashdot.

    • If you're asking on Slashdot... (Score:1, Insightful)

      by Anonymous Coward
      ...then you have no business being in charge of anything!
      • Hmm. Last time I check, there were a lots of pretty smart, incredibly opinionated technically astute people posting to /. I feel sorry for anyone too dim to grasp what an enormous opportunity the /. community provides. How you choose to take advantage of that opportunity is up to you. (Even if only training your bullshit detector :p)
  • Well, as the developer of a Portfolio Intelligence product I think our solution is perfect. It is simple, flexible, and really has a nice built in methodology to manage the complete lifecylce of requests, pipeline, project, and finally measurement. It is also a nice inexpensive subscription based system. You can check out the corporate site at: www.3olivesolutions.com Cheers

    • Re:Unabashed Commercial (Score:4, Funny)

      by Hognoxious ( 631665 ) on Saturday February 26, 2005 @02:22PM (#11788090) Homepage Journal
      Quiz:
      Someone can't do hyperlinks. You'd trust him:
      1. to develop a project management tool.
      2. to develop a project management tool that doesn't suck poo through a pipe.
      3. as far as I could throw him.
      4. no fucking way.
      5. no fucking way, Jofuckingse.
      6. to tie his own shoelaces.
      7. did I miss the "no fucking way" option?

  • I know this one, my boss taught me. (Score:5, Funny)

    by Amiga Lover ( 708890 ) on Saturday February 26, 2005 @01:46PM (#11787872)
    Yell loud. Yell even louder to make things happen quicker.

  • IT Operations PM (Score:4, Informative)

    by Anonymous Coward on Saturday February 26, 2005 @01:49PM (#11787898)
    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...

    • Re:IT Operations PM (Score:5, Informative)

      by meburke ( 736645 ) on Saturday February 26, 2005 @03:38PM (#11788578)
      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.

  • Operations books (Score:5, Informative)

    by Checkered Daemon ( 20214 ) on Saturday February 26, 2005 @01:51PM (#11787910)
    "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.
    • "The Practice of System and Network Administration" is a great book. I haven't read the other one but now I'll have to!
  • "Mythology" more likely.

  • video training (Score:1, Funny)

    by Anonymous Coward
    There's a TV show called The Apprentice...

  • Communication Is The Key (Score:5, Insightful)

    by garwil ( 841790 ) on Saturday February 26, 2005 @01:53PM (#11787924) Homepage Journal
    "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.
    • Communication Is The Key - yeah, I think someone around here said it already: Yell Loud!

    • Simply automating existing processes may be "paving the cowpaths". Rethinking the existing processes will require business process reengineering (BPR) and information modeling prior to defining requirements. Communicate steadily with stakeholders and customers throughout the project. This will help to manage their expectations and requirements over time. Design project development so that requirements and expectations can be reconfirmed at regular junctures. Periodically check to see that stakeholders

  • IT Service Management (Score:5, Interesting)

    by (nil) ( 140773 ) on Saturday February 26, 2005 @01:57PM (#11787942)
    One methodology that is gaining popularity for larger organizations is IT Service Management [itsmf.com]. 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.

    --(())

  • Operations Methodology (Score:2, Informative)

    by Anonymous Coward
    ITIL

  • Get good people (Score:3, Insightful)

    by PIPBoy3000 ( 619296 ) on Saturday February 26, 2005 @02:01PM (#11787964)
    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.
    • The migration/upgrade projects we plan and execute, all come back to us admins to figure out wtf to do and how long it will take. The pm keeps a timeline and gives pitches to upper mgmt to keep them in there cages (and the money flowing, etc). The benifit of pm to us is simply to keep us honest and make us formalize the plans. Thing is we must fully understand how to get where we are going from where we are. No project mgmt approach can replace that.

      Of course if you don't care about a smooth tra

    • Re:Get good people (Score:2, Interesting)

      by customiser ( 150740 )
      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.
      • Interesting dichotomy; I find just the opposite true.

        I am a computer science major, and I started off as a system administrator and doing technical support at night in the operations department. I stayed in operations, and now I build tools for the operations team (so I do development - mostly, although I do get my hands dirty from time to time on my own projects) and have been on the job for 8 years.

        I was offered a job several years ago in the 'development' part of the organization, but that part of the
    • "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. "

      I would add "people who care" to that list. Sometimes you have intelligent and capable people but they don't give a damn and you end up with crap.

      Intelligence is only half of the equation. The other half is caring, work ethic, and the willingness to play nice.

      A brilliant genious who is incabable of working with their teammates is not only worthless but an
    • Processes aim to curtail and contain the intelligent and capable people because they are potentially the more dangerous (the original question was in the context of Operations, not development).

      In a higly procedurial environment the people that are better at following procedures will be more successful and efficient than the intelligent, constrained, frustrated, theoretically more capable people.

      • Simple as that, if you want to have a project that is well documented with proper testing regression suites and sign-off documents at all levels, go with CMM or Six Smegma. If you want to make a boatload of money, get a few wicked smart people, promise to also make them rich, and cut away all bullshit that keeps the rubber off of the road. See: Google. Yahoo. etc all the companies where people have made more cash than you can imagine.
    • It's not enough to just have smart people. You have to have some smart people from different departments to get stuff done and to consider all the possibilities. I'd suggest the poster should learn more about "cross functional" teamwork.

      There's a lot of crazy stuff in teamwork research, but not all of it is BS. A team that works well together can tackle any project you through at them with great results...

      When we have a large project, it'll typically involve people from IT, Systems, a project manager and

  • ITIL, from the UK (Score:5, Informative)

    by davecb ( 6526 ) * <davecb@spamcop.net> on Saturday February 26, 2005 @02:02PM (#11787978) Homepage Journal
    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

  • ITIL (Score:5, Informative)

    by Pete (big-pete) ( 253496 ) * <peter_endean@hotmail.com> on Saturday February 26, 2005 @02:02PM (#11787981)

    ITIL [itil.co.uk] 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.

  • Project Management (Score:3, Informative)

    by Laferlout ( 595504 ) on Saturday February 26, 2005 @02:03PM (#11787985)
    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/

    • Re:Project Management (Score:4, Funny)

      by Tyler Eaves ( 344284 ) on Saturday February 26, 2005 @02:13PM (#11788041)
      Really?

      Seems like every time I see a UK govt IT project in the headlines, words like "Disaster", "Overbudget", "Late", and "Useless" tend to appear with alarming frequency.

    • I work in an organisation where we seem to use PRINCE2 in name only. Once a project is under way the idea of PRINCE2 seems to be to only be concerned about bad things - ie. documentation revolves around things like risk logs and issue logs.

      The trouble with where I work is that we bury our heads in the sand when something is wrong. I think this stems from management being scared that if anything bad is documented then it might be used against them. I can kind of see how this might not be so uncommon but wou

      • I haven't used PRINCE2, though swap in CMM levels and you're basically at the same place.

        I'm a fan of CMM, though it's rarely used properly; either limited to a checkbox on a contract or used in an impractical heavy handed way.

        Chalk it up to human nature. I do like the 'kill project or any part of the project that no longer meets the goals' attitude of PRINCE2, though. It would get rid of quite a few bits of deadwood.


    • Here in the UK we use the PRINCE2 methodology

      There's a sequel [constitution.org]?!?

  • V Modell (Score:1, Interesting)

    by Anonymous Coward
    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.
    • In Germany the Government developed a "V Modell", that has to be used in Governmental projects

      Over here in germany, big governmental SW projects ("Toll Collect", "Hartz IV" and others come to mind) are infamous because they always fail.

      But perhaps this is also due to shady call-for-bids practice.

  • PRINCE2 (Score:2, Informative)

    by Anonymous Coward

    I work in the UK Civil Service, and we use (a loose form of) PRINCE2 [ogc.gov.uk] as recommended by the Office of Government Commerce [ogc.gov.uk].

    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.

  • Start with SIMPLE, FUNCTIONAL methodology... (Score:4, Interesting)

    by ulatekh ( 775985 ) on Saturday February 26, 2005 @02:13PM (#11788042) Homepage Journal

    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 [sourceforge.net].)

    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.

    • You really need just three things, and in my experience, nobody bothers to even go this far.

      What might help is a project management infrastructure to assist in doing these things.

      For design documentation and documentation in general you need a rudimentary content management system. It can be as simple as document repository under version control.

      For e-mails to track changes and record on-going discussions and debate, use a change management system like Request Tracker [bestpractical.com] or a threaded discussion group prog

    • Re:Start with SIMPLE, FUNCTIONAL methodology... (Score:5, Insightful)

      by Etienne Steward ( 677851 ) on Saturday February 26, 2005 @03:23PM (#11788471)

      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.

      • 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.
      • Look at the great products you swear by every day (e.g. iPod, Google, etc) and think of how many more years you would be waiting for these if the firms in question used your approach.

        3.Make it incredibly hard (and let people know it will be) to change

        Yup, that says Government money to me.

  • Hard rollout, bumpy landing, fallback if necessary (Score:5, Insightful)

    by Kurt Gray ( 935 ) on Saturday February 26, 2005 @02:14PM (#11788050) Homepage Journal
    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.
    • This is the best advice I've seen so far on this article, and is how I learned to handle rollouts when I first started admining -- I know you're not my former boss, but it's nice to see other people in the industry following the same method, because it bloody works.

      I'd add on to number two that designing and printing a 'changes' manual is essential for any major rollout; when I deployed a customer support-tracking system for the first time, I set up a little twenty-minute 'training session' in one of the c

  • Forget the books (Score:1, Insightful)

    by Anonymous Coward
    Use your brain.

  • Projects vs. Operations (Score:4, Informative)

    by masterplanorg ( 526696 ) on Saturday February 26, 2005 @02:22PM (#11788093) Homepage
    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.
    • 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 o
    • 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.

      OK, I see why you're saying this, but: in a suitably large/busy/dynamic environment, daily change is a routine aspect of the operations. Here's where we split hairs over whether an operational task (upgrading someone's machine) is or is not a project. I prefer to only use "project" when the task (or collection of

  • Whatever you do - don't entrust "Enterprise Solution"s just because the masses use it - the (human) masses tend to like not to have responsibility, not to have to think.
    "Yeah, let's outsource, so many are doing ti, and if it doesn't work - never mind! We'll sue them! Harhar!"

    Carrying no responsibility and no knowledge might be comfortable, but your business will not go from it.

    Get creativ people who really want to create things in the area they are working in, and not just "Oh we will go on the Micro
    • "[...]so many are doing ti, and if it doesn't work - never mind! We'll sue them! Harhar!"

      You're right, it won't work. After all, it is tough to do business with a graphing calculator. I do agree with the need for assertive, un-FUDdled thinking though. It's tough when not everyone you & your employees want advice from is a computer expert, and are instead trying to get money. Or free iPods.

  • RUP and stuff like that is not required for that. General PM methods like PMI will do.

  • RUP = The Devil. (Score:4, Interesting)

    by newdamage ( 753043 ) on Saturday February 26, 2005 @02:44PM (#11788215) Homepage Journal
    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.
    • Agreed. and UML support in MS Visio is even worse.

      I've played with Umbrello a bit, but not enough to find out its limitations.

      One thing I like to do is treat all deployment problems as tests, and write automated health checks. Example -if the filestore's clock is on GMT but the server is in PDT, files get deleted as out of date by the scheduled cleaner upper. After the fix. we wrote junit tests to create files, check the time, fail if they are different.

      Now, such tests only work after the fact, but once

    • Re:RUP = The Devil. (Score:3, Interesting)

      by 0WaitState ( 231806 )
      Heh, you said "RUP".

      Among RUP's deficiencies, you left out the way the "roles" it defines in the process attract all sorts of deadwood in the organization, people who discover they can attend meetings, act as gatekeepers, check off forms and "contribute", WITHOUT EVER HAVING TO TAKE ANY RESPONSIBILITY FOR THE DELIVERABLE, OR SUPPORT IT ONCE SHIPPED. Only an organization dedicated to the billable hour could embrace this monstrosity.
      • People end up associating themselves with key elements of the process, not the product or the customer. Team members end up literally thinking they will be rewarded in the market if they satisfy the process.

        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.

  • If there's one word that I hate more than "multimedia," it would have to be "methodology." Why make up new four-syllable words for things that already have proper words?

    (Yes, I know they're both quite old but anyway.)

  • Try this link (Score:2, Informative)

    by k0mplex ( 545007 )
    Try "How to Manage Projects" [mit.edu] by Hooman Katirai from MIT I've seen this methodology [mit.edu] 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.

  • Earth is dying! (Score:4, Funny)

    by homesteader ( 585925 ) on Saturday February 26, 2005 @02:48PM (#11788239)
    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!
    • Is the B-Ark the first ship, which is actually a ruse because there is no A-Ark or C-Ark? How is it that the B-Ark gets sent first?

      Or was there really an A-Ark and a C-Ark, but they never got launched in time?

  • ... make three envelopes.

  • 1) Get the best personnel with the right attitude. This is the most important ingradient. Keep them motivated.
    2) Set the culture you need among the team.
    3) Plan, plan and plan.
    4) Define the process and monitor the process.
    5) Measure the key parameters ( bugs, timely delivery, process errors... )
    6) Be result oriented. Process is not important as the result. If a process does not suit you, change it.
    7) Communicate bad news in time to the client. Good news can wait... bad news-earlier the better.

  • I remember in one of my first code reviews a peer dressed me down for writing "inefficient" code, specifically, I think it was my "while" constructs. I was dumbfounded! I was given the lecture on compiler optimizations, blah, blah, blah. I dug in and claimed bullhockey -- it was more important to understand the code, not even necessarily for other coders, but for one's self should one have to revisit code after a long absence.

    I know compiler theory, and that's basically what it is... if you write code t

  • PMBoK in plain english (Score:5, Informative)

    by sdanic ( 8197 ) on Saturday February 26, 2005 @03:59PM (#11788704) Homepage
    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 [amazon.com]

  • Prince2 (Score:3, Informative)

    by tliet ( 167733 ) on Saturday February 26, 2005 @04:00PM (#11788713)
    As mentioned already by someone else, Prince2 [ogc.gov.uk] 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.
  • I do not think there is a one-size-fits-all methodology for project management in IT operations. There are constants, I guess, which I think motivate each new round of IT management mythologies, but these constants are abstract, prone to severe disconnects from reality when implemented in a specific project.

    With that said, I work in IT infrastructure support for a major defense contractor. For the past 4 years, we've been implementing a project management methodology called 6 Sigma, which has its roots i
  • I'm just starting to deal with CMMI as it is a requirement for a project I've just started. (AFAICT: It's in the contract specifically to allow the customer (a government agency) a consistant way to oversee multiple contracting companies and other projects they don't directly control.)

    From the Carnegie Mellon CMMI web site; [cmu.edu]

    1. Benefits of CMMI

      The CMMI models improve upon the best practices of previous models in many important ways. CMMI best practices enable organizations to do the following:

    more ex

  • ITIL (Score:2)

    by Nygard ( 3896 )
    IT Infrastructure Library.

    Best practices for running IT Operations.

    With this in your warchest, you can craft a response to virtually any problem.
  • Honestly, once a business starts adopting processes for accomplishing tasks as opposed to having smart trustworthy productive people who justGetItDone, its time to bail. Its not so much the processes themselves that will grind you into depression, it is the people who advocate them. There's the in house "process expert" who oddly enough is almost run down in the parking lot every night and eats lunch alone...although everyone pretends to like him when he gives a "mandatory company-wide" indoctrination sessi

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

    None of these has much to do with project management.

    RUP is a development methodology. It says next to nothing about project managmenet.

    The CMM is an assessment framework for tech

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close