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

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!

June 26, 2012March 12, 2013

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.

June 18, 2012June 18, 2012

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.

June 12, 2012March 5, 2013

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!

�

June 11, 2012April 11, 2013

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.

