Ten Fallacies to Watch Out for in Projects

Posted on January 30, 2012 by Alvin

Projects inherently involve a lot of communication from a lot of people with a lot of different backgrounds. This type of environment provides a breeding ground for fallacies which results in poor decisions that ultimately hurt the success of the project. Below is a list of ten common fallacies you will see in projects. The list is a subset of what I found in Wikipedia with my thoughts added at the end each definition.

  1. Ad hominem (attacking the arguer instead of the argument) – This is usually done through name calling or labeling the person something deemed negative. This usually happens when a person runs out of reasons to support their argument so have to resort to attacking your character. It is important to understand when this is happening as it can negatively influence decisions. It also speaks to a greater problem of respect in the project team.
  2. Cherry picking (suppressed evidence, incomplete evidence) – act of pointing at individual cases or data that seem to confirm a particular position, while ignoring a significant portion of related cases or data that may contradict that position. This problem is more apparent when you have a strong personality doing the cherry picking as others will not speak up to point out suppressed evidence. When you do not feel good about an argument, it is sometimes a good idea to talk individually to each person to hear all the facts.
  3. Hasty generalization (fallacy of insufficient sample, leaping to a conclusion, secundum quid) – basing a broad conclusion on a small sample.  This hurts when people are too quick to fix something before they understand the real problem or if a problem really exists. A good project change and escalation control structure can reduce this fallacy.
  4. Argumentum ad baculum (appeal to the stick, appeal to force, appeal to threat) – an argument made through coercion or threats of force to support position. This is something I see between business and their IT or business and a vendor. This can work for short term issues, but it hurts the long term relationship which can bring much more to the table.
  5. Argumentum ad populum (appeal to belief, appeal to the majority) – where a proposition is claimed to be true or good solely because many people believe it to be so.  This is something I use to start the conversion on an issue. You first want to ask what everyone else does. In saying that, you should never base the final decision on this alone. It should be based on the facts on why the proposition is true as there are cases where it will make more sense for you to go with a different direction. Continue reading →
Posted in Best Practice | Tagged , , , , , , , | Leave a comment

The inside of the Project Triangle (quality)

Posted on December 6, 2011 by Alvin

Most project managers have heard of the Project Triangle. It is the scope, cost, and time of a project. It is the three lines of the triangle that the project manager is always monitoring and controlling to make sure a successful project.

You will hear people say that if you change one it must effect one (or both) of the other lines. This is great in theory and looks like it make sense when you stare at the triangle, but the reality is that many projects do increase scope and neither the cost or the time is affected. So how do they do this amazing trick? The secret to this lies inside the the project triangle. They do it by exploiting the ’quality’ of the deliverable produced. You do this in one of many ways that could include:

1. Rush through the construction or development
2. Skimp on the system of user testing
3. Use of inferior materials

So even though you might have met the scope, cost, and time your project will have produced a mediocre product. You sometimes see the project triangle with the word ‘quality’ in the middle and that is just as important as scope, cost, and time.

This is not to say you should not use the project triangle, but you definitely should not rely solely on it for a successful project without also monitoring quality. Probably the best place to address quality is through non functional requirements. Add quality requirements and get this signed off. Couple this with a good change process and you will be making something you can be proud of.

Posted in Best Practice | Tagged , , , , , | Leave a comment

The pros of SharePoint for Project Management

Posted on May 15, 2011 by Alvin

While browsing through the Girl’s Guide to Project Management (found here) I came across a case study on using SharePoint for Project Management. Having used SharePoint for Project Management I thought this would be a good blog where I could elaborate on the case study.

Overall, SharePoint is a great tool for project team collaboration. The Project Manager can highly customize a project SharePoint site to track issues, risks, expenses, milestones, contacts, calendar, and so on. The search feature is great as it not only goes through every item and doc in your site, but it can also look inside documents. Another great feature is the integration with MS Office as you can work on your documents directly in SharePoint. It also features built-in versioning of docs so you can see all the past changes you made and who made them. And if someone accidentally deletes a document you have a 30 day recycle bin to save the day. On top of all this is the ability to set permissions on any doc, list, or item in a list. What is nice about this is you can make your project schedule read only for everyone except yourself.  This is just the basic stuff as a power user could push the site even farther with SharePoint Designer and workflows.

Where SharePoint lacks is in Portfolio Management. It is not intuitive to bring the data together from all your project sites and roll that data up into portfolio dashboard reporting. This gets more difficult if the project sites have been modified by the project manager.  This can be overcome, but it does take a little work and standardization.

Posted in Random | Tagged , , , , , , , | Leave a comment

Knowing when to zoom into the project

Posted on May 8, 2011 by Alvin

The level of detail that a project manager should be involved in a project should not be static. As the project progresses the amount of oversight needed fluctuates and the project manager needs to adapt if they want to make best use of the resources available. For a project manager who does manage at one detail level you have two extremes.

The first is the project manager who always manages from very far and with very little direction. This can lead to a project going way off plan and a lot of finger pointing when problems arise. The project team will also think you do not do anything and have no respect for you. More so if they see the project manager taking two hour lunches.

