Networking, Patience, and Self-torture

If I am looking out for a job and see that a guy in a senior position may be of help to me, how do I ‘pretend’ that I am of help for him and he should connect with me, when the reality is that in this case, atleast for the time-being the ‘help’ will be going only one way – him to me. For a direct person, who does not like beating around the bush and pretence, this networking bit becomes tricky. I know it is my weakness, but I am finding it hard to overcome it.

I go through the same doubts, especially when connecting to somebody who is many levels above me. But I look at it this way. We must take time to be polite.

The connection

Suppose you come home and, before you even put down your briefcase, your roommate or spouse starts telling you all the things on the repair list and all the things that went wrong today. To-the-point requests make people feel the same way.

People do things for friends that they will not do for strangers. Good manners includes telling a new acquaintance what you admire about them and explaining something you have in common. It establishes a bond. If you don’t have any reasons that you can turn into a compliment, then why are you connecting?

The request

Remember, it’s about your contact, not about you. You don’t want to put him in a position where he has to sound mean. So I ask, “If you think our interests fit, may I join your LinkedIn network?” or “…would you add me to your LinkedIn network?”

The offer

You try to connect with as many people as possible, right? If you, yourself, do not have confidence to offer help, you can still offer to connect them with somebody else who can help them. Sometimes I ask, “As I build my network, what skills or knowledge could I look for in people I might send your way?” (Of course, now, you have to start keeping track of the answers!)

Another way might be, “Does your organization face any challenges where I could watch for resources for you?”

Patience

I’m sure there are much better ways to say such things, and you should always adapt your words to the person you’re connecting with.

Remember, establish a relationship before asking for something. Better yet, don’t ask for anything until

• they offer to help, or 
• you have been able to do something for them.

When you’re desperate for work, it’s very hard to be patient, but it will get you much better results.

For further reading, see a great article with excellent comments:

• Ruhl, Susan. LinkedIn Networking 101: What Not To Do. Careerealism

Differences between Risks and Issues in Projects, Part 1

Differences between Risks and Issues in Projects, Part 1

Issues

Updated 1 June 2014

People define issue in many ways, but in project management, issue has a special meaning.

In everyday English, one synonym for issue is topic. An issue is a situation that merits discussion. For example, the issue, what caused the last ice age or is man's contribution to climate change significant compared to factors such as volcanic ash and the variability of our star.

Everyday issues include past, present, and future situations. Discussions about issues may or may not lead to actions. Often, when we say that something is an issue, we imply that people disagree about it.

In project management, an issue is a situation that merits consideration because it affects the project. For example, the vendor left our parts to rust on the dock and will not ship them until they get paid, but our policy prohibits paying for the shipment until we receive and inspect it.

If the issue is significant, the project team will study actions that would reduce or remedy the situation effects on the project. This leads to change requests.

Part 2 (click here) focuses on the definition of risk and explains a side of risk that most PMP prep materials overlook.

Copyright 2013, 2014 Richard M. Wheeler

Links to Management Resources

General Management Resources

• World Health Organization - Leadership and management topics
• Defense Acquisition University - Search engine for DAU resources
• Department of Energy - Directives, delegations, and requirements
• EverySpec - Collection of free US government (NATO, too) specs, standards, handbooks

Process Asset Samples and Templates

• Project Management Docs - PMBOK based project management templates
• Brad Egeland - Sample PM plans & templates, with links to related articles

Project Management Newsletters

• The Program Manager's Paper - Articles and links to articles useful to project managers

Project Management Resources

• Lessons Learned.info - Lessons learned (LL) in the context of project management (PM)
• Certified Enterprise Risk Manager® Academy - Risk-based problem solving & decision making, enterprise risk management: resources, training, certification, newsletter
• Herding Cats - Informative blog entry on uncertainty, risk, and risk management

Project Management Tools

• PM Tools Review - Project management & PM-related tools and services

PM Social Media and Online Study Groups

