Posted on

Project Billing Rates For Client Invoicing

This video will show you how Standard Time uses rates for client invoicing. Different rates for different employees. Once Standard Time is set up you won’t need to fuss with it.   Just set each project rate for each employee and you’re done.

You have several models to choose from:

  1. User rates (Default.  Each user has their own rates for each project)
  2. Role rates (each role a person plays on a project has it’s own rates)
  3. Category rates (each kind of work has it’s own rate)
  4. Project rates (each project has it’s rate, regardless of user or kind of work.  Least flexible)
  5. Option Year rates (for government contracting)

Check stdtime.com for more details.

Posted on

Employee Availability Graph

Here’s a graph of employee availability in Standard Time®.  It shows when employees are available for work.  This is a lot like a resource allocation graph, but inverted.  The bars show when employees are available, unlike a resource allocation chart where the bars show hours the employee has work assigned.

You’ll need this if you are a consulting, engineering, or manufacturing organization.  It’s important to see when employees have projects assigned.  Standard Time provides that.

 

 

Posted on

Timesheet Tasks

This video shows how the Standard Time timesheet displays project tasks.  Each timesheet is different for each employee.  That makes things pretty handy!

 

 

 

 

 

Posted on

Standard Time Android and iOS apps

Here’s a new video showing the Standard Time Android and iOS apps.

https://www.youtube.com/watch?v=pIbkf4SEXzc

All your time and expenses sync with the cloud or desktop.  So you can track project hours on the mobile device and it will find it’s way up to the big database in the sky.    Project managers like that because they get more accurate project time.  Remember, the more frequently employees enter hours, the accurate the project is.

Project schedules depend on accurate actuals.  So if you can get them to update their timesheets on a regular basis, then you’re farther ahead.  That’s what this app does.  It encourages employee input when the actual work is performed.

 

 

 

 

Posted on

What is a project milestone?

Good question!  What is a project milestone?

Think of a project milestone as a marker in time where you stop and evaluate your project.

How is your project going?  Have you completed everything necessary to move on to the next level?  Have you finished everything in this milestone?  And are you ready to move forward to the next one?

The video below shows what milestones look like in a Gantt chart, and how to track time to them.  But normally you don’t actually track time to milestones.  They are just markers in time, not actual tasks.  But you can if you want to.  In fact, you could set up a project with nothing but milestones!  Just track hours to them and compare against your original estimates.  That’s a simple way to track projects.

In the old days, a milestones was a physical stone erected by the road.  There would be one stone every mile.  Just count the stones as you waked along, and you would know how far you had traveled, and how far the next town was.  They were just like our interstate mile markers now.

Project milestones are very similar.  They tell you how far into the project you have traveled.  Got a big project?  Put up a milestone every so often and you’ll know where you are.

Posted on

Feature Delays Mean Reallocating Resources

Has a customer of yours ever forgotten to get back with you about a feature you were developing for them?  They were hot to finish, but then weeks went by and no word.  Maybe the feature was almost finished, and you just needed a little more information to complete it.  One phone call or email and it would be finished.

But guess what happens when these delays occur?

All the feature nuances you kept in your head are now slipping…  A week goes by… Two weeks…  A month…  By now you’ve forgotten some of the little details that made finishing the feature so simple.  You’ll have to relearn some of those and get the feature back on track.  What would have taken a short time to complete will now take four times as longs.

When this happens, you are essentially reallocating resources to complete the job.  In some cases when too much time has elapsed, you might just as well restart the project and reschedule hours to come up to speed.  All that admin scheduling take time too.

Moral of the story: Don’t let these little delays creep in in first place.  Stay on top of your dependent resources so they don’t leave you with a long forgetful delay.

Posted on

10 Best Teams – My Comments

Below is a short commentary on a fun article I recently read.  (See link below.)  The Online Business Degree put together a list of the best teams ever assembled.  I read through the list and agreed with most.  Some sounded a little contrived, but workable.  Here are my reactions.

http://www.onlinebusinessdegree.org/2012/08/29/the-10-best-teams-ever-assembled-and-what-we-can-learn-from-them/

I’ll take each team in order:

