Quality Perspectives in Project Management

In Managing for Quality and Performance Excellence, Evans and Lindsay point to 5 distinct perspectives when defining quality. They are transcendent, product-based, user-based, value-based, and manufacturing-based. The authors discuss the topic in terms of defining quality within organizations and products. I see parallels to defining quality when running projects.

Transcendent Quality

This perspective makes a judgment as to quality in comparison to a “standard of excellence”. This is a highly qualitative measure of quality, and is normally a function of all aspects influencing the perception of quality combined. On projects, this is your complete package, and could be judged by whether or not sponsors want you to manage their projects, customers ask for you by name, or team members love to work with you on your projects.

Product-Based Quality

Are the details taken care of? In manufacturing, product-based quality could be the thread count in textiles, or well things fit together. In a project, I interpret this perspective as looking at:

(1) Did the project manager do a great job of managing the details (communications, risk planning, resource planning, etc.) and

(2) Did all the solutions satisfy the requirements fully, or did some of the solutions only solve the problem 80%?

User-Based Quality

The customer is always right. Or at least from this perspective, quality is based on whether or not the customer got what they wanted. Suppose the exact same IT solution is implemented for two groups. For group A, this is the perfect solution for their needs and so it represents high quality. Group B is impacted by limitations that don’t matter to group A, and so they perceive this as a low quality solution.

Additionally, this relates to how well the requirements are written and implemented. Do they truly address the customer needs? Poorly written requirements can be executed on perfectly and still represent a poor quality job from the user-based perspective. This would happen if the requirements were poor to begin with and did not accurately reflect the customer needs.

In short, the user-based perspective all comes down to the accuracy and precision of requirements, and how well they are executed.

Value-Based Quality

Many times people jump towards a custom-built or proprietary solution to a problem when there are commercially available alternatives that would meet the same needs for much less cost. Project A and Project B solve the same problem and have comparable value added when finished, but Project B costs twice as much. Project A has twice the level of quality from this perspective.

This could also play into resource allocation. When people and tools are used in the right place at the right times, they work more efficiently and cost less than disorganized, adhoc projects. Whether it’s the solution or resources involved, this perspective is all about return on investment.

Manufacturing-Based Quality (or Specifications-Based Quality)

In business, this is defined as the level of conformance to specifications. A tolerance specification of .236cm +- .003cm is a standard of quality. In projects, I see this as conforming to the original scope and plan. Scope creep reflects poor quality in this regard, and so does being over (or under) budget or time constraints set forth in the beginning. EVM practitioners and project controllers may be able to relate with this very well. If you stick to your original plan, then you’ve got high quality on your project from this perspective.

Another angle on this might be how closely the actual solution matches up to the requirements. Although the User-Based perspective speaks to requirements also, it is geared more towards what the stakeholders actually want. This perspective assumes that if the stakeholders signed off on their requirements, and you provided solutions that address those requirements, you have high quality. This could result from taking a pre-conceived solution from a customer and running with their requirements, without worrying about what business problem you are actually trying to solve, and if there is a better way. In that case you could end up with poor user-based quality, but high specifications-based quality.

I'm looking forward to delving into the rest of this book. So far it is very promising and I believe it will provide many insights into how to create and manage quality projects.

It Was An Itsy Bitsy, Teeny Weeny......

Finding the right balance of documentation and methodology can be challenging on small projects. Here are some tips.

I have been managing small projects for some time now. Some of my project are really tiny, I'm talking about 8 hours of work max. Others can be 2 week or month-long projects. Some span several months, and then you get up into the 6 month and year plus undertakings.

As a student of project management, I have often struggled with finding the right level of planning and documentation for these various sizes of projects. Some things are obvious, as in I'm not going to go through a formal project plan and communication plan, etc. for an 8 hour project.

As a rough guideline, here is what I use:

Level 1 (Projects longer than 6 months in duration)

-Full blown project planning and documentation for whatever is appropriate to the project

Level 2 (Projects 1-6 months in duration)

-Simplified project planning document, which includes brief communications and risk plans, along with scope definition, limitations, objectives, and deliverables. Also containts a simple WBS and Gantt-style task list with dependencies, owners, estimates, and a timeline.

-Weekly status reports to stakeholders

-Project meeting agenda/minutes template - I use this to document the agenda before meetings about the project, then update it immediately after the meetings and send it out to all the stakeholders. It includes a section for decisions regarding agenda items, and a seperate section for action items.

