Posted on

Homemade Products Don’t Sell

Here’s just a quick reminder that homemade products stick out like a sore thumb.  Have you ever encountered a product that was clearly not professionally produced?  They just look awful, and one look at them screams, “Homemade!” or “Unprofessional!”  It doesn’t take long for consumers to sniff you out and flee.

Epic Fail

This past weekend, my wife and I stayed at a little ‘mom and pop’ motel in a little town in Colorado.  With one step into the room, I got a good reminder of this issue.  (See the pics below from my crap phone)  The entertainment cabinet was hand-painted, and looked awful.  I nearly fled the room, but decided the cost was cheap enough to entice me to stay.  It turned out fine.  But ugly little piece of artwork really drove this point home to me.

Consumers do not like hand-crafted products.

Epic Fail 

Let’s face it… we live in a consumer-oriented world.  Almost every product we touch is machine made, and professionally crafted for maximum emotional indulgence.  Think about the indulgent products you use on a daily basis: $50,000 automobiles… iPhones… stylish eyeglasses… jewelry… and more.  Every product we use it slick and well-designed.  So consumers are used to those kinds of products.  Now slap and homemade software product in front of them, and watch them flee!  Or a poorly polished plastic drinking cup… or any other product you can imagine.  Consumers expect high quality.

This issue is especially true in software, where programmers are sometimes responsible for developing the entire product from code to help files to graphics.  Software developers just don’t have the talents for all those jobs, and it’s very obvious when they try.  The results are a lot like the Riviera Motel.  Can you guess where it’s located?

Epic Fail

Posted on

The Harmonious Project Management Trinity

Regardless of the role you play in company projects, you will likely see three primary personalities in the project management and executive teams.  In other words, if you are involved in engineering a product, or managing the development of a new product or service, holding the executive reins of a company with project management, you will likely see individuals with the following three personality drives.  These three primary issues drive their thinking.

1. The “On Time” Person
The time conscience “On Time” person primarily worries about project schedules.  When will each subsystem be finished?  Each milestone?  Each Phase?  And when will the project ship?  This person studies and observes all the team interaction with dates and times in mind.  Is the project going to be late?  If so, what can we do to fix that?  His first suggestions are to defer features for a later release, cut the scope to something more manageable, and to create a smaller, foundational release that can be improved upon later.  In other words, meet the agreed-upon ship dates at all cost, and defer more advanced things until later.

2. The “On Budget” Person
The cost conscience “On Budget” person thinks much like the On Timer.  He thinks primarily about project costs.  Blow the budget by a dollar, and he freaks out!  And since the biggest cost in most project is human resources and salaries, he’s thinking the same thing as the time conscience person, “get the project done on time so you don’t blow my budget.  And if you don’t think you can get it done on time, cut something so my budget isn’t wrecked.”  Time and budget go closely hand in hand.

3. The “Quality” Person
The quality conscience person primarily thinks about the consequences of releasing a bad product.  What will the marketplace say?  How will customers receive it?  And the Press?  It’s hard to recover from bad press or a mainstream revolt against your product.  You could lose millions of dollars just from a Facebook uprising.  It would be far better to spend an extra month getting right, or an extra $100K, than to suffer a marketplace meltdown.

So you see that these personalities can be in conflict from time to time – not exactly harmonious at all times.  The Quality person doesn’t want to witness a total user-base revolt because of a poor product.  The budget person doesn’t want to sink the company in debt.  And the schedule person doesn’t want customers to walk away all because the product took too long to deliver.

The best hope a company has is to recognize that these personalities can all exist in one project management team.  Recognizing each one for its merits goes a long way.  Sometimes people just want their input valued.  The next step is to work together toward mutually agreeable compromise that includes input from each driving force.  Hopefully, the result is a good quality product that doesn’t ruin the company in debt and unresponsiveness.

Posted on

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.

Posted on

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!

Posted on

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.
Posted on

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!

 

 

�

Posted on

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!

Posted on

Should You Go Cloud?

That is the question…to cloud, or not to cloud?  I recently read an article by Sarah Fister Gale, found here: http://www.pmi.org/~/media/PDF/Publications/PMN0312%20cloud.ashx
It is interesting how many people go to the cloud without knowledge of security, back-up, redundancy, and so forth.  There is little doubt that the cloud has many positive attributes.  That is why cloud usage continues to experience robust growth.  However, too often people just assume the cloud is a magical solution with hardly any issues.  Well, that is normally the case…unless you happen to be my brother-in-law.  His company was utilizing a cloud hosted credit card processing service.  And things were great for nearly two years, until the cloud server went down and there was no back-up plan in place.  It took 3 days of hand wringing and lost sales to get back online.  In addition to immediate lost revenue, he lost long term customers.  The article above will certainly give you an idea on specific questions one should ask and a basic outline to help you make a solid choice for your cloud solutions.

�

Posted on

Don’t be the DIA and BAE Baggage System

Remember the expense delays in opening the brand new Denver International Airport?  Many case studies have been done examining the intricate reasons for such a colossal failure on a grand scale.  DIA was to be the most efficient airport in the world, able to accommodate over 50 million passengers per year.  One of the key components was to have a fully automated baggage system…eliminating the tug and trolley system.  This would cut a planes turnaround time by 30 minutes and would be a key component in creating more efficiency with flights and passenger throughout.  The chief project manager, Walter Slinger had his heart set on this shining new system and romanticized about the notoriety the state of the art airport would bring to the city of Denver.  BAE also liked the idea of designing a system that would garner great attention and further their own reputation for building baggage systems.  Again, you could read many in depth case studies about the key decisions that led to the cascade of delays and failures.  However, I would summarize them in a single manner, tunnel vision.  Both parties fell in love with an idea and ignored many internal obvious warnings about the baggage systems feasibility.  The delays were numerous and cost billions of dollars.  In the end, after many attempts to partially use the automated baggage system, it was virtually scrapped for the more economical tug and trolley method.  We all know the old saying that our eyes are bigger than our stomachs?  If you’re a project manager, make sure your love of an idea isn’t greater than your team’s ability to design and implement the idea.  Don’t be afraid to change directions.  Otherwise, you may be the next DIA, which is still one heck of an airport!

Posted on

Project Quality Assurance

Project quality has many facets depending on the type of project and the quality objectives. A few common metrics used are guidelines and standards.  Most people understand the difference between the two.  However, guidelines can be confused with standards.  Guidelines are just that, an idea or parameter to stay within.  Standards are a more exact objective to be met.  It is well worth while to make sure people are clear on the differences and expectations of each.  Otherwise, a small misunderstanding can be costly.  As an example, a sorting team was tasked with looking through thousands of figurines to inspect for defects.  The guideline says the figurines can have up to 3 blemishes on the front portion, no larger than 2 cm each as long as they are not on the face.  The Standard stated if there is only one blemish allowed in the facial area and they must be less than 1 cm.  Well, an entire shift didn’t understand the difference between the guidelines and standards and inadvertently allowed figurines to pass through that had single blemishes on the face up to 2 cm…double the allowed size.  This was caught during a random audit and thousands of figurines had to be re-sorted costing the company hours of productivity, not to mention money.  As cliché as it may sound, never assume anything. Communication is vital.  A simple misunderstanding can cost an entire project.