1. The Dream Team:
Yes, they were the finest basketball team ever assembled, but they were also professionals.  I thought the Olympics was supposed to be amateur.  I vaguely remembered a guy named Jim Thorpe losing his metals because he was accused of accepting gifts.  I’m behind the curve on this; maybe The Olympics has turned pro, and I missed it.  But the Dream Team always seemed odd to me.

2. Sherlock Holmes and Dr. Watson:
Sir Arthur Conan Doyle created Sherlock Holmes and Dr. Watson as fictional characters.  They weren’t real.  But they sure had some fun adventures, and the recent Hollywood film is pretty good.  Doyle presented them as pretty good team, I must admit.  Still… it’s hard to get behind them as a real team.

3. Rogers and Hammerstein:
Now here’s a great team!  Nothing fake about them.  This was some of the greatest music of the Twentieth Century.

4. SEAL Team Six:
Worthy of our worship (figuratively speaking).  Have you seen how SEAL teams are trained and formed?  Watch the documentary some time…  It’s amazing!!!

5. The Beatles:
Yep, I’d go with them too!  Millions of people around the world still listen to their music.  But “more famous than Jesus”?  I don’t think so.

6. 1985 Chicago Bears:
Don’t know much about sports, so I can’t comment much.  But hey… if they won a Super Bowl they had to be pretty good.

7. The Justice League:
Another fictional team.  Humm…  I’m not convinced fictional teams work for me.  It’s easy to write fiction because the characters don’t actually have to accomplish anything.  You can just write up a bunch of cool scenes and you’re done.  Can I learn anything from fiction?  Yes.  But generally, non-fiction is the most inspiring to me.

8. The Apollo 11 team:
Now here’s a real super hero team!  These guys went to the moon with less computing power then an iPod.  Pretty amazing when you think about it!

9. The Not Ready for Primetime Players:
Wonderful team of comedians!  I’ve always enjoyed them.

10. The Manhattan Project:
Yes!  Another great team of scientists that I can get behind.  Most people don’t know how great these guys actually were, and how they literally saved the world.  But sadly… most people don’t know history.

If I had created the list, I would have dropped the fictional teams.  Sure, they sound great, but it’s debatable how much they actually inspire.  For instance, Sherlock Holmes was a pretty smart character, but most people find it difficult to pattern their lives after a character in a novel.  It’s like trying to be more like Huck Finn or Indiana Jones.  It’s entertaining, but not inspiring.

Lastly, I would have liked to see “The 12 Disciples” listed as a team.  Jesus didn’t pick them for their skills and awesome speaking abilities, but in the end they changed the world.  That kind of power can’t be ignored, and they are men you can comfortably pattern your life after.

Overall… it was a fun article.  It was well thought out, and fun to read.

Posted on

Engineering for Longevity

While camping this past weekend, I noticed a bunch of new broken stuff on our 1990’s pop-up camper.  It’s seems everything is broken nowadays, but a new travel trailer is not in the budget, so we’ll make due.  But still lots of stuff is broken.

And that got me thinking about engineering…

I told my wife that engineering schools could benefit from a class on “engineering for longevity.”  Students could bring in broken consumer items and analyze them for possible improvements.  In other words, figure how they might have lasted longer with a little engineering foresight.

Engineering for Longevity

Students could identify stress points in plastic parts.  They could find wear surfaces on moving parts.  They could analyze fabric tears.  Just picking up a broken twenty year old part instantly makes you think differently.  It’s a very impressionable moment.  It makes you wonder what could have been done to make a more reliable part.  Perhaps nothing can be done, but at least you are thinking in those terms.

I remarked to my wife that a lot of consumer items are nothing but cheap crap.  They have obvious design flaws, bugs, and limitations.  You can tell the manufacturer hired an engineering intern to develop the items.  Things don’t fit right, or could easily be optimized.  There’s just very little “fit and finish” any more.  And since engineering interns are young and don’t realize that stuff breaks, they produce shoddy products.  It takes somebody with experience to know where the obvious break points are.

My wife pointed out that there’s no money in consumer items to hire experienced people.  The engineering apprentice is all the company could afford, so this is what you get.  But that goes back to my original point, which is… if engineering schools had a class that familiarized students with the issue of engineering for longevity, some of them might produce better products.  Not all students would get it, but some.  And that’s worth having a class for.

