Define: Project Baseline

Project Baseline: A copy of the project tasks as they were at some point in time, which you can refer to at a later date.

Here is an example of two project tasks immediately after setting the project baseline.  Notice that the ‘Baseline 1 Work’ field has been copied from the ‘Work’ field.  As the ‘Work’ field changes throughout the project, the baseline is still available for comparison.  How did we do this?  Easy.  Just choose Tools, Tracking, Set Baseline within Microsoft Project.

Here we see the ‘Work’ field changed and the ‘Baseline’ unchanged.

 

Want an easier solution?
Baselining can be complicated and confusing, so “Sir Ganttalot” (a YouTube celebrity) has come up with an easy alternative.  Click here to see the YouTube video:

 

 

 

http://www.youtube.com/watch?v=c7BJ6%5F1pcgc

Essentially, Ganttalot creates a customized field named “Finish Date Changed” to identify tasks that have changed.  Graphical arrow indicators tell whether a finish date has slipped in the future or has tightened up.  These graphical indicators are easier to spot than comparing textual finish dates to baseline finish dates.  It shows you at-a-glance what’s changed from week to week.  Slick, I’d say!

Give Up Chocolate to Telecommute?

In the recent CIO Insight poll (see link below), 29% of the respondents say they’d give up chocolate to telecommute.  Yeah, right!  For how long?  17% said they’d give up a salary increase for telecommuting.  And 5% would even ditch the spouse.  Okay… that’s going a little too far.  But evidently, that’s what they said.  Check out the story here.

http://www.cioinsight.com/c/a/IT-Management/What-Your-Employees-Would-Give-Up-to-Telecommute-503693/

Evidently, people will do almost anything to work at home.

I can tell you from first-hand experience that the productivity boosts are enormous.  Focus comes so easily.  But only if you are self-motivated person with autonomous tasks.  Project team members with frequent ties to other employees can’t pull this off well.

There is also no substitute for face-to-face interaction.  Ten times the information passed between people when they look each other in the eye.  Information fidelity drops as you employ lessor communication tools like telephone, email, and finally the worst, text.  Even Morse code is faster than text, as Jay Leno demonstrated, but not by much.

But the upshot is, employees will give up almost anything to telecommute.  Just remember that, project managers!

Project Portfolio Management 2

I’ll take the liberty to build on Warren’s Project Portfolio Management post below.  Hope he doesn’t mind!  It’s a great post, but the images below could help solidify the usefulness of project portfolios.  See the Project Portfolio YouTube video here.

There is a wonderful Timesheet software product named Standard Time® that handles project portfolios nicely.  The screenshots below are from it. Standard Time lets you see forecasted revenue for a selected project portfolio.  It also lets you see future task allocations and employee availability for a selected portfolio.  That’s powerful!

 

 

Here you see a project portfolio chosen from the dropdown list at the top-left.  The chart at the bottom forecasts the future revenue from all the projects in that portfolio.  This lets you compare one portfolio to another and focus on the profitable ones, and ditch the rest.

 

 

This screenshot shows project resource allocation for a selected project portfolio.  In other words, you see when your employees are scheduled to work on the projects in that portfolio.  The program takes all the projects in that portfolio, and then checks to see when employees are working on them.  If you decide to postpone a portfolio, you’ll see where you can pick up some extra resources.

 

–newshirt

Project Portfolio Management

Project portfolios are helpful for grouping work and managing projects individually and as a whole. Many companies start out not utilizing project portfolios. Then, as the company grows projects become unmanageable and the need for project portfolio management becomes clearer. Portfolio management helps companies maintain efficiency and breaks project work load into manageable pieces. It is vital that whatever project management software you utilize, be sure it is scalable to include project portfolios. It is likely you will need it! There is way too much to cover in this short blog. However, a pretty good white paper can be found from Mosaic Project Services at the link below.

http://www.mosaicprojects.com.au/WhitePapers/wp1017_portfolios.pdf

Define: Task Status

Task Status: In Microsoft Project, the task status field represents the current state of each task.

The illustration below shows all the possible task states: Future Task, Late, On Schedule, and Complete.

 

 

How do tasks get into these states?
    1. Future Task:  When the task ‘Start’ date is in the future.
    2. Late: When the completed hours are less than what they should be by today.
    3. On Schedule: When the completed hours are >= to what they should be today.
    4. Complete: When the percent complete is 100%.

Planning for Pathological Issues

