"I like to connect to people in the virtual world, exchanging thoughts and ideas, when in the physical world we might never have the opportunity to cross paths."  - Demi Moore


The quote above says a lot about how we interact with others because of today's technology. With social media allowing us to connect with others regardless of geography we are truly becoming a virtual society. This is also true for our working relationships. The virtual workforce is growing. Currently 25% of the US workforce works remote at least one day a week. Forrester estimates that by 2016 43% of the workforce will be virtual. Virtual teams are not new to project management but they do require special attention to work well.

Last year I moderated a panel on the virtual workforce. One of the questions asked of the panel is how do their organizations address team building of virtual teams? Some of the answers dealt with the use of technology such as video conferencing and chat rooms. Other answers focused on establishing regular meetings. governance, and cadence. However, one specific answer triggered my though process the most. One of the panelists mentioned that personal things such as acknowledging team members birthdays or holidays in different countries was important. This answer got me to realize that although the project team may be virtual it is still a team and the team dynamics needs to be managed.

When managing a virtual team encourage interaction among the team members. When a issue arises think about assigning it to two team members to work jointly. Encourage team members to reach out to each other with questions. Use team meetings to conduct peer reviews. The more the team interacts in this manner the less it seems like a virtual team and the more it functions as a well built team.

This week the tweets looked at at project estimation using the estimating by analogy method.

Estimating by analogy is done by comparing the effort for tasks / deliverables of the current project to past projects with similar traits.

So the first thing you need for estimating by analogy is data from past projects. Actual data is the best if you or others has tracked it. If you don't have a lot of past data you can still do the analogy method by using data from industry sources. Another way to get data for the is to estimate standard elements of the project such as web pages, interfaces etc. to develop base numbers

Once you have your baseline numbers you can now build the first draft estimate. Start by identifying elements to be built for the project. Then for each element identified categorize the complexity as high, the same, or low compared to the base element. Now you need to determine the time or effort change based on the complexity. E.G.the baseline web page takes 16 hrs to develop and unit test.

You can the say that a low complexity web page will take 12 hours and a high complexity will take 24 hours.

Do this for all the elements and then add up the numbers. Add in test, rework, and deployment time. This will give you your first draft estimate. It is best if the team helps with the estimates as the more expertise used the more accurate and complete the estimate will be. If you have multiple people estimating a particular element make sure to use the average numbers and not the best case or smallest. You want the estimates to be reasonable and doable.

"You're Outta Here!" - Managing Conflict on a Project

 I wrote this tip a couplf of years ago. With spring training around the corner I thought this would be a good opportunity to repeat it. Readers of the weekly tips and those people who know me are familiar with my love of baseball. Many however may not be aware that I have been a High School baseball umpire for 18 years. When people I work with discover this they look at me like I'm mad. "So you're telling me that after being yelled at all day as a project manager you willingly go to a ball field and get yelled at by coaches and parents?" The answer is yes, I love it! In baseball the umpire has the final say as he / she can eject a coach or player if their arguments become overzealous. I will admit that early in my umpiring career my arguments with coaches resembled those famous scenes of Leo Durocher kicking chalk on a major league umpire. As time has passed I have learned a lot about handling these situations better to avoid throwing coaches out whenever possible.

 As project managers we don't have the ability to throw somebody out. However, many of the techniques I have learned on the field can be applied to the everyday project world. So when dealing with conflict, keep the following in mind:

1.   Watch your body language. As umpires we are taught to stand erect with our hands at our side when talking to coaches. Crossing your arms, slouching etc will tell the other person you don't want to listen or don't care.

2.   Control your language and tone of your voice. If the other person raises their voice, don't raise yours. That will only escalate the argument. Pick your words carefully when responding.

3.   Acknowledge what the other person says to show you are listening. Look for common ground in the discussion. Make sure the other person has concluded their comments before you explain your position.

4.   If the conflict occurs during a meeting or in a public area, suggest that you meet in private to discuss the issue. If the discussion is heated, suggest meeting later to provide a cooling off period.

Leo Durocher once said, " I've never questioned the integrity of an umpire. Their eyesight , yes." Keep this in mind when dealing with conflict. You and the other person may not agree but you are both trying to accomplish the same thing, a successful project. If you treat others as professionals they will do likewise and you will both solve the issue together.

