Computer Engineering 203 R Smith Project Tracking 12/2008 1 Project Tracking Why do we want to track a project? What is the projects MOV? – Why is tracking

Computer Engineering 203 R SmithProject Tracking 12/20081

Project Tracking

Why do we want to track a project? What is the projects MOV?

– Why is tracking important to management?

What is the MPV in project tracking for developers?– What can an individual developer gain form project

tracking?

What do we track? If we are not on track what can be done? What is the best method to communicate the data?


Why do we want to track a project?

Initially a project plan was developed, which is a road map for the project and instructions.

Tracking is the periodic checking of where we are on that road map.

Why create a road map if we do not intend to follow it or care if we are on track?


Why do we want to track a project?

Tracking gives us the opportunity to make corrections if we are off-plan.

Tracking provides a check on the quality of our planning process.

Tracking allows us to see if our basic assumptions were correct.


What is the MOV?

What is the measurable value to the organization to project tracking?

Why is it important to management?– Coordination with other departments– Commitments and dependencies– Forecasting revenue– Management goals– Customer expectations


What is the MPV?

What personal value is there in project tracking:– Less schedule pressure– More resources– Making management aware of problems while

there is still time to correct problems– Provides a wider audience for exploring possible

solutions


What Is the MPV?

Project tracking involves tasks that developers do not like to do or do poorly.

Telling developers that what they are doing is for the good of the organization is not very effective motivation.

Developer motivation needs to come from an understanding of what personal value is derived from providing tracking data.


What do we track?

The role of metrics Things we can track:

– Estimated size versus actual size– Predicted work completed versus actual work

completed– Planned dates versus actual dates– Expected resources versus actual resources– New or changed requirements


What do we track?

Any project can be off the expected plan for multiple reasons.

Each reason may require a different solution and often the wrong solution will only make the problem worse.

Metrics help provide information on what the specific problem is.


Estimated Size

The Software Development plan should contain estimates by size of each of the work products.

Tracking the actual size lets us know if the estimates for future work products will be accurate or not.

Actual size numbers can be accumulated outside the normal development process.


Predicted work completed versus actual work completed

When the project is estimated and scheduled a production rate is assumed. Tracking expected work completed per resources expended gives us a check on how valid the assumed production rate is.

Other estimates based on the same production rate should be called into question.


Production Rates

Things that can effect production rates:– Work more complex than expected– Developer learning curve– Actual versus expected tool performance– More complex logistics or communications than

expected– Over optimism for a new process


Changes to production rates

In general changing tools or process in the middle of a project will not help the production rate.

If the project is long enough it is possible to overcome the learning curve.


Planned versus actual dates

Are dependencies being met? Expecting dates to improve without taking

action.


Planned versus actual resources

Our size estimates, production rates and dependencies can be right on plan and we still are missing dates, why?

Our estimates are correct yet the developers just are not spending hours expected on the project.

– Failure to hire or high turnover rate– Priority conflicts– Unscheduled vacations, sick time, or company shut downs.


New or Changed Requirements

Tracking how and when requirements change can predict further changes in the project.

This can reflect on the requirements gathering process.

Introduction of better control methods. Did we select the correct development model?

– A model that facilitates change


Other things to track

If a project has significant costs other than direct labor then those costs should be tracked.

You should be looking at both price and quantity


What Data is Required for Project Tracking

Estimates Actual Size Defects Change Requests Actual Resources Expended


Time Cards

For most of these measures actual developer time must be accurately tracked.

How many hours spent even if over 40 or less than expected.

All time needs to be accounted for. Questions

– Recording frequency and increments– Quality checks


Now that we know where we are what can we do about it?

The four dimensions of control:– Resources– Time– Function– Quality

If nothing changes can we expect any different results?


Resources

Adding more resources generally does not help, why?– Training time– Added integration and communications costs– Integration into the team

Adding the right resources does help– Experience or special skills


Time

Most projects do not have the option to add more time.