-Project Closure report at the end which summarizes the business benefits gained and effort spent. This is a good post-mortem look at ROI. Lessons learned are also attached to this.


Level 3 (Projects 1 to 4 weeks in duration)

-Simple project request form, where the requestor fills out their definition of requirements and business justification. Since these requests are fairly simple, I normally work out the details of the requirements over the phone with the customer, and just make updates in my project documentation log (which I keep for all projects big and small)

-Weekly status reports to all stakeholders (sometimes yes, sometimes no - depends on the project)

-Project Closure Report

Level 4 (Less than 1 week)

-For this I still have the simple project request form

-Email when the deliverable (usually 1) is ready for validation, asking for approval


I keep detailed activity logs for all levels of projects, even if it's a 2 hour job. My department has a sharepoint site set up that works really slick for this.

I find that using these guidelines, and the templates I've developed, really makes it easy for me to keep my ducks in a row and keep my stakeholders informed about what is going on, for any small to medium project I am managing. For more information, check out this great article by Simon Buehring which I found today and very closely matches my style for managing small projects.

This article was originally published at http://projectmanagementlearningcenter.com/.

Old School Bas De Baar

I wanted to have a great new article ready for today's post, but I am applying for scholarships through PMI and so had to put some effort into the required essays.

So, today will be a lazy post on my part. Here is an interesting video I found that Bas put out back in 2004. Much of this is in the spirit of his book which I am reading now. Check it out!

Interesting camera work Bas!

Master Plan

In the April 2007 edition of PM Network, there is an article titled "Master Plan: IT executives need to develop an eye for project managers" that I would like to comment on.

The article is mostly based off a study done by Gartner Inc., in Stamford CT, USA. One sad but true statistic stated that 20-30% of IT executives "have a 'dismissive attitude' toward project management". Those are the same execs that suffer "from poor quality, late delivery and unrealistic project costs." I can related to this information from my personal experience, and would venture a guess that when you move into executives in operational areas, the dismissive attitude towards proper project management increases. The majority of IT execs seem to have seen the light and made the realization that there really is value to be delivered by well run projects by individuals who have the right skills to do so in a formal manner.

If I had to guess at a percentage, I would say that more like 40-50% of operational executives have a dismissive attitude towards formal project management, although the number seems to be decreasing. There are still a majority of director and above level people who seem to not perceive value in formal project management. I see the trend towards realizing project management adds value as positive reinforcement for my decision to enter the discipline.

But I digress. Back to the article in PM Network, I found a few points insightful and worth sharing here. First, the report by Gartner classifies IT project managers in 4 categories:

1. Novice - Some project experience, lacks formal training
2. Apprentice - Some project experience, shows initiative towards managing projects, has sought out and attained some formal training, ready to manage a low-risk project.
3. Journeyman - 2 years of project management experience or more, formal training in scope and risk management, advanced scheduling and best practices.
4. Master - 5+ years successfully managing projects, usually PMP or other certification attained.

Only 15-20% of project managers are in the Master group. I would place myself either in the high Apprentice or just barely Journeyman category. I've had a good amount of formal training and several years of managing projects, albeit projects managed without knowledge of the discipline of project management.

I feel the categories above are a bit tenuous, as I have met project managers who by the definition above would fit into the Master category, but do not display what I would refer to as Mastery skills in managing projects. The last box in the article goes into five characteristics of masters that I feel are much more accurate:

1. Diplomacy - ability to manage the business relationships effectively
   
2. Strategic Vision - ability to see the big picture and eliminate "silo paradigms"
   
3. Policy Responsibility - seek process improvements and question existing policy constraints
   
4. Collaboration - cross-functional leadership skills
   
5. Risk Management - advanced risk management goes beyond a risk management plan checklist

I would like to add a few to this list:

1. Effective Planning - see my previous post on Alpha Project Managers and how they spend twice as much time planning as non-alphas.
2. Superior Communication - Again a reference to Alpha PM's - This goes with diplomacy and collaboration, but everyone knows the successful project management comes mostly from excellent communication.
3. Decisiveness - the ability to make tough decisions quickly and stick to your guns
4. Conciseness - the ability to drop pretenses and execute. Many junior project managers I know seem to throw around a lot of jargon in meetings to try and wow those not educated in the discipline. Masters I have worked with drop the unnecessary, speak on the client's level, and get to the point.