• Google Plus - Project Management, PMI, PMP Certification - Oliver Lehmann's outstanding Google+ group for PMP test prep, Agile, PM news recommended articles, almost everything PM
• PM Lessons Learned - Conference calls for PMP exam study, job hunting, and best practices every Tuesday plus the first through third Thursdays, 9 PM New York time; Archives of presentations and also a discussion capability are available at http://groups.yahoo.com/group/pmlessonslearned/

Technical References

• Department of Energy  - References, regulations, and requirements
• University of Maryland Space Systems Laboratory Spacecraft Design Reference Library
• EverySpec.com - Government and military standards, specifications, handbooks, and documents

PM Blogs

• The Southern Project Manager - Harry Hall's practical project management insights and tips

PM Study and Free Resources

• PM Study - Free Simulated Practice Test, Sample Guides and Podcasts, Work Experience Hour Calculation Tool
• PM Success - 400 Questions of the Day
• Head First Labs - Free PMP Practice Exam
• Simplilearn - Articles and instructional videos

Agile Study and Free Resources

• ScrumStudy - Free learning resources (including the ScrumStudy BOK) - Hat tip to Kylie Wilson in the Comments.

This is a work in progress. Add links to your favorites in the comments, below, and I'll add them.

Understanding the Rule of Seven

Context: Discussion of the Rule of Seven in statistical process control 

Problem: In some industries, one cannot wait for repeatable errors as defects and errors lead to loss of life. I was told that, in pharmaceuticals, a certain % of death is acceptable and almost expected. The waiting process or period of time before halting tests or evaluations is where I am stuck.

First, let's use the terms specified value and control limit rather than errors or defects.

 

Also, we would normally discuss this topic in terms of parameters that have numeric values such as temperature, weight, and speed. In this conversation, we want to deal with measurable characteristics long before they result in catastrophic failures.

Rule 1. Out-of-bound conditions

If you have just one value outside the control limits, such as a severe side effect from a drug, you stop the process and figure out what went wrong. 

Rule 2. Calibrating the results

The Rule of Seven (or Run of Seven) does not apply to parameters that go outside the control limits. The Run of Seven applies when seven consecutive, acceptable values lie on the same side of the specified value. Such a situation indicates that the average has deviated from the desired value and you need to recalibrate the process so that the average is close to the specified value.

Illustrating with a made-up scenario

Suppose the scientists at Schpooky Pharmaceuticals want to test an inoculation against the HG (Heebie Geebie) virus. In order to train the immune system to fight off a full invasion of Heebie Geebies when somebody sneezes on us, the inoculation has to cause a fever of at least 0.5 degree F. They calibrate the variables in making the vaccine and in the dosage to cause a 1.0 degree F fever, or a temperature of 99.6 degrees F.  In this test, they set an upper control limit of 3.0 degrees, or a temperature of 101.6 degrees F.

 

Specifications:

• T = 99.6 degrees F, average
• 99.1 degrees F < T < 101.6 degrees F

Using the first rule, just one person develops a temperature of 103.0 degrees F. We stop the tests to see what's gone wrong because 103.0 > 101.6, the upper control limit.

 

Using the second rule, if we have seven consecutive people develop fevers between 99.6 and 101.6, we stop the tests to see what's gone wrong. These temperatures are all acceptable, but they are all greater than the desired value.

 

The Run of Seven indicates a special cause -- that is, one or more variables in the process need to be controlled. Maybe the dose is too large and needs to be reduced. Perhaps the HG virus needs to be baked five minutes longer. So we make the adjustments and then resume the trial.

 

These rules and others like them serve to stop a process long before it reaches catastrophic failure such as the death of a patient.

But catastrophic failures do happen

You might wonder, What about the catastrophic failures? They do happen! What about the one in 10,000 who dies? How can that be acceptable?

 

This takes us to other techniques such as Decision Tree analysis (p. 299 of the Project Management Institutes Project Management Body of Knowledge (PMBOK) Guide, 4th edition).

 

