Small to Midsize Business Going To The Cloud

The CIO Insight article below explains that SMB’s are going to the cloud for simple apps like email and storage.  And they are not necessarily asking IT for permission.  I suppose that is because the cloud provider supplies all the support they need, and users feel they can get by without their own internal IT department.  Probably so…

http://www.cioinsight.com/c/a/Messaging-and-Collaboration/Cloud-Computing-Plays-Big-Role-in-Small-MidSized-Businesses-539145/

Inexpensive cloud solutions are getting more and more attractive.  Not only do you get a great app, but you get external hosting and support.  So instead of spending your in-house resources on server hosting, patches, backup, upgrades, and babysitting, you can spend it on your core competencies.

Another up-and-coming cloud app is timesheets – check out a product named Standard Time®.  Their cloud-based timesheet is superb.  And just like the simpler apps described above, all the support is handled by the vendor.  But this is no simple app like storage or email.  This thing is loaded!  Check out some of the features you get for $13 a month!

Here are two videos on the Standard Time dynamic duo – Timesheet and Project Management

Cloud-based Timesheet

Cloud-based Timesheet

Cloud-based Project Management

Cloud-based Project Management

 

Timesheet
Of course you would expect this.  It’s a timesheet, after all!  But the timesheet is extremely flexible and comprehensive.  Employees only see projects assigned to them.  Project tasks are included.  Sub-projects and phases show a full hierarchical breakdown.  There is an expense sheet, and time off tracking.

Project Management
In addition to the timesheet, Standard Time gives you project rollups.  (Yes, this is all on the cloud!  Pinch yourself!!!)  They let you track actual work verses estimates.  Track percent complete.  Attach documents to tasks.

PTO Accruals
Need to track comp time for employees working over their scheduled hours?  Got it.  Need vacation tracking?  Got it.  How about automatic time off accruals on a daily, weekly, bi-weekly, monthly, or yearly basis.  That’s in there too!

Expense Tracking
What would a consulting tool be without cloud-based expense tracking?  It’s in there too.  In fact, you can run a client invoice that contains all the timesheet hours plus expenses.  Or, you can run a report that includes them both.  Or separately.  There are even custom reporting capabilities.

It’s a little hard to believe that cloud-based hosted services have evolved this far.  I guess somebody’s been hard at work.  Check out Standard Time if you’re a consulting firm, manufacturer, or government office.  Here’s a link to their YouTube channel.  New videos are posted all the time, so subscribing is a good itea.

http://www.youtube.com/user/scoutwestinc

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

 

Define: Preleveled Start

Preleveled Start: The starting dates of all tasks in a project plan before a resource leveling operation was performed.

If you use the resource leveling feature in Microsoft Project, you might consider adding the “Preleveled Start” and “Leveling Delay” columns.  These two columns help explain the effects of a leveling operation in MS Project.  The Preleveled Start field shows the dates that the tasks were before the level, and the Leveling Delay tells the amount of time each task was shifted to avoid over-allocation.

Consider the screenshots below.  They demonstrate the Preleveled Start field and Leveling Delay.

The first screenshot shows the fields before the resource leveling operation.  In this example, we have two tasks that occupy the same calendar date range.  Obviously the resource cannot complete both tasks at the same time.  We must move one, or split the tasks so they both can be completed.  But here you have a decision to make… can the resource multitask or must the second task follow only after the first has been completed?  Certain tasks like “Foundation” and “Framing” and “Roofing” cannot be multitasked.  They must be completed in sequence.  In this case, the normal leveling choices are best.

Preleveled Start before leveling
Preleveled Start is NA before leveling

 

 

In actual life, the resource will probably multitask both project tasks, which has the effect of pushing them both out.  The screenshot below shows the resource working 50% of his time on both tasks.  That doubles the amount of time the tasks take, but allows the resource the luxury to spend whatever time they want on the tasks.  This only works when the tasks are not mutually exclusive.  In other words, the second task can be performed at the same time as the first.  Or, they don’t have to be performed serially.

Resource at 50%Multitasking means working both tasks during the same calendar date range

 

But if you really want to use resource leveling, you’ll find that MS Project pushes one task out past the first one to that it starts when the first one ends.  Use this approach when you cannot work on the second task until the first is completed.  In other words, multitasking is not possible for these two tasks.  The screenshot below illustrates this.

Preleveled Start after leveling
Results of Leveling: Preleveled Start and Leveling Delay

 

Follow these steps to level resources:

  • 1. Choose Tools, Level Resources…
  • 2. Click Level Now

This dialog box is displayed to help choose the leveling options.

Resource Leveling Options 

Project Management Doesn’t Have to be Hardcore

When most people think of project management, they think of crusty PMI propeller-heads sitting in a back office analyzing complex columns of project metrics and arriving at lofty strategic conclusions.  (Did I pitch that nerdy enough?)  In other words, project management is out of most people’s realm of understanding.

But it doesn’t have to be that way.

Consider a simpler model, as demonstrated by the videos below.  The stuff I’m seeing here is simple – something any average manager can wrap their brains around.

 

How to Read a Gantt Chart:
http://www.youtube.com/watch?v=E-GZLfFPWvI

Project Management:
http://www.youtube.com/watch?v=E26M3Igh204

Resource Allocation:
http://www.youtube.com/watch?v=K-qfsuft6Ak

 

Really, this is pretty simple project management.  From what I see, you’ve got a simple hierarchy of tasks that employees can track time to.  For each task you set up an estimated duration that you think the task will take.  Then you release it to the wild for employees to enter time against.  When they do, it puts the actual work into the task so you can compare it with the estimates.  Pretty simple so far… no propeller beanies required.

Another video showed how you can give each task a starting date that tells when employees should work on the task.  Since you have a duration for each task, and you have a proposed starting date, you can then see how much work has piled up for any given employees.  After all, you are telling how long and when his work should occur.  The video shows a nice graph telling how much work is scheduled for each time period (week, month, or quarter).  It may have a fancy name (resource allocation) but it’s really pretty simple from my perspective.

Why not give these tools a try?  You don’t have to be a propeller-head to set up a few tasks and start tracking time to them.  You don’ t need a degree in project management or sit in a PMO office with all the bean counters.  To me, this looks like project management for the non-project managers.

You don’t have to be hardcore to manage a few tasks.  Give it a try!

Improve Task Estimates, Multiply by Pi

Trouble with poor task estimation?  Introducing the three-point estimating technique.  This might help.

Te = (To + 4Tm + Tp) / 6

Here’s the problem: engineers are never good at estimating task durations.  Not even close.  When asked how long their tasks will take, they usually just say, “They’ll be done when they’re done!”  As a project manager, you have to coerce an estimate out of them.  And then multiple by Pi for the real number.  But there may be a better way.  Read on for a possible solution.

Example:

                It’ll take about two and a half months.

                Multiple by Pi

                Result: eight months

First off, Engineers just don’t like estimating time.  They have technical issues to deal with, and are not practiced in the arts of time estimation.  They feel uncomfortable in fuzzy areas like this because they don’t spend any time thinking about such things.  The traffic in mathematical and logical conundrums, not project scheduling.  You might just as well ask them how much their tasks will cost, or how much the company will make from the product, once marketed.  It’s just not something they spend any time considering.  That means you have to take their task estimates with a grain of salt, or perhaps with a more scientific calculation.

What could be more scientific than multiplying them by Pi?  🙂

The three-point estimate technique below first appeared with PERT (Program Evaluation and Review Technique).  It has some merit when dealing with task durations, and might be more accurate than multiplying engineer estimates by some arbitrary number.

Start by taking this three-point estimate below from the engineer for each task.  You must get them to tell you the most likely duration for each task, which they will understate by a longshot… then you must try for an optimistic estimate, which they will assert is the same as the first estimate… then finally you have to get them to spit out a pessimistic duration, at which point they will argue is also the same as the first two, and that you are stupid for asking… now go away!  But if you can get these three numbers, you can plug them into the three-point estimate calculation below.

  • 1. Tm – Most Likely estimate (example: 6 months)
  • 2. To – Optimistic estimate (example: 4 months)
  • 3. Tp – Pessimistic estimate (example: 12 months)

With these three estimates, you can run a calculation to find the mean estimate.  (Find this calculation on page 150 of the PMBOK.)

                Te = (To + 4Tm + Tp) / 6

                Example: (4 + 4(6) + 12) / 6 = 8 months

The results are a good prediction of human estimations, assuming that most people under-judge the duration of most tasks.  They simply forget or don’t consider all the possible details in executing their assigned tasks.  This calculation makes up for that lack of detail.

Hope it works for you!

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.

How Buggy is your Product?

Want a really slick way to find out how buggy and nasty your product is? Buggy? Who wants to know that? We want good products, not buggy ones. Well, this method will help you get there. It’s a way to find out how many bugs there are still in your software when you release it.
Let’s face it, all products have bugs. Even fully released and supported ones. But managing the number of bugs at launch time is a good thing. Release too many, and you’re dead. Tech Support will hate you; your CFO will hate you, and worst of all, your customers will hate you. So clean things up, buster!

Here’s how you do it:

Let’s first start by supposing that you have a QA department testing your product prior to release. They test the documented and “undocumented” features of the product, record and report the bugs, then retest when engineers fix them. Hopefully, the product becomes more robust as the release date approaches. Less and less bugs are found. But we all know the product will ship with some known and unknown bugs. You just can find them all, and you can’t always fix the ones you find. But the process is good, and it’s working fine.

So, what if you intentionally slipped some known bugs into the product, hoping the QA department would find them? If you did, you’d know they were doing their jobs. After all, that’s what they are paid to do. So for instance, if you were receiving 1,000 bugs per week from the QA department, and you slipped 100 new bugs into it, you would hope to get 1,100 bugs the next week. You would know the Quality Assurance department was catching 100% of the bugs in the product.