Please leave comments about this post!

Videos from Bas De Baar

Kudos to Craig for leaving the link to this in a comment he left on the last post. Videos from Bas related to the book that I'm reading now. Enjoy!

Part 1


Part 2

Surprise! Now You're A Software Project Manager

I started reading Bas De Baar's book today, "Suprise! Now You're a Software Project Manager!" Bas is a fellow contributor over at PMLC, and after hearing his interviews on Controlling Chaos and The PM Podcast, I had to pick this one up.

In the introduction, Bas touches on many key points that I could relate to, and some that I am not sure about yet. Bas makes several references early on regarding how important it is to focus on the stakeholders in any project. He discusses the relationship and progression of interests, expectations, and requirements (which he terms "The Flow of Stakes". I found this part very interesting as my last post was about soliciting good requirements, and a project I am involved with right now is having some issues creating great requirements.

He also touches on the delineation between project management and software development. This piqued my interest as I currently work on many small software development projects in which I am one of or the sole developer, in addition to managing stakeholder requirements and simplified project management. As I mentioned in my interview with Cornelius on The PM Podcast, once I started applying formal project management methods to my projects, my productivity increased dramatically. I can see the parallel with what Bas is asserting, because essentially I just split my software developer role into 2 roles. Now I am a project manager AND a software developer, even though I'm in the same job as before. By forcing myself to separate the two roles, I have become more proficient at both. I understand my expectations for each role better, and can focus on one mode of thought at a time instead of trying to both functions at once. (If anyone is wondering, I am not schizophrenic, I have just admitted the duality of my job and confronted it!)

Bas provides simple, elegant figures throughout the first chapter to illustrate his discussions. These are very helpful in understanding him fully. If the introduction is any indication, this should be a good read. I'll keep you posted!

Please leave comments about this post!

Good Requirements ARE SORTA NUTS

Have you ever let someone down even though you had tried your best and thought you were doing what they wanted? Few things are frustrating as putting forth tons of effort only to find out you were working on the wrong things.

Expectations are such an essential and common component of human relationships and communication that most of the time they are taken for granted. Taken for granted is exactly what expectations should not be.

In project management, we have a plethora of tools and techniques to help us understand expectations and meet them. We understand and fulfill those expectations through good requirements management.

Every stakeholder in a project has expectations for it, including the sponsor, team, customers, and even upper management in many cases. These expectations need to go through a review process and possibly become requirements, which in turn may lead to derived requirements that arise solely to support the main requirements. So what should come out of this review process? What makes a good requirement for a project?

I put together my own acronym based on the old standard SMART goal setting components, combined with sources on soliciting great requirements (see citations at the end of this article). I hope you like these items although I have to warn you, they ARE SORTA NUTS.

Accounted for	Documented! Documented! Documented!
Ranked	Prioritize for when you can't do it all
Empathetic	No conflicting requirements, understand diverse stakeholder needs
Specific	Clear, concise, to the point
Owned	Who's expectation is being filled, and/or is an SME for this requirement?
Realistic	Is it feasible?
Time-specific	Dependencies and timing taken into account
Actionable	Is this something you can execute on?
Need-focused	Focus on needs, not preconceived solutions
Useful	What is the business justification?
Testable	How do you know when the requirement is satisfied?
Sufficient	Enough detail to tell what they really want?

What factors do you look for in great requirements?


Sources and links:
The Art of Requirements Gathering, George Spafford
Eliciting Software Requirements, Presentation by Jesse Borschel - Sioux Empire PMI Chapter

Book Review: Human Resource Skills For The Project Manager

Human Resource Skills for the Project Manager: The Human Aspects of Project Management, Volume 2


This book by Vijay K. Verma provides a good overview of various project aspects regarding relationships, communication, and human capital in general. I personally found it helpful in the descriptions of various theories out there, and a good starting point to branch out and seek more specific research and information.

The book is split up into 6 main sections: Communication, Motivation, Conflict, Negotiation, Stress, and Leadership. Some of the areas of interest for me I took further and branched out on, and you may recognize some of the topics from posts I have been writing.

Specifically, the communication, motivation, and negotiation chapters prompted me to take further action in seeking out academic and industry research and thoughts on these topics.

This made a great textbook for my HR Project Management class this semester. I recommend it to anyone who wants to be able to better understand these areas within project management as a good place to start on the journey to self-improvement. It may help highlight some counterproductive practices you are engaging in and do not even realize.

It is set up much like you would expect a text book to be however, soft cover and short novel dimensions notwithstanding. It is not something I would classify as an easy or casual read. (It's not quite as dry as the PMBOK guide though!)

Negotiation in Project Management

Planning and change management regarding scope, resources, scheduling, budgeting, etc. can benefit from good negotiating skills. I recently studied an article titled "Social Perception in Negotiation", published in the journal “Organizational Behavior and Human Decision Processes”. The article looks into the different types of agreements that can be achieved, and makes some conclusions about the factors that make an agreement most valuable for both parties. I will discuss the article here, and share my thoughts on how great negotiating skills can be applied in project management.

AGREEMENT TYPES

The study first defines the difference between compromise and integrative agreements. Basically, in an integrative agreement both parties find they are receiving more value than they are giving up. This is mainly a function of compatibilities between what each side wants and what they can give up. This is the famed “win-win” scenario.

I visualize the iterative agreement like a zipper, where individual items up for negotiation are simultaneously perceived to have high value for side A while having less for side B. Side B is thus willing to give that element in exchange for another where the value perception is switched. Each finger in the zipper represents a negotiated element, and the further the element reaches toward the other side, the more integrative and mutually beneficial. The combination of multiple compatible elements culminates in a strong and stable agreement with high mutual benefit. An integrative agreement provides a compelling answer to the “what’s in it for me” question, for both sides.

The compromise agreement pops into my mind as more of two flat surfaces butting up against each other. Both sides are trying to compete against each other on the same items and so they reach an agreement that is unstable and provides minimal value for either side. There are no or very small fingers because neither side is giving up less valuable elements to gain more valuable ones. The split could be at the 50-50 mark, or move depending on positioning inequities or other disproportionate advantages. The result is that both A and B end up holding onto provisions of low value that might be of higher value to the other side. It also means the agreement is tenuous and doesn’t “stick” well of its own accord. These types of agreements may result in frequent arbitration or litigation to resolve disputes, because the relationship and value exchange is not strong enough to support cooperative resolutions.

JUDGMENTS

The study identified two key factors critical to optimal negotiation. They are priority and compatibility judgments. Both of these judgments are based on assumptions and information about the other party. It’s all about how well you know the needs of the other side.

Priority judgments are made regarding particular items up for negotiation and how important they are to the other side. How important is element 1 as compared to element 2. Not to you, but to them.

Compatibility judgments are made regarding the various alternatives available for negotiated items and how compatible those alternatives are for both parties. I believe it ties into the priority judgment because there is consideration on whether or not they will go for this or that proposed provision, which plays into prioritization.

CONCLUSIONS

The study concludes that accurate perceptions of compatibility or priority lead to more mutually beneficial outcomes when the potential for join gain exists. It also finds that the earlier those perceptions become accurate, the more beneficial they become towards a positive outcome.

All of the conclusions point to sharing as much information as possible, as early as possible. This results in mutually beneficial negotiations with a higher probability for an integrative agreement.

For project managers, here are some ideas on how these conclusions could be applied:

1. Scope Definition: It is important to dig into the assumptions and root causes of user requirements as early as possible. If you do this, you may be able to negotiate a different approach that will make the project run more smoothly while also giving the stakeholders a better result.
2. Resource Acquisition: When an integrative agreement is reached initially, there is more mutual benefit to be gained and therefore the party providing resources is more willing to allocate them to your project. You can also look for talent that is undervalued in their functional role and find those places in the project that are a great fit, and make the case for why they will provide more value to the functional manager by leveraging their strengths on the project.
3. Scheduling: Understanding the relative importance of deliverables to stakeholders is critical to reaching an integrative final schedule. If you only look at the task dependencies and what is most convenient for you, be prepared to miss out on great information about an optimal schedule.

If the stakeholders really care about the dates of specific deliverables, focus on those first where possible. Sometimes an output may lie stagnant for months when it could have provided value to the business, only because the project manager did not understand the significance. You may even be able to get a later project completion date because you are providing the value that really matters in an incremental fashion and playing to stakeholder needs.

4. Budgeting: One opportunity here would be where there are multiple cost centers and departments involved. By understanding and playing to stakeholder needs, you may be able to get a higher chunk of money by appealing to the group which has the most to gain. The important thing here is to tie the expense to the value they will enjoy.

Another key is the importance of understanding the true problem being solved by your project and doing a great job at the scope definition. If you just implement the wiz-bang software they asked for without knowing much about the pain you are trying to soothe, you have no bargaining power when it comes to the budget. You can not articulate a proper value proposition or appeal to the true needs of the business. How can you ask for more money unless you can link it directly to the bottom line? How can you link it to the bottom line unless you have developed a quality understanding of the true purpose being served?

REFERENCES

Thompson, L., & Hastie, R. (1990). Social perception in Negotiation. Organizational Behavior and Human Decision Processes, 47, 98-123.

Carpe Factum Revisited

Today I received an email from Timothy Johnson over at Carpe Factum. I met Timothy when he did a presentation for the Sioux Empire chapter of PMI here in Sioux Falls, SD. His presentation was titled "What your project team isn't telling you." I wrote about the presentation back in January.

I found out that Timothy's new book, Gust: The "Tale" Wind of Office Politics is available for pre-order! I placed an order today for both of his books. I haven't read either yet, but based on meeting Timothy and hearing/reading his content in the past, I'm sure they will be good. He's a smart guy with good thoughts to share, so check out Carpe Factum and Timothy's books.

Congratulations Timothy on the debut of your new book! Stay tuned for a review of both books after I've received and read them.

Young Versus Veteran Communication Styles

The feature story in the March 2007 edition of PM Network, titled "Bridging the Gap", is a look at some of the differences in style and communication that newer professionals and project managers have compared to veterans. I enjoyed the article and found some points to agree with and some in conflict with my personal experiences.

In the article there is a quote from Dave Davis, PMP, asserting that "the younger generation doesn't grasp the value of face time and the importance of building a team identity...They avoid social time and group meetings and end up identifying more with the tasks than the team."

Ouch. I can see how he might be right though. It wasn't long after I entered the professional world that I realized how important relationships are to getting things done, mostly because I had a mentor who cared enough to kick me in the teeth when I needed it:

If you are within walking distance, get off your butt and go talk to them. If that's not feasible, pick up the phone and call them. Email should only be used for following up, giving technical details, or links and attached files.

That made a lot of sense to me. I've tried to live this, although I will admit that sometimes I catch myself after having sent an email, saying "why didn't I just pick up the phone and call?" I've seen this with colleagues too, and I'll admit that it seems the younger people tend to almost seem afraid to pick up the phone and call, or walk over and talk something out. There have been a few times recently where people have come over to my desk and asked what to do with something that came through email. When I look at it I can predict with fair accuracy that it's an email chain at least 3-4 responses long, and no one understands each other. At that point I usually say, "It looks like this email is done. Give them a call." On the email chain question, personally I have a rule that if it's more than 2 replies and still needs clarification, it's time to walk over or pick up the phone.

New communication channels have come about since that sage advice mentioned earlier. Now there are chat, video conferencing, and screen sharing/online collaboration tools to manage. Chat is definitely an area were younger professionals get benefit if it's used properly, and older people do not. Most people 30 and under grew up with computers and lots of typing, and we can communicate via chat without much effort. Video conferencing doesn't seem to be too widely used yet, and if so it's usually for more formal meetings and not daily/weekly ones. Screen sharing and online collaboration tools are wonderful, especially if you are on the phone too. It can be a great way to present a tool, train, or collaborate on building project plans.

I personally see the opposite trend when it comes to following up on verbal communications with a written summary and/or action plan. I find the more experienced people seem to have a meeting and not send out meeting minutes, action items, etc. Younger and more inexperienced people like myself I would probably give a 50% hit rate on following up properly on meetings. It may be because when I send out status reports or meeting summaries, I use a set of form templates I created myself, and they are not company standard. There are no company templates for status reports or meeting summaries (that I know of). I think younger people are a little more willing to 'rock the boat' like that and create their own processes based on the conditions at hand.

In summary, I believe everyone has something to learn and improvements to make, myself included. So if you're a new professional, go find a geriatric mentor and really listen to what they have to say. Veterans with the scars of battle, go find a young whipper-snapper and show them the ropes, but listen and learn from them too.

Stress Attitudes

Stress is all around us, on projects and elsewhere in daily life. It is important to have an understanding of the manner in which people on your project team perceive and deal with stresses they will encounter on your project.

Stress Appraisal Types

Appraisal	Description	Properties
Harm/Loss	Holds a grudge or can't get over a stressful event in the past	Pessimism Hopelessness Reactive Avoiding or ignoring stressor Emotion-focused coping mechanisms
Threat	Fear of the possibility of a future stressful event
Challenge	Perceive a stressful situation in the past or future as an opportunity for growth or gain	Optimistic Hopeful Proactive Confronts problems head-on Problem-focused coping mechanisms

As a part of managing the human resources on any project, it is a good idea to list the people on your project out and understand how they cope with stress. It may give you a good indication of where hidden risks may lay in waiting, and the people you may want to check with more often to make sure they are making good progress on their tasks. People who deal with stress using emotion-focused coping mechanisms would have a resulting lower quality and timeliness output on those tasks that cause them stress, or if they are exposed to stressors outside of the project. You may want to have a better understanding of what outside responsibilities these people have that will compete for their time on your project.

Risk Attitudes

I listened to Cornelius Fichtner's new PM Podcast episode today, How do risk attitudes affect your project?

As usual, Cornelius provides great content in this episode. The interview with Janice Preston was very insightful and helped me with the concept of risk management. In school, they teach you that risk management is almost like it's own little module that you do while planning and insert into the project plan. Sometimes they talk about updating and reviewing it regularly. I've never heard them talk about it in the context of the risk attitudes of project stakeholders.

You really need to listen to this episode if you haven't already, but one aspect I liked was the classification of 4 distinct risk attitudes:

1. Risk Seeker - enjoys and seeks uncertainty in search of greater opportunities, can be overly optimistic and not take possible negative consequences seriously.
   
2. Risk Averse - uncomfortable with uncertainty, doesn't like risk
   
3. Risk Tolerant - reasonably comfortable with uncertainty, but usually sticks head in the sand and ignores them
   
4. Risk Neutral - analyzes risks and weighs negative/positive possible outcomes and probabilities objectively.
   

From my experiences with project managers, it appears to me that the majority are Risk Tolerant. I say that based on how little time and effort is usually put into analyzing and planning for risks. I can also identify with these classifications because of people I've worked with on project teams. Some people seem to have their heads in the clouds and look for risky solutions when a more proven approach would do (Risk Seeker), and others are conservative to the point of seeming cynical (Risk Averse).

Risk Neutral is the goal. Personally, I'd say I'm more of a Risk Seeker right now, but the knowledge and experience I'm gaining are directing me more towards the direction of Risk Neutral. The tools and techniques of risk management are doing that for me by forcing me to look at uncertainty in more of a formal SWOT analysis where my exuberant optimism can be subjected to some logical scrutiny.

Be sure you head over to The Project Management Podcast and check out this episode.

Please leave comments about this post! Email this post to a friend!

Becoming a Project Manager

In episode 62 of The Project Management Podcast, Cornelius interviews Thomas Cutting on the subject of breaking into the project management profession. This episode was helpful for me and reinforced some of my ideas on the subject.

One obstacle I've run into is that many of the project managers I work with now have a history where they worked in operations for 5+ years in a specific area, and worked up to be a team manager, etc. until their where either promoted or fell into a project management role within that specific department. Many don't have project management specific education or started with a goal to be a project manager.

My situation is completely different. While I have many years of industry experience with information systems and technology in general, I've never been in a specific department for any longer than 2 years. I've approached my career more from a focus of developing my PM skill set rather than industry expertise. So, the formal education and PM focus is very helpful, but how do you actually get into a job this way?

One of the recommendations Thomas made was to go in as a Project Assistant of some sort. This could be a controller, scheduler, coordinator, etc. Sometimes the title would actually be Project Management Assistant. The only problem is that PM is still a newborn thing in most companies and many do not have specific project management administrative roles like this. The project manager does everything.

If you are interested in getting into the project management profession, check out this episode.

Links:

The PM Podcast - Episode 062: How can I become a Project Manager?
http://www.thepmpodcast.com/index.php?option=com_content&task=view&id=109&Itemid=9

Cutting's Edge - Thomas Cutting's blog which has a series of posts on this topic as well
http://cuttingsedgepm.blogspot.com/index.html

Please leave comments about this post!