Jeff Floyd on Management

The list below contains recommended project management web Sites. To help keep the list clean and scalable, the links are grouped into categories.

Professional Organizations

• www.pmi.org
• www.asapm.org

Project Management Tools

• www.microsoft.com/project
• www.project-management-software.org

General Project Management Information

• www.gnatthead.com
• www.allpm.com
• www.4pm.com

Project Management Education

• www.zervigon.com

Justin
What are some good ways to improve project management awareness, understanding, adoption, and execution in a project team?

Jeff
Let us assume that the culture of the team is one that does not understand project management. In this case, I have conducted 3 to 5 day “quick start” project planning meeting. In these meeting, we cover each of the initial project planning steps as a team. First, I teach the theory, then we apply that theory to a real project. For example on day one, I spend a couple of hours on the purpose of a project charter, and then we write a project charter. Next, I talk about WBS, and then we do a WBS. Then comes activities, tasks, sequencing, resource assignments, effort, risks, etc. We end with a list of action items that must be completed to baseline the plan.

This technique educates this project team on techniques and sets expectation for performance. It also goes a long way to build the team.

Use this approach project by project and soon the organization will understand PM.

Justin:
I like your approach and will look to adopt it going forward.

Over the last few days, I have participated in a discussion with Justin on various Project Management Topics. With his permission, I am sharing our discussions with you as a series of posts.

Justin:
The first topic on project management that I’d like to discuss would be the barriers to establishing strong project management practices and baking project management into the culture of companies big and small.

Jeff:
Primary barrier is the value proposition. Many folks jump on the project management band wagon without a basic understanding of what it is, what it does, how it works, and most importantly what it means to the culture.

Therefore, we want project management. OK, Why? What problem will it solve and how? What form or project management do we want? Are we prepared for decisions to be made by project managers? Will we have a PMO? If so, what will that look like? It is strategic or tactical PMO? Do we understand the difference?

Next if the company does not have the PM skill set in house, how will you go about getting it? It takes a great PM to interview PM’s and select a great PM. Any idiot can interview and select a bad PM. How long will it take to find out?

Justin:

I fully agree with your response and see teams continue to struggle in project execution and management make knee-jerk decisions based upon superficial and often inaccurate data. All due to poor project management, bad project managers, and the lack of organizational adoption and understanding of project management practices.

You mention the value proposition. An issue that has recently been researched by PMI. They should have or soon will publish their finding. I watched a webcast on it, I liked what I saw, and the information presented.

Vendor Evaluation Template is an excel spreadsheet that will allow you to do a simple evaluation of multiple vendors responding to a procurement activity. The template is a good example of the “weighting system” of vendor evaluations.

What is a weighting system?

A weighting system is a method of quantifying data to minimize the effect of personal prejudice on source selection.

High level process:
Step 1: Define the evaluation criteria

Step 2: Assigning a numerical weight to each of the evaluation criteria

Step 3: Rating each prospective sellers on each criteria element

Step 4: Multiplying the criteria weight by the vendor rating for each criteria element

Step 5: Totaling the results to compute an overall score

In this example the highest scoring vendor is the vendor that is the best fit to the evaluation criteria. This vendor may not be the best overall fit. That determination is made after negotiations.

Comments are welcome.

Use at your own risk.

Source: http://www.nwfusion.com/newsletters/gwm/0406gw1.html

1. Construct your copy list on a need-to-know basis. Be careful in using large distribution lists for highly focused topics.
2. Use formal language (with complete sentences, business letter formats and correct spelling) and a well-thought-out structure when communicating with senior management or customers. Remember, an e-mail message helps to create an image of you and your company.
3. Avoid large attachments if at all possible. Background documents of interest to a subset of the recipients can be put on your intranet.
4. Be prompt in responding to action items. Acknowledge an accepted action item with an e-mail response even if you can’t get to it for a while.
5. Avoid e-mail wars. Take personal conflicts offline, and handle them privately.
6. Use auto response messages to notify correspondents if you are out of the office or on vacation and won’t be able to read messages.
7. Put meaningful data in the subject field. Many users are responding to information overload with filters and rules-based agents.
8. Don’t use e-mail to highlight negative thoughts about senior management. It can be too easily forwarded or misaddressed.
9. Observe common practices within your organization. Every organization has a unique culture, and this also applies to e-mail etiquette.