But what if the QA department only found 70 of your artificially injected bugs? I.e. the ones you inserted just to test the percentage of bug found. If only 70 of the inserted bugs came out, that would tell you that their efficiency rate is about 70%. Given that they find 1,000 bugs per month, you might suspect there are actually 1,428 in the system. Why? Because they only found 70% of your artificial bugs, so what makes you think they are finding 100% of the others? Probably not, but that’s okay; nobody’s perfect. If they are 70% efficient, then 1,428 x 70% = 1,000.

Using this method, as your bug rate approaches zero, you’ll know about how many uncaught bugs remain.

Closer to the Source

The sooner employees record actual hours worked, the more accurate they will be.  Some companies require team members to record their project hours.  Sometimes this is for client billing, other times for engineering or manufacturing projects.  Whatever the reason, I’ve seen firsthand that recoding hours soon after the actual event ensures accuracy.

Most people cannot remember what they did last week.  So if asked to fill in their timesheet for last week, they will not be able to pick out individual tasks.  Sure, they remember which projects they worked on, unless there are more than two.  But they cannot reliably remember which tasks.  It gets impossible when asked to assign actual hours to those tasks.  That is the primary reason DCAA (Defense Contract Audit Agency) requires timekeeping every day.  Even filling out timesheets at the end of the week is against the rules.  I don’t normally like government agencies, but in this case there is truth to their overbearing policies.

Standard Time® is an example of a professional timesheet with a built-in timer.  The image below illustrates the Quick Task window.  A link to a video is also included.

Prototype

Standard Time® Quick Tasks

In the Standard Time Quick Task window, you simple click project tasks to start and stop the timer.  Time log records are automatically entered into the timesheet.  That solves the problem of entering hours after the work is finished.  Actual work is sent directly to the timesheet; there is no delay.  And since you are clicking the checkbox to start and stop a timer, the actual work is as accurate as it could possibly be.

Most companies do not require minute-by-minute accuracy, unless you are charging them for time worked.  Only consulting companies really need this level of granularity.  For them, it’s much easier to justify invoices when the time accounting accuracy is beyond impeachment.  Simply print out the actual time log report (with records down to the second) and there is no disputing the accuracy.  Of course you can still milk the clock, but consultants are rarely accused of that.  But still most manufacturing companies that track projects for earned value purposes don’t need timer accuracy.

Whether your company needs timer accuracy, daily accuracy, weekly, or monthly, tracking time is almost always a good thing.  There is so much value in knowing how much time projects take.  Consider a few good reasons: comparing estimates to actuals, estimating future projects, assigning cost and estimates to new activities, or even know what employees are up to – all good things!

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.

Earned Value: 50% Fiction and 50% Fact

In project management, there is a term named “Earned Value.”  It prevents the value your project has actually earned based on its current state of completion.  The graphics below help describe this.

A close relative to Earned Value is Planned Value.  It is the monetary value the project should have generated at any point in its state of completion.  Ideally, Earned Value and Planned Value should be identical.

And another close relative is Actual Cost.  It is the cost the project has incurred at its current state of completion.  When Earned Value and Planned Value and Actual Cost are all equal, the planets have aligned!  But when they are not, we have discrepancies which we’ll explore below.  That may help explain the post title: “Earned Value: 50% Fiction and 50% Fact”.

The 50% fiction is Planned Value.  The 50% fact is Actual Cost.  Earned Value is somewhere in the middle.

Prototype

 

Here is an example of a discrepancy between Earned Value, Planned Value, and Actual Cost.  The Earned Value is much less than we expected, and the Actual Cost is much more.

Prototype

 

In this example, we see Earned Value at $30,000, but it should be $40,000.  We also see the actual costs on the project to be $45,000.  It turns out there are calculations to help normalize and judge the value of these numbers.  This let you compare the numbers with other projects to see how close you have come to historical numbers.  If you miss the Planned Value mark, the difference is called a variance.  Variance simply means you varied from your target by some amount.  There is a schedule variance and cost variance.  Of course ideally, we want these to be zero.

Schedule Variance (SV) is Earned Value minus Planed Value.  Cost Variance is Earned Value minus Actual Cost.  The equation is below.

SV = EV – PV  ($30,000 – $40,000 = -$10,000)

CV = EV – AC  ($30,000 – $45,000 = -$15,000)

In addition to variance, you can view the discrepancies in terms of ratios.  They are actually more helpful to compare with other projects because they normalize all the numbers to a single comparable performance value.

The Cost Performance Index is the ratio of Earned Value to Actual Cost.  The Schedule Performance Index is the ratio of Earned Value to Planned Value.

CPI = EV / AC  ($30,000 / $45,000 = .67)

SPI = EV / PV  ($30,000 / $40,000 = .75)

Any Cost Performance Index number over 1 is over budget.  Any Schedule Performance Index over 1 is “over schedule.”  See how these performance numbers could be helpful?

In this case, the Cost Performance Index is 67% efficient.  In other words, the project made 67 cents for every dollar expected.  That’s not good.  But maybe the next project will be better!