Project Team Blog – Page 48 – A project management blog for manufacturing and engineering

August 21, 2012August 21, 2012

There are no big problems; there are just a lot of little problems.

There are no big problems; there are just a lot of little problems.

— Henry Ford

Henry Ford was the genius of the 20^th Century assembly line. He almost singlehandedly designed the Model T and Model A Fords. Those two cars were the workhorses of the early 1900’s. So when Henry speaks of “little problems” he’s talking about inventing the entire automobile industry. But that’s big enough for anyone.

His point, though, is that in engineering you have dozens of little issues to deal with. And they stay with you indefinitely. In other words, engineering is a constant fight with little problems that you must work out with patience and perseverance. If you don’t have the aptitude, don’t get into engineering!

1. One of the biggest problems engineering people have is balancing quality with cost. Any engineer can tackle the myriad of little problems before them. But can they do it cost effectively? In other words, does it take forever to solve them, thus costing a fortune? Or can they resolve each one rapidly and without expensive solutions. The balance between polishing your work in a craftsmanship style, and pumping product after product out the door is a big, big problem that requires a lot of thought.

2. The next biggest problem engineers face is collateral damage from engineering fixes. I.e. bugs. Here’s an example: Say you are an electrical engineer designing a printed circuit board. And in your haste to produce a cost effective product, you forget a circuit trace. The manufacturing department is now forced to hand-wire that trace. It now costs your company much more in the long run. That’s a bug that must be retooled. Things like that happen in every engineering discipline. It’s definitely the next biggest problem you must face.

3. The final big problem engineers face is time estimates and project schedules. Engineers do not think like other human beings. They cannot estimate time with any degree of accuracy. And they do not like being interrogated about how long their work will take. You’ll just have to wait until it’s done, they’ll say. I’m working as fast as I can. Problem is, big money is riding on their engineering work. Sometimes the company just can’t wait. It the engineer that has to hurry up and product the product on the company’s timeline. And that can lead to big battles. So this is a fairly big problem facing engineering departments and company executives.

And then after those three, there are just a lot of little problems. 🙂

August 16, 2012

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 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

August 14, 2012

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

August 2, 2012

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

July 31, 2012April 7, 2013

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.

�

July 23, 2012August 24, 2012

All Your Eggs in One Basket

Concentrate your energies, your thoughts and your capital. The wise man puts all his eggs in one basket and watches the basket.

— Andrew Carnegie

I love that quote! It speaks of focus and single-mindedness. Those are qualities the project team can do well to learn.

There is a “magic” that occurs when the project team is single-minded with a burning goal on all their minds. I’ll try to articulate the experience, as I have had been in the middle of it several times. The closest parallel I can relate to is the focus of war. Many speak of the chaos of war, but there is also a singular focus that it brings upon the average soldier. And that focus is intoxicating. Think of the Confederate army under General Robert E. Lee in 1861. Those gray-clad boys fought for a cause! It was the cause of freedom from government tyranny. With such a cause, they would endure some of the most grueling warfare known to man – starvation, slaughter, and privations as yet unknown to Americans. It was all for the “cause.”

The same was true of GI’s during the Second World War. Those soldiers knew the cause was the defeat of Hitler and the unconditional surrender of Germany. Everyone focused on the same goal, whether on the battlefield or at home. It was one singular goal everyone could focus on.

This happens in the engineering world from time to time. Underdog companies focus on one goal of building that killer product that will change the industry. For the most part everyone speaks the same “language.” It is the language of winning… of succeeding regardless of the hurdles… of performing their very best, if only once in their lifetimes.

People want causes. It gives them one good thing to fight for that’s worthwhile and lasting. Think about it… without something truly worthwhile we are just marking time through life. Nobody wants that. They want their lives to mean something.

All this is wrapped up in Andrew Carnegie’s statement above. He is describing an industry focus that consumes everyone in its path. In Carnegie’s case, that was the manufacturing of steel, and the goal of commodity pricing that could supply the world.

Can you find a cause like that for your business? If so, you will have all the energies of all your employees focused on success. And they will thank you for a cause to believe in.

