Define: Technical Debt

Technical debt: Engineering changes you owe a project before it can be signed off as completed.  E.g. software, electrical, mechanical, ergonomic, and other engineering issues to be resolved.   If you’re tracking bugs, enhancements, defects, and other project issues, then you no doubt have some technical debt.  In other words, your team owes the project something before it can be said to be complete.  Every one of those issues should be documented, fixed, and verified by an objective party before project completion. Engineers, and in fact everyone, tend to sweep little things under the rug.  Especially when they don’t know how to resolve them.  Can’t fix that annoying little bug?  Easy answer: don’t tell anyone.  That’s just human nature.  Hide your deficiencies.  Make yourself look good.  Ignore the hard things. A good project team culture faces up to difficult little deficiencies.  A simple line item in a bug tracking tool like Standard Issue® makes them public, and that resolves most of the “facing up to them” issues.  Now everyone knows they exist, and must eventually be dealt with.   –ray

Define: Work Variance

Work Variance: Difference between the current ‘Work’ value and the baseline ‘Work’ value for a task .  In Microsoft Project, this is a read-only column.

 

There are a lot of variance fields in Microsoft Project, and they all relate to baselines.  Baselines are a way to compare your current values with original estimates.  A baseline captures all task values, including ‘Work.’  Weeks or months after capturing a baseline, you can compare those original estimates with current numbers.

To save a baseline in Microsoft Project, choose Tools, Tracking, Save Baseline.  To view all the baseline values, choose View, Table, Variance.  This changes the columns in the current view to show variances to the baseline.

 

–ray

Define: Deadline Date

Deadline: A date associated with a task’s finish date, after which an indicator appears in the ‘Information’ column of Microsoft Project.

 

Microsoft Project allows you to set a deadline date for each task in an MPP project file.  This date is closely linked to the task’s finish date.  See the link below to set a deadline for a task.

http://www.projectteamblog.com/?p=43

 

I prefer deadline dates to task constraints.  They are simple and informal, and do not affect downline task dependancies.  In other words, they simply show a red symbol next to the task rather than affecting the starting dates of other tasks.

 

But honestly, Microsoft Project® is not as elegant as Standard Time® when it comes to time-related things.  It has no timesheet, and cannot accurately track employee hours for tasks.  Obviously, there is an ‘Actual Work’ column, but has no effective way to fill it. Standard Time® is much better suited for that purpose, and it has a task deadline feature as well.

 

–ray

Define: Earned Value

Earned Value: The amount of money a project has already earned, based on percent complete.

Calculating earned value will let you know approximately how much money is in the bag.  Obviously, it has to pass through the Accounts Receivable department, but eventually the money will be there.  This scheme works well for projects where money tightly follows work.  In other words, you do the work, and the money follows soon after.  While that’s often true of service-based companies like consultancies, it is not always true of manufacturing projects.

When a company manufactures goods, there is a much longer pipeline to cash.  Money does not tightly follow work.  You develop the product, test it, manufacture it, test it again, market it, sell it, and then your customer pays.  That process can take months or years.  So earned value is not as tangible.  And, there is the upside of selling the same design for several years.

Standard Time® calculates earned value based on Actual Work times the Client Rate.  Obviously, this is very tightly connected to the work you perform.  Every hour means billable time.  For consultancies, this matches reality pretty closely.

–ray

Define: Critical Path

Critical Path: A series of tasks that extend a project to its longest finish date.  Tasks that depend upon previous tasks, causing a project to finish at the latest time.

 

A project’s critical path is your longest route from start to finish.  In other words, your project cannot be finished any quicker than through this series of tasks.  Eliminate or shorten some tasks, and your project will be completed sooner.

It is valuable to analyze a project’s critical path.  Sometimes you can offload tasks to other resources, effectively shortening it.  In essence, you are turning a series circuit into a parallel circuit with multiple paths.  Any time you can do this, you are trading time for resources.  Yes, it will cost more, but you’ll finish sooner.

Consider a simple project with 1,000 hours of work, all performed by a single person.  The critical path is that single-path sequence of tasks.  Task 1, then 2, then 3, and so on…  You get the idea.

What if you added another person who could do the same work?  The project would then be completed in 500 hours, utilizing two paths.  But do you have a second person?

This is the crux of project management – juggling time, resources, and cost to maximize productivity.  Quite a game, huh?  🙂

–ray

Define: Project Phase

Project phase: A series of project tasks grouped together by time frame.

 

Project phases help you complete a portion of your project before moving on to other activities.  If your project is so big that it needs phases, good for you!  It probably means you have many resources assigned to it, and you need to break things up to manage them effectively.  This is not always so, but often the case.

Both Microsoft Project® and Standard Time® let you create phases or breakdowns.  They are called by many names: summaries, subprojects, subsystems, or just plain phases.  Anyway you look at it, they are project breakdowns that represent groups of tasks lumped into a time frame.  In other words, all the tasks are expected to be completed within a close proximity of time.

