« Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part I - Introduction
Conducting Effective Meetings - Part 3 – Facilitate The Meeting »

Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part II - Pitfalls of Not Doing A Detailed Customer Interview

October 23, 2007 | Author: PM Hut | Filed under: Communications Management, Project Management Best Practices, Project Stakeholder Management, Role of the Project Manager

Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part II - Pitfalls of Not Doing A Detailed Customer Interview (#2 in the series Successfully Interviewing Your Project Customer and Gathering Project Requirements)
By Keith Mathis - PM Expert Live

Today, unless a thorough business interview is undertaken, the project plan will have numerous pitfalls from scope creep to fast paced change. These pitfalls will cost the average project huge amounts of productivity and efficiency while increasing the potential of failure. What is a shame is that many of these pitfalls can be prevented, if only the project manager and project team had participated in a customer interview.

Pitfall #1 – Starting a project with an unclear target

Starting a project with an unclear target sounds like only a fantasy; however, each day many project managers will do this very thing! An unclear target can best be defined as a lack of details and understanding about the goal and objective that the project will deliver. Getting as much information about each of these components and target areas is very important to everyone on the team, to the success of the project, and to the clarity needed to hit that target every time.

Pitfall #2 – Neglecting to nail down measurable objectives

A second pitfall that many face is that the details of the project are not measurable and are very subjective in nature. When a project team is trying to run a project with subjective measurements, they really have no measurements at all. Due to this, it is unclear when they have actually reached the end of the project. It is almost impossible for someone to think that the project has been successful due to the fact that it is in the eyes of the customer, and people will always second guess their solution and add some additional piece or component to this project.

Pitfall #3 – Creating an atmosphere which enables scope creep

Scope creep is defined as the creeping of the project’s parameters beyond what is specified in a detailed scope statement. Since the project team has begun a project with little or no information, it is almost certain that the scope is going to creep, and that it is going to go beyond the parameters as designated by the project team. In seminar after seminar, one of the frustrations that project managers and team members discuss is how the scope creeps throughout the project and is considered a normal part of their culture. The idea of scope creep is something in which many customers will take full advantage, if allowed. It will over commit your project team and your resources. You especially see scope creep used as a normal part of internal behavior when employees are paid a salary and are looked at as “free” in relationship to resource expense. An example of this would be federal, state, city and county employees who are already on salary and working on projects. Most of the time, their salary is not considered in the budgeting process of the project and so, in jest, the employee is considered free. We know that this is not true. The employee is not free and only has a limited amount of time to allocate to the projects. Due to over scheduling, the “free” employee’s time is committed anywhere from 125% to as much as 175% due to the creeping of the project’s scope.

Pitfall #4 – Increasing the possibility of failure to your project

Pitfall number four revolves around increasing the possibility that the project will fail. Project failure is always possible, regardless of which project team is working. However, when you do not understand the target, you have increased the possibility that the team is going to misdirect the project. Many teams only possess a perception of the target rather than a real goal to be achieved. When this happens, it increases the potential that this project will fail and cost the organization a great deal of money. It is very important to reduce these pitfalls. One of the strongest ways of being able to avoid this is to conduct a detailed requirements gathering interview.

Dr. Keith Mathis, founder and CEO of The Mathis Group, specializes in Project Management, Management Leadership, and Marketing training for private businesses and government agencies of all kinds. He offers 33 Project Management courses, is a Project Management Professional, is certified by the Project Management Institute and will customize every training session to your individual company’s needs. The Mathis Group also sponsors www.pmexpertlive.com, which is a powerful project management resource with free reports, podcasts, videos, and a monthly newsletter. He also offers customized management training and coaching on any subject with prolific communication and professionalism.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Tuesday, October 23rd, 2007 and is filed under Communications Management, Project Management Best Practices, Project Stakeholder Management, Role of the Project Manager. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories