Interview: Better than a Spreadsheet

A spreadsheet looks really inviting; free! If you have a small business with a few employees and don’t have to send any invoices, then it probably is OK. But multiple projects, many employees and different billing rates for them all is when you need a professional timesheet.

All true…

But here are some reasons spreadsheet are not the best tool for tracking client hours.

  1. You can easily make the mistake of entering hours into the wrong employee.
  2. Same with the wrong project
  3. Same with the wrong client
  4. You can’t sync with a neato time tracking app like Standard Time®.
  5. You can’t easily share the spreadsheet on the web without collisions.
  6. You don’t get any email notifications when things are wrong.
  7. You don’t get any real project status.

So… that free timesheet may be costing you more than you think.

Check this out.

Project manager is so screwed

Is it time for this project manager to take a plane to Mexico or Cuba? No, he can redeem the project with Standard Time®.  Enjoy the lighter side of project management!

Did you like the cartoon?  Let us know.  Here’s how.  Subscribe to the ScoutwestInc YouTube channel, and then click thumbs up.

All kidding aside, any project can be resurrected from the dead.  But some are not so easy.  Some organizations have so much politics and infighting that their projects are doomed from the start.  Resurrecting a project in one of these organizations sometimes means changing the way people think.  That’s sometimes not so easy.  Everyone is right in their own eyes.  They can’t see the trouble they’ve made for themselves.  And the project manager doesn’t always have a clear vision, or even the means to inspire others to follow it.  Implementing a nice project tracker like ST doesn’t always do it.  You need a true visionary to pull projects out of the ditch.

So sure… it’s easy to poke fun at failing projects.  But not always so easy to resurrect them.  But why not try?  Put a good timesheet product in place, and see what happens!

8 Dirty Secrets of Project Tracking

The video below may be useful for some.  Ray White of the Standard Time® Timesheet team outlines eight dirty secrets of project tracking.  These make a lot of sense.  Take a look!

 

What did you think?  Project tracking is a slippery game.  You’ve literally got thousands of enemies and obstacles that will bring your project down.  It takes a watchful individual to make sure those things don’t happen.  And a project manager who can do that is worth their money.

I was once on a project where the manager made us all sign a paper that said we’d finish the project by a certain date.  It was a big event where the paper was passed around for all to sign.  Honestly, most just laughed, signed, and mocked him later.  Here’s why: he never followed up with any real management.  He committed virtually every sin in this video.

Even though we signed the paper, he had no real end-game plan.  We just all worked on stuff we thought was cool.  The project blew through the ship date and died an ugly death from suffocation.  He didn’t track our hours.  He let the cool kids camp out on tasks they liked, which left the rotten tasks unfinished.

I never really know when the product would ship because it was always a moving target.  And like I said, the project died of suffocation months later.  Hummph.

Hey, I found the video transcription on this page.  Hope it helps!http://www.stdtime.com/videos/dirtysecretsofprojecttracking.htm

–newshirt

 

 

 

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.

Epic Fail: Why Projects Go Off the Rails

Are you beginning to think your project may be a total wreck?  Is it way over budget?  And does anybody but you care about that?  Does it bother anybody that there’s no end in sight?  And feature-creep never seems to end?  If so, that’s a sign that your project has gone off the rails, and is doomed for failure.

Chances are you’re not the only one who’s noticed.

A dark cloud of failure sometimes descends upon project from time to time.  I’m not sure if anybody really knows why.  It just happens.  I suppose you could call it a “perfect storm” of incompetence, wrong choices, and apathy.  When those circumstances form up into that dark cloud over your project, forget it!  You’re done!

Epic Fail

 

This begs the question of whether there should be an assigned person whose responsibility it is to watch for telltale signs of failure.  Such a person should first of all have been involved in a few epic failures so he knows the signs.  Peering into the hazy fog doesn’t do anybody any good.

Here are some signs to look for:

Missing half your milestones
If your project is consistently blowing past half the milestones (evaluation points), then you clearly haven’t identified all the work required.  And if that’s the case, your project may last 2 – 3 times longer than expected.  Is that okay?  Can the budget hold that much water?

Cynical Team Members
Are your project team members gossiping about management?  Has water cooler talk all gone negative?  If so, the team may have lost its moral.  Employees can’t always pinpoint the problems, but they sure can gripe.  If that’s happening a lot, then you project may be in trouble.

No End In Sight
Can team members see the light at the end of the tunnel?  Are you making progress, or just spinning your wheels.  You had better see some progress or you might be in a death march.

The Death March
This is when overtime rises to 60 – 80 hours per week.  You’re working weekends to meet a vague deadline that has no obvious payoff.  And you get the distinct impression that you’re still climbing the hill rather than sledding down the other side.  Project leads say you’re just about finished, but you get the sense that that isn’t true.  Why else would the work keep piling up?

Pulling Out
As we said earlier, the only way to pull out of the situation like this is for a whistleblower to call it.  Do you have one on your team?  If so, chop the product into quarters.  Deliver what little you have done now.  Take a big break.  And then take up the monumental challenge of boiling the ocean.  Maybe your project is just four times bigger than you first imagined.

A Helpful Timesheet Product: Standard Time®
Here’s a link to YouTube video that could help.  This is a timesheet project that may have a few answers, and may impose some order to your project.  It’s worth a look.

http://www.youtube.com/watch?v=SJRKTBye2j4

 

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.

False Front Prototypes

When you watch the old Westerns like ‘3-10 To Yuma’ you are usually treated to a Main Street with old-time businesses and homes on it. Horse drawn wagons lumber by. Victorian dress is on full display. A child taps an iron barrel ring down the dusty street with a stick. There’s the obligatory livery station, bank, gunsmith and hardware store, and cobbler. They all sport a nice tall false front, as the turn of the Century buildings often did. It’s exactly like “real life” in 1880.

But what you don’t see is the backs of those buildings. The Hollywood cameraman never goes back there. Guess what? There’s nothing back there! The buildings are literally just false fronts. You couldn’t actually live in one of those houses or do business in one of those stores. Sure, there are a few sets where you see characters going into and out of those businesses, but those movie sets may be in a completely different sound stage. Nothing is as it seems; it’s all staged for the camera.

Got your attention? Now consider how this happens in engineering…

In engineering, we build prototypes to help people see what a finished product will look like. What people? Customers, potential investors, buyers, company executives, project stakeholders. Everyone needs an idea what a product will look like when the engineering is complete. It gets everyone on the same page, and dispels misunderstandings. Sure, the prototypes have a few warts. It can have reduced functionality, but it must *look* like the finished product, and must allow the sales force to tell the story and make the sale.

The problem with these prototypes is that they have almost none of the proper engineering – much like a Western movie set. Sure, they look good, and may even appear to work. For the purposes of a First Look, they satisfy everyone curiosity and need to see something tangible, and they get everyone thinking in the same vein. But they may not have any of the correct functionality! That fact alone leads to a false sense of completion.

Project managers, engineers, project stakeholders, and everyone alike can be lulled into a false belief that these systems are just a step away from completion. In actuality, they are like false front Western movie sets. You could never consider actually using them for everyday purposes. But after looking at them for an extended period of time, you come to a false belief that you could. You forget how far they are from reality.

It’s that “one step to final product” illusion that gets everyone into trouble — especially the engineers. They are the ones tasked with readying the product for release. Everyone around them believes the product is almost there – almost finished. But it’s not. The stakeholders have big money riding on a swift move from prototype to production. Customer expectations have been set, and they are waiting – sometimes not so patiently. Problem is, there is no swift move. The prototype must be thrown away and the “real” engineering begins. It’s like throwing away the Hollywood false front hardware store and building a real one. You can’t just build onto the false cardboard buildings. They have none of the real factors that go into a real building. Real hardware stores are expensive! And they take a long time to build! They are nothing like the quickie cardboard movie sets.

Failure, ouch…

Failure is simply the opportunity to begin again, this time more intelligently.
    — Henry Ford

 

These are not from Henry:

Project failure is a luxury few can afford.  Multiple failures can bankrupt you.  See that they don’t…

