I have a book entitled “What Makes a Good Project Manager” by James S. Pennypacker and Jeannette Cabanis-Brewin. In the book, there is a reference to a 2001 ComputerWorld article that discusses “The Perfect Project Manager”. The consensus of the article was in the world of Information Technology (IT) there are three general areas of Project Management competency: Technology, Business, and Behavior (in no certain order).
One of the CIOs interviewed in the ComputerWorld article stated “in order to motivate IT workers, you need … an understanding of human behavior and how to motivate teams.” Do not miss this important point. Project Managers are primarily team leaders, motivators, and communicators. Project Managers will not be successful managing IT projects if they do not have an understanding of basic human behavior.
It has also been determined there are three Project Management skills that are required for success in IT:
General Management Skills
Project Management Skills
IT Management Skills
Under General Management, the key areas of expertise are (not in order):
Thinking Skills
Organizational Awareness
Leadership
Interpersonal Relations
Communication Skills
Many companies are now interviewing Project Managers placing a heavy emphasis on character traits versus professional competencies. These companies realize if a Project Manager cannot get along well with others and have poor communication skills they will not be successful.
The key to project success is having a competent project manager and the number one competency of a project manager is honesty. Research has shown that projects are more likely to fail because the human elements are not managed. In order to mitigate this type of risk project managers need to develop skills that support sound decision-making, good communications, motivational techniques, and conflict management.
Tuesday, May 17, 2005
Tuesday, May 10, 2005
Are You Trustworthy - Part II
I have always admired Stephen Covey’s writings. In his book “The Seven Habits of Highly Effective People” Mr. Covey talks about being Trustworthy. As project managers if we are not trustworthy, we are not going to be effective. When you are trustworthy, you can be counted on to keep your word. Trustworthiness is a qualitative measure so we cannot apply some objective measure to how honest or reliable a person is.
As mentioned in Paul Friedman’s Book “How to Deal with Difficult People”, Paul states “Faith in people is fragile”. “Every single breach of trust diminishes people’s confidence in you”. Paul goes on to say, “Most people believe themselves to be more trustworthy than others think they are. We forgive ourselves more readily for minor transgressions that linger in other people’s minds. We know why we neglected to do something. We know we had a good reason and intended no harm. However, others cannot read our minds or know what our lives are like”.
Take your promises seriously. When you are unable to keep your commitments, be quick to admit fault, explain, apologize and do whatever is necessary to repair the damage and reassure others that you will redouble your efforts so you do not repeat the same mistakes. Trust is earned, but it is earned only after you demonstrate that you are Trustworthy.
As mentioned in Paul Friedman’s Book “How to Deal with Difficult People”, Paul states “Faith in people is fragile”. “Every single breach of trust diminishes people’s confidence in you”. Paul goes on to say, “Most people believe themselves to be more trustworthy than others think they are. We forgive ourselves more readily for minor transgressions that linger in other people’s minds. We know why we neglected to do something. We know we had a good reason and intended no harm. However, others cannot read our minds or know what our lives are like”.
Take your promises seriously. When you are unable to keep your commitments, be quick to admit fault, explain, apologize and do whatever is necessary to repair the damage and reassure others that you will redouble your efforts so you do not repeat the same mistakes. Trust is earned, but it is earned only after you demonstrate that you are Trustworthy.
Friday, May 06, 2005
Project Requirements and the WBS
The project manager is responsible for controlling a project's requirements. To start the process of managing requirements the project manager works with the team to create a Work Breakdown Structure (WBS).
A couple of things to keep in mind regarding a WBS are:
A WBS should identify the level tasks to be completed, and relate to the project’s deliverables.
The customer(s), project sponsor, and stakeholders are actively involved in creating the WBS.
The WBS helps avoid future "scope creep".
As you can see the WBS is an important project artifact. The WBS accomplishes several things:
It assists the project team to identify and create specific work packages
It is another way of communicating the project's objectives to the team
It is the foundation for future project planning and activity sequencing
In closing, a WBS summarizes deliverables, shows work relationships, helps the team to estimate costs and perform risk analysis, and assists the team to identify project assumptions and dependencies.
The WBS is your friend. Start taking time to create one for every project.
A couple of things to keep in mind regarding a WBS are:
A WBS should identify the level tasks to be completed, and relate to the project’s deliverables.
The customer(s), project sponsor, and stakeholders are actively involved in creating the WBS.
The WBS helps avoid future "scope creep".
As you can see the WBS is an important project artifact. The WBS accomplishes several things:
It assists the project team to identify and create specific work packages
It is another way of communicating the project's objectives to the team
It is the foundation for future project planning and activity sequencing
In closing, a WBS summarizes deliverables, shows work relationships, helps the team to estimate costs and perform risk analysis, and assists the team to identify project assumptions and dependencies.
The WBS is your friend. Start taking time to create one for every project.
Tuesday, May 03, 2005
Business Process Mapping
Does your organization perform business process mapping? Mapping of business processes is important if you want to understand what is happening. Mapping your "as is" processes tells you a lot about what you may already know, but also a lot about what you don't know.
When you begin to map your processes, you will start to see the activities, products, information, and decisions being made that support the process.
Some reasons to map your business processes are:
Mapping the "as is" processes will assist your team when doing detailed analysis
Helps to identify process ownership, and identifies the roles that support the process
Helps to show the difference between cycle time and value-added time
Helps to measure process performance
Helps to identify problem areas to address
Establishes performance baselines when creating "to be" processes
Identifies process bottlenecks, and disconnects
Shows relationships between activities and products
NOTE: When looking at what processes to model, the processes that cross functional business areas should be addressed first.
Three principles to keep in mind when process modeling are (in this order):
Eliminate wasted time and work
Consolidate efforts where possible
Automate (where it adds value)
When process mapping we are always asking questions like "why are we doing this", "why are we not doing that", "can this step be eliminated, consolidated, automated", "can we do this step/sub-process better, faster, smarter, cheaper”? Business process mapping can help your organization to operate more efficiently and respond to change faster, which ultimately will lead to improved customer satisfaction.
For more information be sure to Google "Business Process Mapping" or "Business Process Modeling"
When you begin to map your processes, you will start to see the activities, products, information, and decisions being made that support the process.
Some reasons to map your business processes are:
Mapping the "as is" processes will assist your team when doing detailed analysis
Helps to identify process ownership, and identifies the roles that support the process
Helps to show the difference between cycle time and value-added time
Helps to measure process performance
Helps to identify problem areas to address
Establishes performance baselines when creating "to be" processes
Identifies process bottlenecks, and disconnects
Shows relationships between activities and products
NOTE: When looking at what processes to model, the processes that cross functional business areas should be addressed first.
Three principles to keep in mind when process modeling are (in this order):
Eliminate wasted time and work
Consolidate efforts where possible
Automate (where it adds value)
When process mapping we are always asking questions like "why are we doing this", "why are we not doing that", "can this step be eliminated, consolidated, automated", "can we do this step/sub-process better, faster, smarter, cheaper”? Business process mapping can help your organization to operate more efficiently and respond to change faster, which ultimately will lead to improved customer satisfaction.
For more information be sure to Google "Business Process Mapping" or "Business Process Modeling"
Friday, April 22, 2005
Project Management Basics
To improve your project management results you need to look back over your organization's project management successes and failures. In doing so patterns or trends will emerge that will help you pinpoint areas for improvement. Research in the area of project management has shown the following simple steps can lead to radical improvements in your project management results.
Here are some ideas:
When starting a project a core team of competent, motivated people must be assigned as early as possible to the project and kept on the project until the end.
The project manager is held responsible for managing the success of the team and for motivating and monitoring the team's performance.
The project manager position needs to be a full-time position with documented job responsibilities.
The organization must ensure that the project manager is held responsible for the success or failure of the project.
The project sponsor's organization and/or the end user group(s) are responsible for defining the specifications of the project's product. This is not a project manager's responsibility, however the project manager works to coordinate these activities.
A project plan (word document) needs to be developed with the cooperation of the core team.
Developing the project plan is the responsibility of the team, not just the project manager.
A lessons learned/project close-out meeting needs to be held at the end of every project to determine if the project objectives were met and to identify project management process improvements for future projects.
A communications plan must be developed for the project, and kept up-to-date.
There are many other items we could add to this list, but the ones listed here are vital if an organization wants to have any success at managing projects.
Here are some ideas:
When starting a project a core team of competent, motivated people must be assigned as early as possible to the project and kept on the project until the end.
The project manager is held responsible for managing the success of the team and for motivating and monitoring the team's performance.
The project manager position needs to be a full-time position with documented job responsibilities.
The organization must ensure that the project manager is held responsible for the success or failure of the project.
The project sponsor's organization and/or the end user group(s) are responsible for defining the specifications of the project's product. This is not a project manager's responsibility, however the project manager works to coordinate these activities.
A project plan (word document) needs to be developed with the cooperation of the core team.
Developing the project plan is the responsibility of the team, not just the project manager.
A lessons learned/project close-out meeting needs to be held at the end of every project to determine if the project objectives were met and to identify project management process improvements for future projects.
A communications plan must be developed for the project, and kept up-to-date.
There are many other items we could add to this list, but the ones listed here are vital if an organization wants to have any success at managing projects.
Tuesday, April 12, 2005
Communicating with Discretion and Tact
How are your project communications? How do others perceive you? How do you perceive yourself as a communicator?
Let us review some rules of communication that will help us better manage our projects.
When making presentations know your:
OBJECTIVE – Goal, Purpose, Destination
LISTENER – Know facts about the group, the group expectations, the key people
APPROACH – Premise, Strategy, Theme, Pay-off for the Listener
When speaking with others one-on-one, use statements that show you are concerned about them. Remember the three “A”s when communicating.
APPRECIATING – Show appreciation for the other person’s problem or situation
Examples: “I appreciate you bringing this to my attention”
“Thank you for letting me know that”
ACKNOWLEDGING – This lets the other person know that you hear them
Example: "I can understand…”
“I sorry to hear that..."
ASSURING – Lets the other person know that you will help
Example: “This will be taken care of…”
“I will see to that personally.”
Some thoughts to ponder…
Project Managers that do not communicate effectively at the right times are destined to fail.
Poor communication skills have derailed many a career.
More than likely you will never be told that your communications skills are lacking.
Every project needs to have a written communication plan.
In closing, there are many good resources available to help us all improve our communication skills. A couple of books you might consider are: “The Four Agreements” and the “Seven Survival Skills for a Reengineered World”.
Wednesday, April 06, 2005
Conflict in Negotiations
In the book "Field Guide to Project Management" by David I Cleland, there is a discusson on page 282 about "Conflict in Negotiations". As the book mentions, PMI (the Project Management Institute) outlines eight project management functions that can be a source of conflict.
To paraphrase from the book, the areas are:
Scope: what is to be done (results, products, services)
Quality: what measures, what steps to be taken
Cost: financial outcomes, savings, ROI
Time: deadlines, resources, when complete
Risk: what risks are accepted, avoided, deflected
Human Resources: what resources, what skills, availability, competency
Contract/Procurement: cost, requirements/specifications, when, how, what, where
Communciations: when, how, to whom, contains what
There are several ways to approach handling conflict (see the Guide to the PMBOK), however the important point to keep in mind is we must confront the issue(s)and work with the individuals or groups to come to a win/win outcome.
Unresolved conflict can often lead to bitterness and resentment, which can linger and rise up later to sabatoge your project.
To paraphrase from the book, the areas are:
Scope: what is to be done (results, products, services)
Quality: what measures, what steps to be taken
Cost: financial outcomes, savings, ROI
Time: deadlines, resources, when complete
Risk: what risks are accepted, avoided, deflected
Human Resources: what resources, what skills, availability, competency
Contract/Procurement: cost, requirements/specifications, when, how, what, where
Communciations: when, how, to whom, contains what
There are several ways to approach handling conflict (see the Guide to the PMBOK), however the important point to keep in mind is we must confront the issue(s)and work with the individuals or groups to come to a win/win outcome.
Unresolved conflict can often lead to bitterness and resentment, which can linger and rise up later to sabatoge your project.