Version 98 and up

• Use a Work Breakdown Structure (WBS) to add structure and logic to the task list.
• DO NOT assign a resource or time to a summary task
• Do Not use summary tasks as a dependency (Unless it is to be removed later)
• Do not assign a dependency to a summary task (Unless it is to be removed later)
• Assign resources to tasks before adding hours
• Assign only one resource to any task
• If a task has more than one resource it may need to be broken down further
• Use Verb Noun format for task names
• Make each task name complete and able to stand alone. (If the task is pasted into an email, it will be known what the deliverable is with out the context of the WBS structure.)
• No task over 40 hours in length. If longer break it down.
• Do Not use dependencies to level resources.
• Use priorities, leveling and manually moving tasks.
• Set leveling options to use Priority and task number to level.
• Set leveling options to split tasks
• Dependency field is length limited (in 98)
• If task A and B have a Finish-to-Start relationship, then make sure A will complete before B starts. If work is started on B before A is complete, sometime the schedule will react strangely
• Accounting for less than 100% productivity can be tricky. Before assigning a resource to any task, open the resource sheet and create needed resources. Set the max units for the resources that will have less than 100% productivity. When you assign the resource to a task that productivity number will be used and show up as a percentage to the right of the resource name in the list.
• Future Lessons
• Find a way to deal with
• < 100% efficiency Hard to check the network integrity
• Find a way to deal with out of project activities (if not in scope should not be in schedule)

When planning or re-planning a new project keep these handy tips in mind. They will save effort later in the project.

• Do not assign tasks to people outside the team. Make someone on the team responsible for the task.
• Structure the WBS on how progress will be measured (% complete if deliverable for example)
• Introduce new features via Change Requests
  • Defect for bugs,
  • Suggestion for enhancements.
• If a defect CR will be worked on by multiple people, go ahead and break the single line rule and pass the one person per task rule.
• Schedule defects with one line item on the schedule.
• Schedule suggestions with full development life cycle
• Do a component level responsibility matrix
• Do a Deliverable based responsibility matrix
• Add milestones to the schedule for?
  • Code complete
  • Feature freeze
  • Code Freeze
• Add section to executive status summary for scope changes
• Put risks in categories and summarize the risk for reporting
• Consider milestone chart for executive report
• Review designs before implementation.
• Use” use cases” to justify design
• Schedule tracking, status report with re-occurring task not a broken task
• Schedule only one person per task.
• Use priority to help leveling.
• Do not use soft dependencies, it is hard to maintain
• Input feature development and tasks in priority order wrt WBS
• Include debug cycles in schedule.
• It is OK to have unlinked build and test tasks that are re-occurring
• Schedule testing by test case
• Have a separate schedule for marketing requirements development managed by marketing. (Hold them to their schedules. They will hold you to yours.)
• Hold re-planning session for major scope changes
• Print schedule at least every other week and post for all to see.
• Find a way to do risk management
• Update schedule daily

If you have ever managed a project you know that email overload happens very quickly. A primary responsibility of every project manager (and team member) is to communicate effectively and timely. When starting on a project, consider setting up a set of folders to manage email communications. I suggest starting with something like this.

Project Name:
Requirements
Plan
Risks
Schedule
Design
Implementation
Testing
Process
Configuration Management
Change Requests
Reports
Communication
Procurement
Vendor 1
Vendor N
Financial
Customer Interaction
Lessons Learned
Inventory Control
Human Resources
IP
Documentation
Training
Facilities
Beta Sites
Beta Site 1
Beta Site N
Releases
Release 1
Release 2
Release N

Reporting the status of your project is the single most important way to keep your stakeholders informed on the progress, direction, and health of your project. What follows are lessons on reporting different aspects of your project.

Software Test Status / Defect Reporting
A good way to monitor and report  test progress is to track

• the number of test cases started as a percentage of the complete set
• track the number of new test cases started each week
• the number that fail

From this you can predict the number of weeks you have left to complete the first pass of functional testing.

Graphs are much more effective in communicating defect status compared to tables with the same information. The graphs can contain more historical information and are easier to defend.

Use one graph with cumulative defects found and cumulative defects resolved. Use another graph for number of defects entered, resolved, verified, and closed per period (usually per month).

Design the defect tracking process to separate defects on a per release basis. It does not matter when the defect was fixed (in terms of the release) just that is was fixed.