It really is true that project failure is an opportunity to redesign and restart.  If you think about it… why do projects fail in the first place?  They fail because of some huge flaw that nobody recognized at the outset (or that the stakeholders ignored).

So starting over with those flaws corrected is what Henry is talking about.

There were 13 years of development leading up to the Model T.  (1896 – 1909)  There was another 18 years of development that lead up to the Model A.  (1909 – 1927)  That’s a lot of failure!

But think about it… it’s also a lot of success!

Task Lingering: Employees Avoid the Unfamiliar

Actually, not just employees… Everybody avoids the unfamiliar. But this post is about employees, and specifically project team members that engineer or develop new technologies. It’s about how employees sometimes try to settle into familiar tasks and avoid new and unfamiliar ones. And it’s about how to prevent that.

But wait… why prevent it? Isn’t efficiency gained by perfecting the familiar? By polishing your craft so you can perform it virtually without thought?

Yes, but this isn’t really about that. It’s about the propensity of employees to spend too much time on project tasks they have become familiar and comfortable with, to the exclusion of those upcoming tasks they dread the thought of.

I’ve heard reports of engineers racking up 200 – 500% extra time on tasks that could have been completed at the estimated time. Here’s the reason: people become comfortable with tasks they’ve spent significant time on and don’t want to leave them. The next task on their list may be unfamiliar and scary, so they stay on the one that doesn’t give off those vibes. The justification is that the current task could use some more polish.
Problem is, you’ve got to keep marching on. Your projects must be completed and delivered. You can’t afford to dally on project tasks you’ve already completed.

Here’s a technique you can use to discourage task lingerers. Set your timesheet “percent warning” to 75%. At that time, the task will begin reminding the employee that it’s time to move on. Of course, they may resist, but it’s a good reminder. Then set the “percent error” to go off at 125%. That stops team members from entering any more time. You can extend it with an administrator override, but at least you have some controls to monitor and manage task lingering.

Here’s a YouTube video that describes task lingering.

Hook a Timesheet to MS Project

PMO’s and project managers, have you ever considered hooking a timesheet to your MS Project MPP file? You spend a good deal of time pouring over your MS Project files, scheduling tasks, and assigning hours, but are you ignoring the ‘Actual Work’ field?

Do you have an automated way to input actual work?

Hooking a timesheet to the Actual Work field turns your static project schedule into a living, breathing document. You’re now releasing the beast into the wild, and you might be surprised at what it turns into! What, exactly, does that mean to release the schedule into the wild? It means letting employees enter their own actual work against their own tasks. It means hooking a timesheet to your project schedule. See this timesheet program for an example.

 

Getting actual working hours from employees might completely surprise you. Many project managers are uncertain how long tasks take. They have a good intellectual guess, or even some estimates from the actual engineers on the ground, but actual hours from employees can be a huge eye-opener. They are almost never what you expect. Project tasks often double or triple from their initial baseline estimate. No kidding! And when that begins to happen on a regular basis, panic sets in! You now have to either rein back your initial proposal or force employees to be more efficient.

See what I mean by setting the beast lose in the wild?

When engineers blow past your estimates, or even their own, they have no particular malice in mind. They are just doing their jobs. They may have no idea how those bloated task hours fit into a larger picture, or how they may affect a static project schedule. Again, they are just doing their jobs to the best of their abilities. And if that means a little extra work, then so be it. Problem is, stakeholders and project managers are freaking out as the schedule blows up. I once heard a manager say, “At this rate, we can only do a quarter of what we hoped.” That’s project management panic!

So back to hooking a timesheet to your MPP file… Sure, panic may set in for a while. You may need to rethink your plan. But you’ll be much more educated than if you had left the schedule in an “open loop” system without actual hours from employees. Ignorance is bliss!

A timesheet is the best thing ever invented for a project plan. They are so closely related, they should be in the same package! Fortunately, with this timesheet app, they are. In fact, you don’t even need MS Project. You can create your own project schedules with full hierarchy and project tasks, and then track time to them. You’ll instantly compare estimates with actuals, and avert most of the panic associated with a blown schedule.

Getting “Actual Work” feedback early is the best answer to project management panic!