Posted on

U.S. Losing Competitive Edge in Technology

The recent eWeek story regarding U.S. decline in science and technology (see below) is nothing new.  We’ve heard this same story for twenty years.  But is anyone listening?

http://www.eweek.com/c/a/IT-Infrastructure/US-Losing-Competitive-Edge-in-Technology-Science-National-Science-Board-610257/

Over the Christmas break, I did my bit to encourage passion in software development, engineering, and project management.  I mentored a college student with an Arduio board.  (See http://www.arduino.cc/)  The Arduino is a microcontroller with inputs and outputs for controlling external devices.  It’s big in university engineering departments.  Awesome, dude!

We stayed up past midnight wiring circuits and slinging C++ code to exercise the Arduino I/O ports.  In a rat’s nest of wires, LED’s flashed, speakers squealed, and relays clattered.  Cool!  When it was over, the kid had a new passion for product development and engineering principles.

Code ‘til you drop, and then do it again tomorrow!  That’s my answer to declining technology in the U.S.  And I suppose it’s also my preferred project management style.

Posted on

Earned Value Increases As It Travels

Earned value (or the value you receive on your intellectual property) increases as it travels through the supply chain.  In other words, the farther an item travels from the manufacturer to the consumer, the more value it brings the manufacturer.  Consumer items change hands many times before they end up in consumer’s hands.  Each time they change hands, more money is invested, and therefore the value goes up.

Consider the illustration below.  A single egg isn’t worth much until it is developed.  Its value rises 100 times from nest to table.

Have you ever considered that software does the same thing?  It earns value as it passes from idea to developer, to QA, to packaging, to reseller, and finally to consumer.  So, the true Earned Value of a product is dependent upon its position in the supply chain, not just at the coder’s keyboard.  You account for such value by quantifying your products on their route to the consumer.

Posted on

What’s the difference between ‘Duration’ and ‘Work’?

What’s the difference between MS Project ‘Duration’ and ‘Work’ fields?  The image below probably explains it all.  It’s a simple task from Microsoft Project that shows both the ‘Duration’ and ‘Work’ columns.

 

Task Duration

 

As you can see ‘Duration’ defines the calendar time that the task will be worked on, while ‘Work’ defines the number of man-hours.  In this case, Frank is scheduled to work only 40 hours over the next four weeks.  That’s only 25% of his scheduled hours.

 

Posted on

Small Bites

I like keeping project tasks really, really short.  A week-long task is sometimes too long, but obviously satisfying when finished.  I also like keeping product releases very short.  A release might have only a few of these short tasks.  That ensures that the product is always within a few days of release.  Project scheduling is simpler when tasks are short.

Posted on

Let’s do a meeting!

Does your company do too few meetings?  Yeah, you heard me right… too few.

If you’re like most corporate employees, you’ll answer, “Definitely not!”

Most of the scenes in the Dilbert comic are in meeting rooms.  That should tell you what Scott Adams thinks of them.  Meetings are the first signs of death in a once vibrant company.  But beware; lack of meetings may spell the same results.

Meetings done right should get your blood pumping for action.  You should go away wanting to try something new, or hoping for change, or at least inspired to follow.  Make that the aim of your next meeting!

Posted on

Timesheets are boring

Why get passionate about a boring timesheet tool?  They are little more than cells and dropdown choices that collect your time and expenses.  An endless bucket.  Pointless.  Employees reluctantly fill in those monotonous little cells every Friday afternoon or Monday morning for the week prior.  Time tracking is a chore with little value.

Okay, that’s one perspective…

But have you ever viewed them as an investment?  Like pouring value into your organization that you can mine later?  Consider that for a moment.

What if you could magically predict how long your next project would take?  Or cost?  What if you could walk into the next meeting with hard evidence that your company talents are unfocused and distracted?  That you are fighting too on many fronts?  And in too many battles without clear endpoints?  Wouldn’t that be worth documenting your time for.

That’s what time tracking gives you, among other things.  Still see it as a boring chore?

Posted on

Vicarious Goal Completion

Bear with me…  Vicarious Goal Completion is a pretty obscure title, but there’s logic to it.  🙂

Psychologists have observed a strange human peculiarity.  And it relates directly to project management.  It’s called Vicarious Goal Completion.  Researchers first encountered it while studying fast food menus.  Can I get you to bite?

When fast food menus contain a “Salad” choice or other healthy food items, people purchase the junk food instead! 

Here’s why: People who see healthy items on a menu feel good about their weight loss goals and give themselves permission to indulge a little.  So, they eat the burger and fries instead.  In other words, they remember eating good and believe they have already attained their goals, so that gives them permission to splurge.  The goals are completed vicariously through the menu itself.

Obviously, this is just a slick way of tricking oneself into dodging responsibility.  They used to call this laziness.  Any excuse to pig out.

I’ve notice the same behavior with software downloads and project tasks.  The ratio of downloads to form-completions is pitifully low.  In other words, people take the time to fill out a download form, but never actually install and test the software.  Vicarious Goal Completion!  The person believes they have finished the job, when in fact, they have only just begun.  Filling out the form gives them a warm fuzzy feeling about the goal of procuring software, and that warm feeling is enough to satisfy them.  They don’t actually care if they download, install, and test.  They have met their goals and that’s all that matters.

The same is true of project management.  Beware of employees who start tasks, but never complete them.  Once a task is started, good feelings arise.  Those good feelings give the employee permission of quit because they feel they have already finished, or full completion is within sight.  Vicarious Goal Completion!  Nobody likes to take their project tasks to the uttermost level of completion – unless forced to do so.

 

–ray

Posted on

The X, Y, and Z’s of Product Development

A certain thing happens in product development…  (It used to bug me to death, until I got used to it.)  Your product development team just finishes a great new feature.  Everybody rejoices.  Good feelings, pride, and celebrations.  All that…  The new release is posted on the web, and you start to get downloaders.  Potential customers are giving it a look.  And you know they are seeing the great new feature you just added.  It has “X” and “Y” new things.  Everyone will love it.  Everyone will buy.  You’re sure of that!  Finally… we’ve gotten a great product out there…

The next thing you know, you get an email from an evaluator.  He can’t believe how short-sighted your product is.  In fact, he’s practically indignant.  It’s missing a key feature he needs, and he can’t belive you’d ever consider shipping a product without it.

He asks, “Can you do it?  When will it be available?

“Maybe, next month.  Can you describe it more fully?”

“Oh, I can’t wait that long…  Forget it.”

The situation is that you’ve completed “X” and “Y” but haven’t gotten to “Z” yet.  And that’s what spoiler-boy wants.  Problem is, you never considered “Z” until you completed “X” and “Y.”  Or worse yet, didn’t consider it until he pointed it out.

This is so common.  People cannot see to very down the product road-map.  That’s human nature.  They can see “X” and “Y” but only have fuzzy glimpses of “Z.”  That is, until some grumpy customer complains that it’s not in the product.  He doesn’t see the hard work you put into getting the first releases out.  I.e. getting “X” and “Y” out.  He just sees that “Z” is missing, and feels pretty certain that he can’t do without it.  He’ll move on…  Somebody out there must have it.  “I’ll look around…” he says.

Better get cracking.  Again…

 

–ray

Posted on

Beware of Default Behavior

My definition of “default behavior” is: doing what 90% of the world’s population does, when faced with a new or unfamiliar situation.  Panic and give up.  Let me explain.

The “average guy on the street” almost always acts the same way when faced with something new or unfamiliar.  He throws up his hands and asks for help.  No thought.  No research.  Just give up and ask for someone else to do it for him.  “Tell me how to do it.”

If you expect to manage projects or people, you must learn how to think independently.  And learn how to handle unfamiliar situations without exhibiting “default behavior.”  Here are some examples:

You are asked to download a program:

Default behavior: “What’s the URL again?”

Better: Google the name or look it up in your list of products.

 

You are asked to reconfigure all the users in a certain program:

Default behavior: Call tech support and ask how

Better: Explore the program and learn it

 

Your project is over-budget and stalled:

Default behavior: Ask for more money, time, and resources

Better: Huddle up and cut secondary priorities

 

You may not suffer from these exact scenarios, but the general advice is sound.  Learn to recognize your responses to unfamiliar and stressful situations, and improve them beyond the default behavior.  Career advancement depends upon it!

–ray

Posted on

IT is Backed Up – Forever

Consider this dilemma…  The IT department is backed up for six months.  It can’t take on any new projects for that time.  Not even a little 4 – 8 hour database installation.  With a log jam like that, they can’t get anything new in.

Management comes along with a new product evaluation.  Problem is, they need IT to set up a new SQL database so they can test the system.  Oops, can’t do it.  There’s a six month waiting list, and nobody get to the head of the line.

So, management can’t evaluate the product.  Even a product they desperately need.  IT has failed the company in a big way.  The frustrating thing is that most of those IT projects are probably lower priority, or impossible to complete.  Incompetence has allowed such projects to block real work.

The only real solution to an issue like this is “better generaling.”  I.e. better planners who know roadkill when they see it, and pitch it off the road so it can’t block the real projects.  That takes a smart person with a little experience.  Gain a skill like that (and a hundred others), and you suddenly become a valued member of the team.

 

–ray