As a PMP, you can have your cake and eat it too!

There’s no greater professional satisfaction than celebrating the success of friends.  I had the pleasure of doing that with three great TAPUniversity alums and new PMP’s: Geri, Mike and Mike at Sorintino’s in Omaha.

Related articles

• Asad Naqvi: Passed the PMP Exam 23-01-2011 (pmhub.net)
• Certification Exam Feedback: PMP , CBAP , CISA , CISM , CISSP , ITIL , CSM , Lean Six Sigma (tapuniversity.com)
• Jiri Khun: My PMP Exam Lessons Learned 5.1.2011 (pmhub.net)
• Cornelius Fichtner, PMP: Don’t use too many PMP Exam Prep Books (pmhub.net)
• A-KS: Passed my PMP on Jan 27 (pmhub.net)

What's over there?

We have IQ, there’s Emotional Intelligence (EI) – I say we add  EQ – environmental intelligence based on applying that Emotional Intelligence to what’s going on with stakeholders.

A quick recap, a stakeholder is someone who has a professional interest in the outcome of a project.  That interest may be acknowledged and formalized – corporate board, supervisor, project team and internal or external customer.  It also may be unacknowledged and informal — parallel project teams; teams up or down stream of the project’s production flow (e.g., Shipping), or through a functional group associated but not directly affected (e.g. accounting or marketing).

A stakeholder’s analysis is typically an informal data gathering process.  Perform it during a project team meeting.  The following three steps are recommended:

Identify who will be impacted by the project inside and outside the organization.  It is helpful to draw it on dry erase board or flip chart in a counter clock-wise fashion with the candidate project at 3 o’clock.

Identify outcomes, desirable (+) and undesirable (-).

Identify how often a group should receive information.  Information gleamed here feeds into the project’s responsibility assignment matrix (RAM) or RACI.

Why is this helpful for managing conflict in virtual teams?  Understanding the information and communication needs of stakeholders is critical in all teams, in virtual teams the opportunity to pick up informal, non-verbal ques is far less.  So a project manager needs to be much more deliberate to unearth potential problems

Related Articles

• Virtual Teams – Conflict Resolution – Prepare (tapuniversity.com)
• Virtual Teams – Conflict Resolution, Risk Assessment (tapuniversity.com)
• 5 Common Types of Conflict Found in Project Teams (brighthub.com)
• IQ or Wits Check; Fallacies and Cognitive Biases from Game in the Brain (gameinthebrain.blogspot.com)
• 10 Typical Activities of a Project Development Team (brighthub.com)
• 10 Ways to Resolve Conflict Between Project Team Members (brighthub.com)

Preparing the baking pan for project success!

Conflict. The mere term evokes a strong response. In today’s environment, examples of conflict are replete: Middle East, War on Terrorism, Political Divides. Intra personal conflict also appears to be increasing. Project managers also encounter a variety of conflicts: inadequate resources, changing organizational direction, project direction, disagreement among stakeholder groups, clash with functional teams, role conflict, team unity, and missed communication.

The answer to the first question is yes – conflict will occur.

That is not necessarily bad. Consider this. The Latin root of conflict (conflictus) means to “strike together”. Popular connotations are conflict pulls “apart”. Unresolved conflict pulls apart. Properly resolved conflict brings vibrancy to a project.

In 2002 I wrote a series of articles addressing conflict in virtual teams and shared some steps to actively manage conflict using a the acronym PRE-EMPT. 

The first step is to Prepare. Learn from past projects. Historical information is vital (it’s also a part of Organizational Process Assets now, a rather universal Input). Use it. Understanding and learning about past project flows in general and conflicts in particular provide a powerful insight to a current project.

Know your own standing as a project manager. Are you new to project management, new to the organization, or a veteran of several successful campaigns? Regardless of the entry point, it is vital to understand your strengths and weaknesses as well as how you are perceived by the team, stakeholders and organization. What are the team’s strengths and weaknesses? If the team is newly assembled, then time spent seeking this at the beginning pays dividends.

You hope they have your back

