Project Management equals SUCCESS

Very good point. I think what I had to learn the hard way was creating a really solid requirements list in the beginning. This can get confusing for many people and a critical term that is associated and may help everyone is called "decomposing".

You may start a job out ass a five pager for example. The requirements list would simply state each page and just the simplest outcome of what those need to achieve. What everyone tends to do is continue filling out more and more details in notepads, or in word, excel or something like that. When a requirement is broken down into sub-sets you are decomposing - which is great, you need to get your details figured out. However, this can lose site of what the original is supposed to achieve. So you keep you first list or requirements simple and to the point.

What starts to occur as you break things down is that you are also identifying what work will need to be performed. In PM this is called a work breakdown structure or WBS. Now if you do this in a numbered outline, you can track what part of a very complex project is being worked on, by who, how much it cost and when it should be done. So if you have "create fan page" but it is three levels down from a main requirement it might be numbered 2.1.2 (let whatever program you are using create that)

In a application like MS project, you can also associate a cost and time value which creates a baseline and a timeline and is used in a GANTT chart. Even if you don't know the exact cost you just put in what you estimate and as you associate this for the entire budget it tracks that as well.

What I really like about using an application is that you and the client often will think off the top of your head "This could be done in a week or four weeks". Then as you sit down and enter the details you start to see it actually might take three months. Or at least it will certainly start creeping if that client calls up after you spent so much time setting up a "simple" fan page and "just do a couple quick things" for them. Then suddenly you are working twice, or paying twice for someone to update the thing.

The thing that really kicks around, is that clients often have no idea what it takes to get CSS changes done. Because when they turn their TV on or Computer it just POPS on, they often think we are all just clicking a couple of buttons and thinking "Isn't the computer age brilliant?!"

Working with a contractor is even more detailed, because every change that comes up, you have to write an email and then get back a "HUH? Why", "Because I said so", "Are You sure?" and then hire another contractor LOL.

The big picture for every project you start actually has a project life cycle or PLC. If anyone is familiar with a System/Software Development Life Cyle (SDLC), this goes inside a PLC. A PLC is good to understand as a business owner, because this is exactly the phases and the start to finish time that you are expecting the project to take.

How many people have finished the project and then the customer calls up for some changes and you are hesitant to say "Sure thing I will get a proposal over to you soon" and rather says "Ok, I'll get that taken done..." without recognizing that you were complete and done and need to be focused on your other customers and prospects as well?

Setting a PLC not only gets the customer acquainted with how you two plan to follow a workflow, but it also helps very much in setting your own expectations of how you expect to be treated.

By the way, I have one of these clients who wanted me to install a Joomla site. I mentioned to him at the start "I would suggest you don't make the mistake of trying to reprogram joomla, focus on the goal of the site and let joomla do its thing." He got excited, started to install things all over the place and has a 500 meg site that is driving him nuts as we speak. He had a great business idea, but for some odd reason is wanting to learn how to recreate a CMS, that already works fine.

This is an odd viewpoint of scope and the project. There is the success of the project and then there is the success of the project management. Learning how to peak and tweek how the project works is not as important as how to get the goal of the business. However, you see this all the time when people set out to get an online business running and next thing you know they are learning PHP and JavaScript. Scope creep can be an absolute killer.

By the way, I am telling people all the time that the PMBOK and its rules are all over the place. While I was studying the 4 hour work week I was kind of grinning when he mentions "task creep" and then "dream-lining" as opposed to base-lining.

The only thing that irks me right now is that MS project is the best that I have seen manage Time Cost and Quality almost automatically, but I am still checking into some other open source solutions.

Very good point. I think management and analysis is very difficult for people to balance most of the time. Following a PM style is actually suppose to overcome this, but it's human nature that tends to fall back into the same old thing.

Analysis and trust are a big issue. You have to analyze, but know when to trust that you have done as good a job as you can and move on. So you have a couple sayings that seem to disagree -

Paralysis by analysis
Failing to Plan is Planning to Fail

Management is often about coming into issues that appear black and white and then finding the correct path which is usually the gray middle ground. And none of it is ever set in stone or fixed. Everyday you have to meet the errors and issues as they come.

Also, time,cost and quality is what will tell you - I need to plan this out in an hour and do it by such a time and not cost me more than so much.

On the other hand I know plenty of people who confuse management with techniques corporate managers use to justify their job rather than actually get anything done. Setting meetings, that are more about flexing status than accomplishing team building. I have literally stood in a side room as operations officers explained how a major meeting of regional managers across the entire US were brought in solely to see who was getting the axe, but the whole thing looked like an "improvement" seminar and they had to do all sorts of input and feedback sessions.

Also, there is a term called TQM or Total Quality Management. Plenty of good ideas under that idea, but it can go wrong quick. You can get theories of people analyzing the way someone types and doing all you can to make them work three nanoseconds faster - seriously lame (but really did happen and still does). I once worked for Toyota, and am familiar with "the Toyota way", long story short TOTAL POLICE STATE LOL. It has some good qualities to it, but it also has some nightmarish implications as well.

The beauty of working independently is that you are already in a prime position to bypass a ton of that stuff and just forget it. Really, I am in the position I am now, because I do not agree with it at all. Of course anyone who is dealing with contractors knows that you have to set some rules and keep them on track, but yes there is a level of insanity to it as well if you let it go to far.