If you can add time make sure you add enough time.– Estimated sizes– Actual resources– Changing requirements


Function

Reduce function if possible– Works best when functions are implemented in

priority order

Establish better control over changing requirements.


Quality

Quality is always an easy target.– It comes at the end of the development cycle– Less objective measures are used

Is there a bottom line to quality?– Does reduction in quality just postpone work until

after release when it is more expensive.


What else can be done?

Many times removing road blocks is the most effective way to get a project back on track.

Common road blocks– Communication issues– Minimum hardware resources– Training– Priorities


How can we communicate the data?

Before deciding how to communicate your tracking data you need to decide on your objective.

Are you conveying information and with no expected action needed?

Do you want action if so what and when?– Be prepared to say what you want by when.

Lay the ground work so there are no surprises


Metrics

What are project metrics?– Data/facts– Metrics are measured– Metrics are objectives

Examples


Metrics

Metrics are important because they give management an objective way to look at progress, quality and performance

Metrics must provide solid data without subjective input such as

– The code is 80% done There are very few institutional-standard software

metrics, metrics need to be team and project based.


Metrics

The importance of meaningful data GQM– Goal, Question, Metrics

Goals: what are we trying to determine? Questions: what data pertains to this goal? Metrics: How can we measure it? Is the data useful?


Metrics

It is important to remember that our goal is to use the data we get through metrics gathering to make a decision.

If the data does not lead to making a decision either now or later then why are we collecting data.

Most resistance to collecting data comes from a lack of understanding of how the data will be used or the belief that the data will not be used.


Other basic Metrics Concepts

Reliability– Is the data repeatable

Validity Criteria for Causality

– Is there a logical reason to expect that the action can actually cause the results.

– Which league wins the Superbowl predicts the stock market


Common uses of Metrics

Tracking progress– Use of resources– Schedule– Size

Defects– Density– Arrival rate

By project phase

Process Improvement


Tracking Progress

Are the resources we planned for available? Are we using more resources than we

planned? Looking at actual hours not just days or

weeks.


Tracking Progress

Are milestones being completed as planned? Are milestones really being completed or do

we expend resources even after the milestone is marked completed?

Are milestones objective and binary?


Tracking Progress

How does actual size compare to estimated size?

What is our actual production rate compared to our historical production rate?

Is our measure of size a true reflection of the resources being used?– Criteria of Causality


Tracking Progress

Typical problems– Size Estimate incorrect– Production Rate incorrect– Resources expected not available– Dependent milestones not fully met

Each of these problems would appear as a schedule slip, but the corrective action for each is different.

– What would be examples of corrective action?


Defect Tracking

What can we do with the defect tracking information?– Defect density points to code that needs to be

reviewed, recoded or designed.– Predict customer experience.– Metrics of early phases can indicate corrective

actions needed in later phases.– Is testing as good as expected?


Defect Tracking

Defect Density– By code module, feature or function– Determine where resources should be focused to achieve

the greatest results. Provides insight as where problems are occurring.


Defect Tracking

Arrival rate– Are we discovering problems at an unexpected rate?– Results should be normalized over hours of testing

Determine the trend line of the arrival rate– A declining rate indicates product is stabilizing– A raising rate indicates an unstable product

Defect fix rate, are more being found faster than being fixed.

By phase allows us to look at the success of our development process.


Defect Tracking

By project phase– When was the problem created and when was it

discovered?– Does the quality plan discover problems early enough– Helps determine if development processes can be improved


Process Improvement

Process improvement drives most metrics programs yet the improvement process is rarely the focus of study itself.

It is important to understand if the changes being introduced in the name of process improvement actually do produce changes not just additional work.


Process Improvement

Do we have a baseline?– How good are our estimates?– How good is our quality?

How do the changes we make in the process effect our progress and quality?

What is the value of our changes compared to the cost?

Documents

Computer Engineering 203 R Smith Project Tracking 12/2008 1 Project Tracking Why do we want to track a project? What is the projects MOV? – Why is tracking