While delivering over forty Effective Virtual Team workshops at TAPUniversity since 2006, one question we encourage participants to ask is “well, OK, how does this differ from team members we see in person?”

Swift Trust is one concept worth digging in to help answer the question of differentiation.

Trust applies to all teams. Teams lacking trust do not function effectively: they hoard information, seek self-serving interests over the good of the many, and end up in defeat. Teams with trust, however, rise above challenges, they build each other up, and contrary to many, they can be extremely successful.

Trust is needed in both virtual and in-person teams but what is different for virtual teams is the concept of swift trust. That is, you afford someone trust on a limited basis, with whom you have not met in person. Basically, allowing them the ‘benefit of the doubt’ until that trust is breached.

Trust is built through consistent behavior and delivery. For virtual teams, trust that begins ‘swiftly’ needs consistent nurturing. A week long gap in communicating with someone you typically see face-to-face does not seem as long as going a week without receiving an email, phone call or discussion board thread from someone at a distance.

Swift trust that is lost in a virtual team is often more difficult to regain than in-person teams. To repair broken trust these three steps are helpful:

• Acknowledge the breach in performance through as personal a medium as possible (e.g. phone call rather than email)
• Make commitments for communicating progress and yet don’t over commit to make up for a wrong. That typically leads to a downward spiral of further misses.
• Stay as fact-based as possible and avoid over interpretation or excuses

This may be you, right now. Or if not, in your near future!

Virtual teams are geographical dispersed teams (GDT) who are formed for a variety of reasons.  Sometimes the virtual team is formed as a result of mergers and acquisitions (M&A), or a collaboration among organizations may trigger it, perhaps a key employee moves or a company wishes to get some “boots on the ground” in a new city.  Regardless of the motivation, virtual teams are a given in a dynamic global community.

The Fourth Edition PMBOK references virtual teams as a tool and technique for Acquire Human Resources (Section 9.2).  That single tool and technique can produce a wealth of questions for the PMP exam.  From conflict, to communication overhead, twenty-four hour work cycle and requirements gathering challenges – there’s a long list of topics to discuss and validate.

Virtual teams are a practice area for TAPUniversity.  We have studied them and helped others become proficient in managing them since 2005.  Frequently traditional management wisdom does not apply and may even back fire.  Virtual teams also have proven a sticking point for the Agile SCRUM movement, which, in its initial manifesto, had co-located teams as key principle.  Over the next few weeks we’ll dig deeper and share more about virtual teams.

Please share your experiences as well.  What’s worked well?  What hasn’t?  What’s changed for you in the last ten years in working with virtual teams?

Don't let a plate or estimate fall!

Schedule (Activity Duration or Activity Resource) and Cost estimating are two lynch pins for business analysis and project management. The most common estimate techniques are: analogous, bottom-up, parametric and three-point – PERT.

For those pursuing a CBAP® or PMP® how to use them and whether those are mutually exclusive can become a bit confusing.  The hundreds of exam banks for the PMP® exam often seem to force a PMBOK® based exclusion (see Sections 6.3, 6.4 and 7.1).  That is not accurate.   The estimates for schedule and cost are in practice used together and also not presented as mutually exclusive on the PMP exam.

Now for a quick review of how the four estimate types might work together.  Let’s use a swim meet as an example.

• Analogous estimate - just like the root word analogy implies, analogous estimates are based on a previous project(s) within the organization.  This estimate is often the earliest and most convenient one to gather.  Because of that it is often used to justify a project and for project chartering.
  Example when I help conduct a swim meet we have an intuitive sense of how long a meet of 50, 100, 150, 200 or 250 swimmers will take.   My role is typically whatever is needed and most often starter, referee or stroke and turn judge.
  For a meet we conducted Saturday – based on 210 swimmers for over 70 events with a 20 minute break – our analogous estimate 
  

  Lining up swimmers is like herding cats into the water.

  was 8:30 a.m. to 3:45 p.m.  The various swim meet official team members were a bit nervous when official entries received by Wednesday were 50 more than anticipated.  So our analogous estimate that had been 8:30 a.m. to 2:00pm was revised upward.  Adding a bit to our anxiety was the threat of winter storm (two teams were traveling over 50 miles).

