This weeks tweets looked at tracking actuals, revising estimates during the project, and using estimates to complete to measure progress. There are 3 great reasons for tracking actual hours and costs on a project.
#1 is that actuals help track overall progress against the plan
#2 reason to track actuals is that they give you information you can use to make adjustments to the plan during the project.
#3 reason to track actuals is they give you data to plan future projects. The more actuals you have the better future estimates can be.

If you use a project scheduling tool such as MS Project or Workbench make sure to baseline the plan before you start entering actual hours. As you track and record actual work hours against tasks you can start to see trends and get info that can be used to revise the plan. Actual data lets you revise estimates for future tasks.E.G. If the 1st 3 web pages took 10% longer you can update the other page estimates.

Revising estimates is not a bad thing. Having this data can help you make decisions so the final delivery date can still be met. Another metric that can help you manage the plan is estimates to complete or ETCs. ETCs are the hours estimated to complete a started task.

Every week have resources with open tasks give you their ETC. This does 2 things. 1) It lets you determine if the task will be done on time. The second use of ETCs is to give you a heads up that a task needs more time. Getting this data early lets you make proactive adjustments. For example if a task is taking twice as long you can look to see if it is too complex or if you need to get other resources to do other tasks to keep the schedule on track.

This tip is a compilation of tweets that look at how to fine tune project estimates and turn them into a work plan.

After the first draft estimate is done, take a few days to have the team, stakeholders, IT, and business resources review and comment. Once the team and others have provided comments go ahead and make adjustments to the estimates. Make sure all deliverables have estimates.

After making adjustments now look at the estimate versus the budget. You wait till now to avoid building the estimate to fit the budget. If the estimate is within 10% of the budget, high or low, you are probably ok to create the workplan. Double check with mgmt to make sure.

The first step to build the workplan is to group the tasks you estimated into logical groupings, Start at a high level such as coding. The next step is to further group the tasks into functional or like groups. E.G.you can group web screen coding or new policy tasks. The next step is to identify the dependencies between tasks.

Once the dependencies are listed you can identify the critical path. This will be those tasks that are dependent that take the most time. The reason for the critical path is the CP will tell you if the project can meet the expected delivery date or to set a delivery date. If the CP date is ok then you can complete the plan and begin to communicate it to the team and stakeholders.

"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