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.
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
Mind | Body | Spirit | Cash
Yell loud. Yell even louder to make things happen quicker.
"Oracle-based" and "non-technical" do not belong in the same sentence.
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.
"Mythology" more likely.
The higher the technology, the sharper that two-edged sword.
There's a TV show called The Apprentice...
"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/
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.
If the system is of any size, the scripts, middleware, and other glue that makes up the application will be of critical importance. The documentation and scalability of the parts will often determine the success of the project and how often your beeper is going off. Documentation and proper engineering apply in new development and operations.
In the case of examples, many case studies are available. Someone has already gone through the pain you are about to. The vendor can often provide some case studies. They are often biased, but they often have an interest in making your project succeed. Often these life lessons make consultants rich and they hold them close to the vest. Hiring one for a few hours can often give you valuable insights.
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.
I know this is off topic, but.. "Methodology" is a pretentious way of saying "method". Literally translated means "study of methods" which is rarely what is intended. I hear it used all the time by intelligent people, but if you stop and think about it for a second, it really is pretty silly.
"The Practice of System and Network Administration" is a great book. I haven't read the other one but now I'll have to!
And the first sentence says: "There are a multitude of books, tools, and educational programs that deal with managing development projects."
Am I the only one who thinks that development projects and operations are so different that they're mutually exclusive?
Indeed, one definition of a project I heard is anything that isn't operations.
At the bottom of the
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
I manage a large customer retention program for my customer (a huge, soulless, insurance company). The program has been built up over time, and has reached the point of almost unmanageable complexity. The customer pays a flat fee to keep myself and two developers dedicated to this program, not just to run it -- but to constantly change it.
I'm not sure what forces on their end drive the need for constant cahnge, and I am in no position to question it (as it pays my people's salary) but I have trouble explaining to the non-technical folks there that these constant, ad-hoc changes with no over-arching vision of what will eventually be done will lead to inevitable disaster.
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?
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.
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
In this context, and according to m-w.com, it means:
1 : a body of methods , rules, and postulates employed by a discipline : a particular procedure or set of procedures
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 Microsoft-line, because that is what they told us on the MCSE course".
"First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
RUP and stuff like that is not required for that. General PM methods like PMI will do.
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.
(Yes, I know they're both quite old but anyway.)
while true;do echo -e -n "\033[s\n\033[u\134_\033[B";done
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!
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 conference rooms, and spent two or three extra hours writing up a short manual, complete with screenshots, covering basic functionality.
Almost every user did with the manual what they wouldn't do with a mass-email -- they read it, and pretty much everyone came to the 'training sessions' (I had to add in two more to cover the demand) to ask questions, and all of this *before* the actual rollout. We also set up a 'beta' demonstration system for people to play on, with notices plastered all over the place that the thing was beta, and that it was going bye-bye.
Those two things helped immeasurably, and while there were still bugs to be ironed out, all the users were very patient about letting us get the thing working, because we took the time to tell them what was going on.
--
I Hit the Karma Cap, and All I Got Was This Lousy
... make three envelopes.
Mit der Dummheit kämpfen Götter selbst vergebens.
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.
If that's the kind of job you have, my suggestion is to get a new one, since you're tantamount to a plumber.
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 to home in on compiler efficiency, you're doing it on theory, you don't necessarily know your compiler will do what you think it will. And for those of you who "do", you don't know where else your code will go and be compiled. You run the risk of propogating obtuse code (submit to Obfuscated Code...).
Besides, there's nothing like aging code to improve efficiency... for some reason my code is written so well, it runs twice as fast about every 18 months.
And, per another poster, code not worth timing is not worth optimizing... I've never known a bit-head who "optimizes" C-code to time it to verify its improved efficiency.
This may seem to over simplify the problem, but in real life experience I've found this approach works.
Or was there really an A-Ark and a C-Ark, but they never got launched in time?
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.
...then you have no business being in charge of anything!
Holy cow, look at that "resume"!
I hope that your boss doesn't know that you're posting here...that "engineering" job might just dry up and blow away!
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
I've read ITIL and passed the foundations exam, but I prefer Microsoft Operational Framework, also called MOF. It's much easier to read than ITIL (at least for my limited intelligence).
Of course, our management team has paid lip service to ITIL without actually providing resources to do something about it.
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.
At my workplace our methodology is simple. We roll up our sleeves and code the fucker.
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 in quality control. It is fairly effective for identifying and minimizing sources of variation in a process-driven environment like manufacturing, but making it work in an event-driven environment like IT is not easy. However, we have had some notable successes using 6 Sigma in IT, including infrastucture operations, so I'll give you a capsule view of the basic processes involved.
The 6 Sigma process can be summarized as visualize, commit, prioritize, characterize, improve, and achieve. Here is the 50,000 foot view of each part of the process.
Visualize: Ask yourself "What are you trying to accomplish?" or "What is your vision of the future?" Then ask yourself, "How am I going to get there?" The idea here is to document exactly what the end state is supposed to look like, and the approach you are going to take. For example, "I spend too much time installing and updating applications. I want to reduce the time I spend at a user's desk installing and updating applications software. I think I need a better way to deploy applications to my users."
Commit: Get buy-in from your collegues, your management, and your customers. Create a list of deliverables. Sticking with our example above, your deliverable could be:
Implement an application deployment process that will reduce the amount of time sysadmins spend at users' desks installing and updating applications
Prioritize: Look at your deliverable and start thinking about what you need to do to, and who you need to do it.
Characterize: Document the as is condition, and its undesireable effects, and your plan for improvement. You want to generate metrics that you can point to that will show you made an improvement. Getting these metrics and using them to validate your solution is the essence of the 6 Sigma process. So, our example metric might be the time sysadmins spends installing apps, upgrading apps, patching apps, etc, and your plan for improvement might look like:
1. Identify automated application packaging and delivery systems.
2. Down select to three systems and conduct bake off.
3. Announce winner
4. Train sysadmins on use of system
5. Create Deployment process
Improve: This is where you monitor your improvement plan, making sure that it is staying on schedule. This part of the 6 sigma process is staight-forward management. It will test your ability as a leader and a manager. It has little to do with the actual improvement process, but almost everything to do with its success as a project. When you've implemented your plan, you need to look at those metrics you came up with and see if you really did improve anything.
Achieve: My 6 sigma coach called this the party-time part of project management. Essentially, with your metrics in one hand and your expense sheet in the other, you go to your management and show them that your project was a success, and they buy you and your team lunch.
I apologize for the length of this post - it actually needs to be longer, because I've just skimmed the surface of 6 Sigma. I will happily entertain any questions about 6 Sigma if you want to email me.
From the Carnegie Mellon CMMI web site;
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 explicitly link management and engineering activities to business objectives
expand the scope of and visibility into the product life cycle and engineering activities to ensure that the product or service meets customer expectations
incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management)
implement more robust high-maturity practices
address additional organizational functions critical to its products and services
more fully comply with relevant ISO standards
SCAMPI incorporates the best ideas of several process-improvement appraisal methods. The SCAMPI A method is being used successfully by many organizations. The emerging SCAMPI B and C methods will extend the suite of SCAMPI methods. The method implementation guide for government supplier selection and contract monitoring also builds on SCAMPI in the acquisition arena.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
IT Infrastructure Library.
Best practices for running IT Operations.
With this in your warchest, you can craft a response to virtually any problem.
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
I currently work for the government, and we *try* use the SEI's Capability Maturity Model. The problem is that we try to use it in a maintenance and support environment.
First problem is that critical tools are sadly lacking. Unless you are adding a new feature, it is very time consuming and tedious to keep track of all your changes so that you can, as in the Personal Software Process, keep accurate statistics of what changes you made, how many lines of code were modified, how many were deleted, and how many lines of code you added. PSP, for example, is taught only for one language, but many projects and even many modules themselves use multiple languages. Yes, we have been using Process Dashboard (an open source PSP tool which tabulates your time and lines of code), but the real need is for a tool that can automatically keep track of all the changes you make while you make them. (An Eclipse plugin along these lines would be very cool.)
Another problem with CMM or other like methodologies is that some requirements are often enough not well known until the system makes it into production. Also, if future needs change, your software has to change with it. Unless you are making software for pace makers or weapons (things for which the specifications cannot be changed because they perform critical functions and sometimes even have to be proved by theorem), your users and management *will* come to you with requests for further enhancements, what to speak of all the bug fixes that will be there. Nothing much you can do to prevent it. Because most people who maintain the system once it goes into production are not the people who built the system, what happens then is that an awful (and I really mean awful) amount of time is spent by programmers just trying to figure out the system itself, tracking down what components need to be modified and why and where. And then once they have gone through all that, THEN they can make an estimate that is somewhat compatible to what PSP requires. Basically, the lions' share of programming time goes into the planning stage without touching a line of code, something that doesn't feel very good if, like most programmers, you like to build things. Sure, adequate documentation helps, but there is always a tradeoff between process and getting the job done expediently.
Advocates for agile development processes have typically said that processes like XP are the solution. But I've also developed using XP and have found that compared to something like PSP it lacks in its ability to make accurate predictions about how long it will really take to complete a task. This is because XP more or less uses rule-of-thumb engineering judgement to make time estimates whereas PSP tries to base estimates on historical data. (Of course, up until you get your historical data, even PSP uses engineering judgement). However, XP deals with an aspect of reality the more formal processes like PSP don't address so much, which is that most software specifications are going to change througout the project and change in post production in unexpected ways.
In summary, processes like PSP (CMM) lack critical tools needed to unburden developers from excessive process overhead. These methodologies are meant specifically for building new software, not dealing with the realities of built software, which is usually maintained and enhanced by someone other than the person who built it. IMHO what is needed are people to build automated tracking tools for changes made by coders and for more research and development in the area of operations and maintenance, which according to Sun Microsystems occupies as much as 80% of the development time on any code base.
It's possible to adapt some development practices to operations, or develop practices specific to operations, but not be a "methodology".
Systems Administration Practices on the XP wiki.
Why are so many developers responding as if this were another question about development projects?
Before you reply, re-read the original post. The topic is operational projects, not development/coding projects.
Capische?
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.
IANAL but write like a drunk one.
Thus it surely must all be bad.
IANAL but write like a drunk one.
I work in an organization that has adopted CMM. I feel like I'm a soldier in the trenches in World War I. I'm the one getting shot at and the generals behind the lines have no fucking clue what's going on.
The problem with the latest management fad of process models is that they are cookie cutter approaches based on the belief (by non-programmers, obviously) that software development can be reduced to an assembly line process. It is an example of what I call "round peg, round hole" management theory, that is, all jobs are round holes and all programmers are round pegs and therefore you can switch them around all you like with no impact.
When organizations adopt these models and go for certification, what happens is that following the "process" becomes more important than whether or not anything actually gets done better or faster. And don't forget, if you want to have a bureaucracy, which is what these models more or less demand, you are going to need bureaucrats to implement them. Time and money.
It should be no problem for any group to come up with a development process that makes sense for them and the circumstances of their work. If you are trying to herd fifty programmers, there is a need for rules to be set down. But for a small group, they can spend as much time following the process model as they do getting some actual work done. By going outside for a process model, management really wants to avoid having to rely on the grunts to decide on what they need and how to do it.
Here is what's really needs to be done for any project:
That was a good venting.
The point of my comment was that very little is needed to implement proper team communication, and even the 3 simple steps I outlined are usually not present.
Also, those 3 steps can be implemented in the usual case of idiot programmers and clueless management, while your plan requires a somewhat more disciplined and competent sort of place...like a Fortune 100 company.
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
My experience has been that an awful lot of shops try to use a canned methodology to compensate for the fact that they don't have good people. This simply never works. Having tons of documentation describing how your systems differ from a vendor-supplied baseline, what steps to go through to install something new, how you're going to test the changes, etc, etc, etc, is useless if the people doing the work aren't competent. They'll still find a way to fsck it up.
No amount of testing will save you if the tests aren't performed by people qualified to interpret the results and as QA systems often differ from production ones, there is no substitute for having sysadmins who have a solid understanding of what's going on.
I've been in several shops that have attempted to adapt software development lifecycle practices to system administration. The most common result is a bunch of documentation requirements that slow operational processes down to a crawl and don't end up increasing their reliability. A more productive approach would be to hire top-flight sysadmins and to invest in QA systems that accurately reproduce operational conditions, so that the testing is meaningful. Why is this done so infrequently? Because it costs money and can't be accomplished by management fiat.
All you every need to know about IT management can be found right here:
http://bofh.ntk.net/Bastard.html [BOFH}
Another closely related methodology is "Visible Ops" from the Technology Process Institute. Also have a look at their TWiki site which is quite valulable: ITPI TWiki. Tripwire has also been supporting this methodology and has some good information about it on their "IT Best Practices" web site.
One real problem with ITIL is that it primarily focuses on what how to structure organizations and procedures but not on the nuts and bolts on how to actually implement the methodology in a particular situation. The "Visible Ops" methodology listed above tries to address some of these shortcomings with ITIL.
Ultimately, it is not the strict application of a particular methodology itself that is going to solve any such problems. That is really only going to happen when experienced management working with competent staff appropriately apply these techniques to their own organization. Certainly watch out for any pronouncements of a single "Silver Bullet" methodology!
Oddly enough you are not making this up. Ewwwww. Who wakes up in the morning thinking...can't wait to cruise on over to pmi.org and see what the latest trends in paperwork are!!
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.
Ha! I had the misfortune of being recommended "The Goal", and let me tell you that you are truly trolling if you associate this with any degree of business competence. Night-school associates degree tripe all the way. DRECK.
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.
What does that mean? That an organization is not "excellent" unless it is buried in paperwork?
Good God please tell us where you have worked/work/plan to work so we can run in the other direction.
There's the idiotic management software that is nothing but an anchor on a speedboat to anyone with a brain.
There's the loss of perspective - everyone gets so tied up in meeting the paper goals, no one bothers remembering about the product being awesome or people getting to shine during its creation.
Just look around at the poeple who send in their two-weeks when these processes are put in place...if you think these are the best producers in the office, time to start writing yours too.
Thats the step missing from almost every methodology I have bothered with - this is the point where we actually do shit instead of talking about it.
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.
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.
Unlike other methodologies which require you to fiddle around with a GANTT chart and microsoft Project as if it were some kind of full-time job, this is the only methodology that I found actually practical.
It even works if the people you are trying to manage are above you in rank!
3.Make it incredibly hard (and let people know it will be) to change
Yup, that says Government money to me.
Here's my proposed methodology for handling our next big project:
1) Get all business process leaders in one room to begin discussions of project.
2) I snap, take out a gun, and start shooting the aforementioned business process leaders.
3) After they shuffle off to hell in a blaze of gunfire, I reload and take to the cubicals, dealing death on random whim, as I march my mad way to the boardroom.
4) I kill the board, and any other executives and/or their support staff. Unfortunately on any given day most of them are out golfing and screwing, so I can't cleanse the entire company at once.
5) Hole up and wait for the S.W.A.T. team to arrive. Take as many coppers screaming down into hell as I can, as in some religions your status in the afterlife is determined by the number of your enemies you drag down into the pits with you.
6) As the snipers finally get me, and everything fades to black, be glad I don't have to deal with any more of these stinking, stupid, useless, moronic methodologies anymore.
RUP is a development methodology. It says next to nothing about project managmenet.
The CMM is an assessment framework for technical competencies. As such it is not prescriptive.
The other two are good books that contain valuable anecdotes about project management. Neither is a methdology. I value Brooks far more highly, but that's just me.
Look at the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) for something specific to project management. Brits seem to like PRINCE better.
As with any certification, neither PMI nor PRINCE can substitute for learning project management by managing projects. I've met a lot of PMI-certified nitwits. But having a common vocabulary and toolkit is still worthwhile.
Get your teeth into a small slice: the cake of liberty
Modern Popinjay Management much like the aristocracy of old can look-good, strut, and talk, but cannot do much without the worker-bees and pack-mules. ... performance is directly related to the paranoid delusional corporate leaders (US, EU, UN, Them, Others, ...) in governments and businesses believing that their failure is caused by "worker-bees and pack-mules", or fictitious persons and situations beyond control, and/or something really strange and unheard-of cases them to make mistakes, be failures and losers. This is the typical epitome of white-collar-trash character and megalomania ... "The ends when bad are always caused by others". ... because they are not licensed/certifiable professionals ... they can clame fraud, theft, bribes, are due to ignorance or incompetence and walk of with their ill-gotten treasure-chest just like the pirates old. .... This is just part of the new "Kinder & Gentler" Christian USA. I have volunteer in the past to travel to war-zones as a US Government Civil Servant, but forcing others by regulations seems to be the last resort of BS-patriots. Either it is voluntary deployments to war-zones or it is conscription ... there ain't no middle fucking ground ... for US.
>
Operations depend on those that can do (the worker-bees and pack-mules), not the dodo management of the corporate local politicians and international aristocrats. The current globally poor conditions of humanity, families, education, healthcare, governments, business,
>
Governments and businesses are failing, because of piss-poor-decisions by the leaders/management believing they deserve most of what should be provided to the worker-bees and pack-mules. No CEO is worth more-than 20 times the average corporate salary and a total benefits package that is appropriate for a CEO are reasonable for the lowest paid employee. Any leftover profits shold be reinvested into the company or dispersed among the owners or shareholders.
>
You cannot even hold the governments and businesses leaders/management legally responsible like doctors, architects, lawyers,
>
The only way to fix operations in business or government is fix management by making them legally and financially responsible for ignorance or incompetence caused damages.
>
US Government DoD has a NEW "Back-Door-Draft" it is called the NSPS (http://www.cpms.osd.mil/nsps). Anyone working for DoD as a Civil Servant can be required to deploy to war-zones like Iraq, Afghanistan,
>
HAVE FUN
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
GDPM: This book contains a lot of sense about how to build systems that work first time. Goal Directed Project Management
Is just what you need: "The IT Service Capability Maturity Model (IT Service CMM®) is a maturity growth model aimed at providers of IT services, such as management of hardware and software, operations, and software maintenance. The structure of the model is equal to that of the Software CMM, the contents of the IT Service CMM, however, are key process areas needed for mature IT service provision."
;o)
See http://www.itservicecmm.org/
Hi Frank
I am curious if anyone knows of a good learning resource for small project managment out there? I work in a large corporation with a lot of politics. Our team of only 3 developers is constantly overworked, however, there is constant pressure to incorporate a process into everything we do. It used to be "get the job done", but now, it's "tell me how you are going to do it, document it, get approvals, etc.".
/.'s out there who know there stuff. I would really appreciate any suggestions.
I have been expected to define these processes, but do not really know where to start. I am sure that there are some
Thanks!