One of the more recognized terms in any business is Paralysis by Analysis…or Analysis Paralysis. You know, when nothing moves forward because too many people have to buy off on an idea, or a single person is the team lead and afraid to jump in with both feet. Well, I believe one way to identify Analysis Paralysis is to look for the most common symptom…pathological cases/scenarios. This is easy to spot. When “what ifs”, that are highly unlikely continue to pop up, then you can get stuck in the “what if” cycle, causing Paralysis by Analysis. These pathological cases have a sliver of possibility but cause an overwhelming fear for the project team. Then you’re off trying to plan or prevent the impossible. I have seen this happen many times and more often than you may think. Project leaders and team members can easily become myopic when focusing on their work. In my experience the best way to tackle pathological cases is head on. Politics is one thing, but a never ending project is another.

The Collaborative Process in Project Management

I understand the latest fad in management styles is the collaborative process. Part of the collaborative process is encouraging multiple people to arrive at a decision as a unit, or on behalf of the unit – where, in times past, there was a “buck stops here” person. Now there is a buck stops here, over there and just about anywhere group of people. While the collaborative process has a place and is effective in many scenarios, it is dangerous when it bleeds over into a non-collaborative project structure. I’m not saying project teams shouldn’t work together to collaborate and solve issues. In fact, just the opposite! Project teams are a TEAM by definition, working together towards a common goal. However, with a younger generation being taught the collaborative process so heavily, it can cause issues when they veer out of their lane and bypass a structural hierarchy or chain of command. The collaborative process is great until a person makes a decision without actually collaborating with the person/persons responsible for that particular area of concern. By the time the “true decision maker” finds out, the decision has been made, announced and partially implemented. Now we have a real mess. Collaborate on that!

Methods of Resource Allocation

I’ve recently been made aware of another method of resource allocation.  I’ll throw it out here to see what project managers think.  It’s a simpler method than the traditional task-based resource allocation.

Before getting into that, I’ll briefly describe the resource allocation method I am most familiar with.  In this method, resources are assigned to project tasks that have clearly defined durations and remaining hours. 

The tasks may also have starting and finish dates.  The resource allocation algorithm spreads the remaining task hours over the date range defined by the task.  If you have too many tasks, you are over-allocated.  Too few, and you are under-allocated.

The simpler method I became aware of doesn’t use tasks.  It also doesn’t use start and finish dates.  Projects are assumed to continue forever, and resources are assigned a percentage of their daily scheduled hours.  That’s it, nothing else.

In the simpler method, resources are over-allocated when they are assigned to so many projects that their daily hours are exhausted.  They are under-allocated when there are still a few hours left in their day.

Define: Timephased

Timephased: Total project task hours distributed over a period of time.

An example from Microsoft Project of this is shown below.  The hours for each project task are distributed over the duration of each task.  The hours per day is the ‘Work’ field divided by ‘Duration’ field.  In other words, the total work is spread evenly over the duration.  Choose the Microsoft Project views below to see these task layouts.

 

Tracking Gantt View:
 

 

Task Usage View:
 

You can see that the 100 hours are timephased over 10 days for the first task, and over 1 day on the second task.

Great Product Features Have Solid Business Case

For our company, great features rarely come from high-octane project brainstorming sessions where the heavens open to reveal the glory of God.  Instead, they come from lowly customers here on earth.

Here’s how it happens:

A customer calls up and says, “Why is your product so lame?  Why doesn’t it do such-and-such?”

“That’s none of your business!” cries an eavesdropping passerby.

Oops, no.  Not the correct response.  Instead I ask, “How would you like it to work?”

Nine times out of ten that question turns into a great new feature.  We discuss the business case and work out an alteration that fits the common usage much better.  Customer is happy; we’re happy.  Now we just need to sell it to the executive management and development team.
Why is this exchange so valuable?  Because it comes from an actual customer with little vested interest in the product.  They just want it to work better so they can get their work done faster.

BINGO!!!

That’s the key.  Anytime you can reduce admin time or improve product usage, everyone wins.  Nobody likes a hard product.  Dreaming up great new features in a boardroom rarely accomplishes those basic goals.  Talking to customers is where it comes from.

Problem is, who’s talking to customers?  Tech support, sales, and maybe a marketing hopeful willing to mingle with the great unwashed.  These are the lowlife employees nobody listens to.  So how does the customer need get filtered up the channel to executives and then back down to the development team?

Give them a database.  Let them submit feedback from the trenches.  If they can articulate the business need clearly and effectively, people will listen.  The best features always come from customers.