Project Estimation Techniques - Function Point Analysis

Function point analysis has been around since 1979. It uses 5 types of functions to categorize the software. The 5 functional types of function points are outputs, inquiries, inputs, internal files, and external interfaces.

There are many artcles and books on Function points. Here is a link to a primer bit.ly/43KWT4 by Alvin J. Alexander

To estimate the size of a software project you identify the type and complexity of each FP. Using a FP model an unadjusted score is derived. The UFP is then adjusted using the results of looking at 14 factors
Function points give you the size of the software effort which you can then put a cost to. You also need to add in costs for testing etc.

There are lots of resources for learning about function points. One place to start is the IFPUG, International Function Point User Group. One of the advantages of function point analysis is that fps give you a measurable value that can be used to provide other project metrics. Function points give you a measurable method to determine the size of a software effort. Function points also give you a measure of complexity for each function. This can be used to better plan testing and debugging costs

"When you wish upon a ....."

Requirement. Such a simple word, but one of the major causes of project stress. All projects have requirements. IT projects, houses, ships, marketing campaigns all have functionalrequirements that must be fulfilled. Yet on may projects the requirements are not fully documented or even missed. On other projects there are two many or too complicated requirements for the time, resources, or money available. How does this happen?

 

Project issues due to the requirements arise because important aspects of requirements gathering were not done. These aspects include:

·Understanding the current processes being used

·Making sure that each requirement is understood and agreed to

·Making sure each requirement is testable

·Associating a cost with each requirement

·Having a business owner for each requirement

·Tying each requirement back to a scope statement or goal

·Eliminating "wish list" requirements

On any project, the requirements to be delivered should be only those that are truly needed. There really are no nice to have requirements

Replanning a project that is failing

When a project is in trouble and the delivery date is clearly going to be missed, the project stakeholders immediately start asking for a new date. Usually the team's inclination is to answer the question with a revised date that is derived in one of three ways:

1.A new date two to three months out is selected out of thin air.

2.The team discusses options and selects a new date that they believe is aggressive but doable.

3.The team does a replanning exercise and comes up with a new date based on revised estimates.

All three of these methods can lead to only one final answer, disaster. Option 1 assumes that time was the only factor impacting the project and adding an extra month or two will magically fix the those issues. Option 2 is doomed because the stakeholder's inclination is to believe the team wasn't aggressive enough and will insist that they be more aggressive. Option 3 is always a non-starter because the stakeholders don't trust the new timeframe because the original one was obviously incorrect. In most cases the final result is that the stakeholders select a new date that borders on the realm of science fiction or a least a "B" horror film.

Why does this happen? Business stakeholders and senior executives see project work differently than those of us who deliver the project. The goal of the project is to deliver a result that provides strategic or tactical value to the company. When a project is delayed, the reward the stakeholders were counting on doesn't occur. Their number one driver is to get that reward as soon as possible. By providing a new date for delivery without  providing them additional information on why the new date is necessary, the stakeholders will generally react negatively. To avoid this, the stakeholders need to see three things from the replan:

1.That the project team balanced being aggressive with risks.

2.The project team looked at options for delivery and took into account business needs.

3.The team addressed the underlying issues that caused the project to get into trouble in the first place.

The following is from a set of tweets I sent on basic estimating techniques for projects.

The first estmate done for most projects is a Rough Order of Magnitude (ROM) estimate. This usually is done for approval and budget purposes. ROM estimates are usually done on major scope items and are based on past experience or similar other projects. For an auto insurer a project to add a new product to the billing app may have cost $250K. A new product project est. could start at $250K. Once you have a base ROM you can adjust it based on complexity, estimated delivery date etc

The first detailed estimate for a project is done once the initial requirements have been defined.

One trick I use with estimates is to estimate per requirement. This helps avoid scope creep and gold plating because you can see the cost. When estimating tasks get several people to give you an estimate. Use the average and then round up to even increments such as 8, 12, 16 hrs

Use past project metrics to help with estimates. Actual data from past tasks is one of the best measures of how long a task will take.

Next week I will look into more detailed estimating techniques such as function points.