Suppose withholding the vaccine results in 1,000 deaths per 10,000, but giving the vaccine causes one death in 10,000. If you distribute the vaccine to 10,000, you save 999 lives.

 

Unfortunately, many drug companies withhold such drugs because that one in 10,000 will sue them, and the juries will severely punish the companies.

 

This issue, tort reform, is one of the dividing lines between the political parties in the US. A project manager needs to use various decision-making methods and maintain awareness of a wide range of environmental factors.

The Difference between Accuracy and Precision

In technology and science, accuracy and precision are different, although they go together.

For the measured characteristic

• Precision is described by the range of values.
• Accuracy is described by the difference between the average value and the specified value.

Lets have a goal of making two batches of cookies and specify that they measure 5" across. Afterwards, we measure the cookies.

Chocolate cookie widths

• Average = 5.10 "
• Range = 0.25"

Cinnamon cookie widths

• Average = 5.01"
• Range = 0.50"

The chocolate cookies have a smaller range of sizes, so they are more precise. The average size of the Cinnamon cookies comes closer to the specified value, though, so they are more accurate.

 

Does that seem counterintuitive?

 

For a measurement or a measuring tool

• Precision is described by how many significant figures the tool gives you.
• Accuracy is described by how closely the measurement matches the value of a standard device and also by how accurate the standard is.

As another example, I have two 18" rulers.

• One came from a store that sells drafting supplies. It is graduated in 16ths of an inch.
• The other, I made for myself after I loaned the store-bought ruler to a neighbor kid. I based it on one cubit (18"), the length from my elbow to my finger tips. When I graduated the cubit ruler in 50ths of an inch, I eyeballed the measurements and marked it by hand.

 The cubit ruler is more precise, but the store-bought ruler is more accurate.

Project Management and Open Communications

Project Managers need to guard against setting up an environment where bad news never reaches them. They need to praise and encourage those who communicate risks before they become issues, issues before they become problems, and problems before they become project failures.

Some managers remind me of the Clinton trial in the Senate, following his impeachment in the House.

The Senate set up a rule requiring Ken Starr to keep all the records and evidence in another building. Bringing it to their offices without an invitation would have violated protocol.

Then the majority of senators refused to go view the evidence. A few who did view it said they came away weeping, and the rest (having refused to view the evidence) said that they lacked evidence sufficient to convict.

Does your comfort zone tempt you to maintain willful ignorance? Does your character allow reliance on plausible deniability? The PM has accountability for project success, which any lack of awareness may bring about; but that accountability extends to achieving success ethically.

 

I wonder:  Do PMs ever include ethical lapses as project risks?

The Best Project Management Software

Project management covers many knowledge areas. Developers approach PM software functionality from the perspective of a particular discipline or PM knowledge area. The approaches usually focus on a narrow selection of the following needs:

• Requirements
• Software Development Life Cycle (SDLC)
• Agile methods
• Model Based Systems Engineering (MBSE)
• General verification/validation
• Software test management
• Software test management with scripting
• Issue and change management
• Product definition from a market research angle
• Scheduling
• Cost management
• Resource management
• Project communications
• Scope and requirements definition
• Quality management
• Configuration management

As a result, all the solutions I have looked at work for only a small portion of project management. For example, MS Project would be useless for requirements management, and DOORS would be useless for project scheduling.

 

Some developers stress integration of their products with other products -- preferably their own. For example, Rational (specializing in SDLC) bought DOORS and worked on integrating the two product lines. Then IBM bought Rational and expanded the integration effort to include other IBM products.

 

Implementing many PM software products and then tailoring them to the organization's needs can require permanent, trained resources. Integrating several products can take years, even in large organizations.

 

With the current state, I believe any attempt at a total PM solution will require a very large initial effort, significant support to maintain the solution, and an acceptance that some interfaces between PM processes just have to be done by hand.

 

Therefore, to answer the question, "What is the best software/tool for end-to-end Project Management?" you need to prioritize the areas of PM because no product addresses the end-to-end needs -- or at least, the top-to-bottom needs.