On the other spectrum is the project manager that is involved in every single little detail and will even go so far as to act as the subject matter expert on every project deliverable. This approach can suffocate a project team and gives the impression that you do not trust them. You will end up finding a project team that does not want to work very hard for you. It also takes up all the time of that project manager, making the person either only able to handle one project or work long hours.

I find the best way to manage is dynamically. The project manager should step back when they see that everything is on track and zoom in when they notice potential risk around the scope, cost, or schedule of the project. Another important time to zoom in is when the project is nearing a major milestone like an implementation. Not only does this build trust with the team, but they see that the project manager will swoop in to help when needed. This will maximize your time so you can run multiple projects effectively.

Posted in Best Practice | Tagged , , , , , , , , , | Leave a comment

How to get people to agree on a document . . . on time

Posted on April 30, 2011 by Alvin

When people are unable to agree on a project deliverable, like requirements or a statement of work, there are a few tricks you can do to ensure these deliverables are completed on time.

  1. Identify the decision maker for the deliverable. This way, if people disagree you can look to that person and have them make the final decision. If you have trouble finding one person with the authority to make the final decisions it means you are not looking high enough. For contracts it is a little different as you need the legal counsel from both sides to agree. In this instance make sure you have one lawyer from each side that can make the final decision on the wording.
  2. Plan ahead for review and rework. Too often I have seen a person deliver a rough draft on the day that the final deliverable is due. What ends up happening is that deliverable is pushed back a few weeks to finalize and (often times) the project has to keep moving forward with an incomplete deliverable due to time constraints. So if you know your requirements are due in three weeks, setup a review meeting for each week. And do this early so you can secure time from people’s schedules.
  3. Make the changes on the spot. This is needed when you are crunched for time and the deliverable is on the critical path. The document in question should be up on the wall (or via a web conference) with the document owner making the changes right there for everyone to agree on. The people in the room should consist of those that can make the final decision on issues and relevant subject matter experts. The group should be limited and not include the entire project team. Whoever is running the meeting should be firm and focused on completing the project deliverable. Depending on the length of the document and number of issues, the meeting length can be one to three hours long. For contracts this can be a whole lot longer.

There you have it; a few tips to ensure project deliverables are completed on time.

Posted in Concepts | Leave a comment

Four tips to maximize project communication

Posted on March 27, 2011 by Alvin

As a project manager your primary job is communication. Beyond the status meetings and project plan you will be giving and receiving information in a variety ways. Also, you are dealing with people who will be busy on multiple projects and support related problems. Here are some tips which take a small amount of effort for a lot of pay back.

1. Use of Color and Font. Color can be very powerful when communicating. In a project you have a ton of information that is going out and by using color you can quickly direct people to what you want them to see first. Take the below lists for example:

Report One Report Two
Project A – Green                      Project A – Green
Project B – Red                          Project B – Red
Project C – Green                     Project C – Green

As you can see the text in bold red quickly stands out. When the above list is a full-page, or more, it becomes all the more important that you let the reader know what they should be focusing on first. Continue reading →

Posted in Best Practice | Tagged , , | 1 Comment

Breaking Down Project, Program, and Portfolio Management

Posted on March 21, 2011 by Alvin

People often get confused with project vs. program vs. portfolio so I thought I would give a quick rundown of the differences. Below is a simple diagram showing the relationships between each word.

 

Continue reading →

Posted in Concepts | Tagged , , , , , | Leave a comment

Three roles of the Project Management Office

Posted on March 10, 2011 by Alvin

When someone says PMO most people think of a team of Project Managers, or some say Project Manglers, and a long list of procedures they need to follow. I would say this would have been true in the past, but these days the expectations of the PMO has shifted and can vary greatly from company to company. First off is the name, you have some that think it should be called a Program Management Office while others like to call it a Portfolio Management Office or even Enterprise Portfolio Management Office. I prefer Project Management Office as you are dealing with projects regardless of the number. Another name that I think works well would be a Project Portfolio Management Office. Whatever the name, they all basically try to do the same thing. Below is a diagram I drew of three roles of the PMO I plan to cover.

Continue reading →

Posted in Concepts | Tagged , , , , , , , , , | Leave a comment

The Project Cartoon

Posted on March 6, 2011 by Alvin

I remember first seeing a version of this on someone’s wall and cracking up. I then noticed different versions so after doing some investigation I found the site where you can create your own versions of the cartoon at http://www.projectcartoon.com/.

Posted in Random | Tagged | Leave a comment

The Cohesive Project Team

Posted on February 24, 2011 by Alvin

One of my favorite diagrams on building a strong team is the pyramid from the book ’The Five Dysfunctions of a Team’ by Patrick Lencioni (see below).

What I want to do is discuss this chart as it relates to project management and from a positive point of view. Instead of looking at this from five dysfunctions, the author also listed 5 functions of a cohesive team. This consists of the following:

  1. They trust one another.
  2. They engage in unfiltered conflict around ideas.
  3. They commit to decisions and plans of action.
  4. They hold one another accountable for delivering against those plans.
  5. They focus on the achievement of collective results.

Continue reading →

Posted in Best Practice | Tagged , , , , , , , , | Leave a comment