To create a summary task in Microsoft Project, simply click the task under it, and then click the Indent toolbar button.  That will cause the task above it to become bold, signifying that it summarizes the tasks below it.  As you add more tasks to the summary, certain fields (like start and finish dates) will roll up to the summary level.  You can collapse the summary to hide detail.  In Standard Time, these tasks are displayed on the timesheet.

–ray

Define: Constraint Type

Contraint type: A task scheduling option that determines how project tasks interact with each other with respect to dates.

 

Microsoft Project allows you to set constraint types for each task.  Using task constraints can really bugger up a project, if you don’t know what you are doing.  Ever hear of scheduling conflicts?  Consider using deadlines instead.  I feel constraints can be useful when used in moderation.  But most managers do not need to dive this deeply into task management.  Why?

Most projects change rapidly from day to day.  Because of this, you may find yourself fiddling with esoteric task options, only to find that they become irrelevant next week when the schedule changes.  That’s where deadlines can be simpler.

Here are the task constraints MS Project offers:

  1. As Late As Possible (default in a project scheduled from the finish date)
  2. As Soon As Possible (default in a project scheduled from the start date)
  3. Finish No Earlier Than
  4. Finish No Later Than
  5. Must Start On
  6. Must Finish On
  7. Start No Earlier Than
  8. Start No Later Than

 Clearly, these options control the behaviour of tasks that are linked together.  Let’s say you chose the “Start No Later Than” constraint type.  In this case, you would be required to supply a date that the task cannot start after.  Let’s say you chose August 1st.

A scheduling conflict can occur if a predicessor task causes your task to start after August 1st.  Schedules change so frequently that this is likely to happen.  Actually that can be a good thing.  Consider it an alert that something has gone wrong with your project.  If your project slips so badly that these contraints become activated, it can alert you to deeper problems witn your project team.

–ray

Define: Free Slack

Free Slack: The amount of time that can be spared in a task before it begins to affect other tasks.

 

Some tasks don’t really need to be completed by the time you’ve set for them.  In other words, there’s a little slack available before they need to be finished.  That’s Free Slack.

Microsoft Project calculates free slack in tasks when they are linked to other tasks.  If a task is not linked to another, the free slack is the amount of time from the finish date until the end of the project.  Here’s a quote from MSP:

The Free Slack field contains the amount of time that a task can be delayed without delaying any successor (successor: A task that cannot start or finish until another task starts or finishes.) tasks. If the task has no successors, free slack is the amount of time that a task can be delayed without delaying the entire project’s finish date.

So, how is this valuable to you?  This only applies when a successor task is not linked directly to its predicessor.  In other words, there is some slack time between them, even though they are technically linked.  This can be valuable to offer some spare time for the resource to finish the task, or to do other things.

–ray

Define: Six Sigma

Six Sigma: A project management methodology used to ensure quality and lowest possible costs.

 

The more I look into Six Sigma, the more I like it.  Like all project management methodologies, it does have some heavy-handed aspects.  But, the basic philosophy is sound.

Here’s a link and a quote from Microsoft’s web site (article by John Knutsen):

http://office.microsoft.com/en-us/project/HA011233361033.aspx

The “hidden office” (from Microsoft’s web site)
The difference between 99.99966% efficiency (Six Sigma) and 99% efficiency can be thought of as the “hidden office.” The hidden office represents all activity that results in defects (not meeting customer expectations) or not doing things right at the first attempt. Customers don’t pay for the hidden office.

For example, say a company bills 8 million customers on a monthly basis. If the process were performing at a 99% success rate, 80,000 customers would be incorrectly billed each month. The hidden office represents the costs and resources required to find and fix incorrect billings, and to address customer dissatisfaction.

The basic philosophy of Six Sigma is that poor quality costs your company money.  Doing things wrong the first time costs money.  The best way to lower costs is to reduce defects.  In other words, do things right the first time.  That’s the driving force behind Six Sigma.

–ray

Define: Project Stakeholder

What is a project stakeholder?  Any person who has something to lose if the project fails.

This normally includes higher-level people in the organization.  People who would personally fail if the project fails.  This can include customers, shareholders, executives, vice presidents, and even high-level managers.

A complete or partial project failure would cost these individuals something.  It may cost them money, time, or position.

Every project has stakeholders, even small ones.  It is important to identify these people.  Who stands to lose something if the project goes over budget, is late, or is never completed?  Those people will natually want to control the effort, and have the right to do so.  They hold the purse strings, and they go down with the project.

Does that mean a project stakeholder controls every aspect?  No.  They must trust those who execute it.  In other words, there will be engineers, technicians, and other creative people who actually do the work.  Much of the ground-level control is in their hands.  They report to the project stakeholders who direct their overall efforts.

–ray