July 18, 2012September 5, 2012

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!

�

July 10, 2012December 17, 2012

Why Use a Timesheet?

If you’re a consulting or contracting company, the answer to that question is a no-brainer. Or so says the video below. In this video, the author asserts that consulting companies absolutely must use a timesheet for the job. I tend to agree. Consulting has become so complex, and the margins so slim that you can’t afford to lose a single hour of billable time.

Consultants regularly check their utilization rates to make sure they are making money. Utilization is the ration of billable to scheduled hours for the employee. For example, if the employee is scheduled for 40 hours and only works 35, then he is only 88% utilized. And because he hasn’t worked the full 40, he is not billing as many hours as possible. Therefore, his effective billing rate is lower than what the company actually charges for his work.

Here’s an example of a poor effective billing rate. Suppose a consultant bills at $100 per hour. But he only gets 10 hours per week of billable work. His effective billing rate is now only $25 per scheduled hour. And if you miss any of those hours, the rate goes down. So using a timesheet to collect and account for all the billable time is probably a no-brainer.

Manufacturing companies like to track project hours using a timesheet. It allows them to connect with their employees and see where their time is going. But it has more value than that. Manufacturers who track projects want to improve their deliverable schedules, milestone predictions, and task duration estimates. This obviously lends credibility to their project management efforts. The only way to get good project task estimates is to use a timesheet. They must collect actual employee hours so those hours can be compared with the original estimates.

And finally, even if you are not a services-based company that tracks time for client billing, and you are not a manufacturing company that tracks project management metrics, you may still just want to see employee status and weekly hours. That’s a good enough reason to use a timesheet. Simply keeping an eye on employee activities is a worthwhile management practice, even if you don’t have a hard reason to use a timesheet.

All these reasons are illustrated in a nice little YouTube video. Check out the ScoutwestInc channel for additional timesheet videos. Some of them make a lot of sense.

July 5, 2012November 6, 2012

Disconnect between Execs and Employees

In a recent CIO Insight survey (see link below), it was observed that executives and employees do not necessarily believe the same things. They differ on values, communication, and culture. Read the article below and let me know what you think.

http://www.cioinsight.com/c/a/IT-Management/Execs-and-Employees-Differ-on-Company-Values-855767/

In my opinion, this isn’t anything new. Company executives have always had a difficult time relating to the common employee. That’s one reason for the rise of labor unions in blue collar workplaces. Employees simply do not believe management shares their values or even cares about them.

Actually, as a student of the American Civil War, I’ve read plenty of examples of the wide gap between officers and men in the ranks. So we know this phenomenon has been going on for a long time. One story was told of a Confederate private playing cards with his Federal friends until a colonel came along and threatened to take him prisoner. Clearly, the rank and file held different beliefs about the war in progress.

I believe this belief gap stems from your role in the company. Executives experience the company in completely different ways than employees. Their beliefs are shaped by completely different experiences and input. Of course, the common employees thinks he knows it all, and is usually pretty vocal about his beliefs, but they don’t always have all the information. Sometimes company issues are just too hard to analyze from an employee perspective. Executives may also hold similar ivory tower beliefs about their company. After all, they sit at the top looking down on it all. Surely they can see clearly from a strategic vantage point.

The fact is, employees and executives should swap places every so often, just to experience a different perspective. A company I worked for tried this on a limited basis. Software engineers were required to spend one day per quarter with tech support. Support engineers were required to spend a day with the programmers. This forced those employees to see things from a different perspective.

Rifts are created when employees feel management is not listening to them, or is making bad strategic decisions. The same is true when executives think employees are just in it for the benefits and money. Without some mixing of the classes, this is what you get.

But in all my time, I’ve never seen employees running the company for a day, or executives on the assembly line. Maybe this is not such a bad idea!

July 2, 2012January 20, 2013

Improve Task Estimates, Multiply by Pi

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

T_e = (T_o + 4T_m + T_p) / 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. T_m – Most Likely estimate (example: 6 months)
2. T_o – Optimistic estimate (example: 4 months)
3. T_p – 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.)

T_e = (T_o + 4T_m + T_p) / 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!