�

Posted on

Define: Resource Breakdown Structure (RBS)

Resource Breakdown Structure (RBS): A hierarchical listing of resources necessary to complete a project.

Project resources are commonly thought of human resources only.  In other words, only the people that will actually work on the project tasks.  But that is not necessarily the only type of resource list that can be compiled.  In fact, the RBS can include both human resources and physical resources, like computers, software programs, timesheets, tools, instruments, automobiles, or even special clothing.

As seen below, the hierarchy is entirely project defined.  Any leveling applicable to the project can be used.  Examples might be organizational chart, or tool type, or physical location, or even sequencing by use.  Any useful project breakdown is appropriate.

Traditionally, only non-expendable resources are included.  Expendable items such as water and gasoline would not be listed.  These would fall into the category of supplies rather than resources.

Example of hierarchies of resources:

1. Engineering
  1.1 Rob
                2.2 Ted
                1.3 Software
                                1.3.1 Bill
                                1.3.2 Joe
                                1.3.3 Standard Time® Timesheet (timesheet and project tracking software)
                                1.3.4 Microsoft Project (project scheduling)
                                1.3.5 SQL Server (database)
                1.4 Hardware
                                1.4.1 Alice
                                1.4.2 Jill
                                1.4.3 Test Stand A
                                                1.4.3.1 Computer
                                                1.4.3.2 Wiring harness
                                1.4.4 Test Stand B
                                                1.4.4.1 Computer
                                                1.4.4.2 Wiring harness
 

The example above includes both human and inanimate physical resources, like software and test instruments.

Notice the numbering nomenclature.  The hierarchical list is numbered, with each indented layer adding another level to the numerical label.  Examples: 1.3, 1.3.1.  This makes each resource uniquely identifiable by numerical label.

Posted on

When to Re-baseline Your Project

Baselining is the act of recording your original project estimates so you can compare them to actual results at a later time.  It is also the platform from which the project is conducted.  In other words, the baseline contains schedule and cost numbers used by the project team throughout the entire process.  By baselining the project, you are laying the foundation on which the project will rise.  That’s a nice thing to have.  Employees want a good solid plan that doesn’t wander from whim to social whim.  They want a visible goal that isn’t ducking and weaving out of sight every week.  Such a goal offers reassurance and confidence for success.  A moving target is the worst motivation killer known to man.

But sometimes you just need to start over.

Yes, a moving target is a sure killer.  But there are times when the baseline is just crap.  The schedule has become irrelevant, costs are laughable, and the project team is floundering in a sea of mud.  Nothing is going as planned.  Designers are throwing in new requirements that were heretofore unheard of.  Executives are MIA.  And managers have you working 80 hour weeks to hit a target they have no clue of the purpose of.  Nobody’s admitting they’re stupid, but it’s obvious everybody is.  It’s only years later that everyone can look back and shake their heads at the calamity.  But while you’re in the midst of it, you just keep buggering on.

It is those times that executives, or maybe a strong-willed project manager needs to step in and call a hiatus.  But who’s got the guts for that.  Again, you’ve got to be a strong person to blow the whistle and wave your arms.  But if you can recognize the signals, a re-baselining during a mess like this may be your only option.

I was on a two-year software death-march like this.  It was a disaster.  Nobody knew the warning signs.  Nobody blew the whistle.  Nobody re-baselined.  The product failed six months after release, which was at that time a year overdue and marketplace irrelevant.  It was the worst project I was ever on.

Here is a good rule of thumb for knowing when to rebaseline:

Baseline the project if you have missed over half your scheduled targets in the last six months.

Have you missed a few end-to-end tests?  Missed a customer drop or two?  How about a major milestone?  Missed a target feature?  These are the warning signs.  Again, if you have missed over half your targets in the last six months, rebaseline.  Don’t try to figure it out, just baseline the project again.

In fact, in cases like that above I would suggest cutting the scope in half.  Cut the project into smaller phases.  Get the schedule down to visible goals.  And if anybody disputes them, cut them again.  And then again.  You must have realistic goals or you will fail every time.