• Bottom-up estimate – this estimate gathers cost or schedule from the resources or subject matter experts (SME) involved in performing the activity.  The idea is rooted in quality management – those that do the work really  have the best idea of what is involved.Using the swim meet example again, we ask coaches, those that help line up the swimmers (clerk of the course), time (timers), judge and officiate  how long each stroke (free, back, breast, butter fly, individual medley and relays)  might take and then use those estimates alongside seeded times for each swimmer to create a schedule.
  For that Saturday meet – our bottom up estimate was 8:30 am to 2:52 p.m.
• Parametric estimate - this estimate looks at aggregate estimates from across an industry.  A treasured pocket-book of mine is the Wilson’s pocket estimator (circa 1985).  It’s full of construction estimates for time and resource load, from plumbing to drywall.  I used it for estimating paint jobs during my undergraduate work.  Visiting the swim meet example. the USA Swim Association and YMCA swim governance offer guidance for indoor and open water swim meets.
  For that Saturday meet the YMCA swim guide estimate was 8:30 to 3:30 p.m.
• Three-point/ PERT (program evaluation and review technique) - this estimate typically is used with the other three techniques to develop a pessimistic, most likely and optimistic schedule per activity.  We did not apply this to every activity (event/heat) for the meet.  I did do a quick three-point for the 25 yard events (where timers move from one side of the pool to the other).  The timer travel time took anywhere from 90 seconds to 4 minutes (quite a range) with the most likely or mean travel time of 3 minutes 10 seconds.  My quick 3-point estimate was 2 minutes 53 seconds.

SWIM MEET Actual – the meet went from 8:30am to 3:18 p.m or within the estimate range. The meet was ahead of the bottom-up schedule in the early morning due to combining two 500 yard events into one.  The meet fell behind the bottom-up schedule in the late morning as the 25 yard events were conducted (a dummy activity or lag for timer travel time was not entered).

So what?  As you incorporate the estimating techniques, incorporate all four if possible.  Analogous and Parametric estimates are found by asking someone in your organization (analogous). Nimble use of “Google” will help find your industries Parametric estimates (e.g. COCOMO for software development or Wilson’s estimator for construction).  Bottom-up involves talking with key resources and getting a sense of who will perform that activity for your project (for example a new team member will not produce as quickly as a 7 year SME).  Three-Point / PERT can be used selectively for higher risk activities or ones that you want that second look.

For example the probability of a shipping delay during the busy holiday / Christmas season might be 25% or .25.  The impact on a project is moderate or a .5 on a 1.0 point scale.  The Risk Priority Number (RPN) is .125.   By contrast the probability of a layoff is low during that peak season or .1 but the impact could be far greater on production or a .9.  The RPN would be.09.  So if there are only sufficient resources to devote to one risk, that one would be shipping delay.

The RPN also is used in the Lean Six Sigma Failure Mode Effects Analysis (FMEA).  Another factor is added, detection ability.  FMEA then calculates Impact x Probabilty x Detection.  The result is a RPN .  So RPN makes its presence known in project management and lean six sigma

On a broader scale risk management is also a part of business analysis, IT compliance, information security, IT data center management, auditing and software development.  Risk management is a good example of the “Management Nexus” at work!

Software Estimating - when is it due? Oh yea, now!

Earlier postings described PROBE and COCOMO (“PROBE” posted April 14, 2010 and “COCOMO” posted April 15, 2010) which are two techniques for making software project estimates. The Putnam Model is yet another technique that can be employed in the project planning stages to estimate the time and effort of a proposed software project. It is best applied to large projects. The Putnam Model was developed by Lawrence H. Putnam and he named his commercially available tools based on the model “SLIM” which stands for Software Lifecycle Management.

In order to calculate effort, these equations account for the overall size of the product and project, the allotted scheduled time, and the productivity of the team. Putnam’s company, QSM (http://www.qsm.com/), sells tools not only to make estimates for future projects, but to track current projects and analyze past projects.