Category: Uncategorized

I have been in sales and marketing for some time now and I work with Project Managers (PM’s) nearly everyday. It struck me the other day how similar PM’s and sales forces really are. Project Managers are sales people on many levels. Project Managers often have to sell the benefit of an idea to get their teams motivated. Project Managers identify problem areas to avoid, as do sales professionals.

An interesting twist on this is taking the problem a step further and identifying the problems’ implications and consequenses in any given project.  It is one thing to note a specific problem, but if you really want to wake the team up, talk about the implications of that problem in greater detail. Bring up examples of likely scenarios and issues that could arise. By stressing the implications, you will put a magnifying glass on the issue and focus on the ways to avoid that pothole! After all, problems come and go, but the consequences may not.

 

–Warren

Being consistent in your management style and personality is important for success. One of the first lessons in parenting is being consistent.  If you discipline your child one time for something, but then ignore that same thing a different time, you are sending a confusing mixed message.  Obviously, your project team members are not children, but the principle still applies.

Our teams depend on us for leadership and direction. As managers, if we are on a roller-coaster of emotion, our project teams will be all mixed up.

My manager when projects are late

Inconsistent behavior stifles creativity and does not allow a tolerable environment for ideas to be exchanged.  If a team member is not sure how you will react from one day to the next, they are less likely to be forthcoming with ideas and suggestions.

No matter how crazy a project becomes or how much stress leaders are under, we must be the model of consistency.  Like the commercial says, “never let them see you sweat.”

 

–Warren

Our company develops a line of products.  We sell the same off-the-shelf design to many customers.  They all essentially get the same thing: a downloadable product with a certain set of features.  But there is always somebody that needs something a little different.  That’s when they become “special.”

Developing special features for a single customer can pose special challenges to an off-the-shelf product.  This post discusses three of those challenges.

My biggest concern is punishing 99% of the customers with a feature that only 1% will use.  Suppose you add a new feature to the product that 1% of your “special” customers will use.  The other 99% may not understand it.  That’s a bad thing.  They’ll think they need to understand it, and will spend time studying it, only to learn that it does not apply.  My advice: make sure that doesn’t happen.  Bury it where only the most adventurous will find it.

The next concern is maintenance.  If you create a new feature for one customer, guess what…  You’ll have to make sure it stays working forever.  It will cost you money as long as you maintain it.  Make sure you get that money up-front, or in maintenance payments along the way.

Have you given any thought to the effect your “special” features have on the rest of the product?  In other words, will these one-off features break something else.  The more complex a product is, the more likely collateral damage will occur.

The upshot is that special features cost more money than you might think.  But you have to do them to gain new customers and satify existing ones.  It’s all part of the game.  Just make sure you are profitable doing it.

 

–newshirt

We’ve all heard the saying, “the customer is always right.”  So when a customer and vendor disagree, it implies the vendor is always wrong.  I realize this is a customer service driven idea meant to teach us to take care of our customers.

However, I have seen companies blame vendors all too often, without examining their own shortcomings.  This is an epidemic in our culture, it’s always someone else’s fault and no one wants to be accountable!

Just this week I had an opportunity to do business with a major U.S. company.  A company most everyone has heard of but will remain nameless.  To my surprise I lost their business at the last moment.  In fact, one of the VP’s had stated just days before, “I am ready to cut you a check tomorrow.”  The deal was done, right?  Well, not exactly…after a lot of meetings and numerous discussions met with many delays.  I was told that we (the vendor) were missing a key component.  What’s ironic is that I did countless demo’s and was assured that the deal was done.  The missing feature was never mentioned.  Then bam, it’s over!

We may have been able to accommodate this last minute need, but we’ll never know! We will continue to do business and press forward and I will examine what I could have done differently. 

How can a major company have a year and a half of meetings, discussions, and reach the end of a path only to find out that they didn’t really know what they wanted and then simply brush it off as a vendor problem?  It always hurts to lose business, but the vendor isn’t always be wrong.

–Warren

This is not as bad as it sounds.  A lot of companies are in this boat.  They don’t have the revenue to hire full time QA engineers and testers.  So, they do what they can and rely on customers to report bugs, oversights, and possible enhancements.

Let’s briefly discuss how a ‘real’ QA department operates, and then contrast that to the poor-man’s solution.  Normally, a QA manager and team of testers ensure that products delivered straight from the engineer’s drawing boards ship with minimal bugs.  Each tester is assigned one or more areas of the product.  They follow a QA plan and checklist.  Every feature is scrutinized, often put through the paces as real customers would use it.  Bugs are sent up the chain, through the QA manager, and back to the original engineers for fixing.  Once resolved, QA engineers verify the fixes.

A QA department is nice to have.  They find hundreds of issues, and save the company a lot of money and embarrassment.  Product defects are resolved before they hit the shelves.  In the end, the QA department is usually worth their pay.  After all, that’s why the department exists in the first place – to save the company money.

But if you can’t afford the salaries, and you have a small number of customers, the development and manufacturing engineers will need to perform the dreaded duty.  (It is monotonous work.)  Problem is, engineers bristle at repetitive tasks like product testing.  They won’t do a thorough job, and you still end up getting bug reports from customers.  Plus, you’ll have to pay the engineers for their extra testing work – and they aren’t cheap.  Bugs that reach the outside still cost you money in customer dissatisfaction and lost sales, but perhaps not as much as the salaries for a full testing crew.  That’s the real gamble.  And, there are so many intangibles that a true cost analysis of each method is difficult.  But, you’ll know when you need a QA team – when customer complaints begin to kill your product momentum.  When that happens, put together a team quick!

 

–newshirt

How do you know when your product is ready for release to waiting fans?  Does it have what they want?  Is it high enough quality?  Will it crash and burn, costing you thousands of dollars?  Tough questions.  Unfortunately, there are no great answers, but consider the following factors.  They may help.

Keep it foundational
There’s always a temptation to boil the ocean with your grand scheme.  To have the best product in your class.  After all, you’ll never make money without it.  But this is a trap.  Great products take years to develop, and if you wait that long, you’ll never get a foothold in the marketplace.  It’s far better to get started early with a foundational product, and constantly improve it.

Listen to customers
Every feature in your product should come from customers.  Don’t invent stuff yourself unless you are certain it’s the next great thing, and then still don’t.  Chances are, you’ll have a tough time selling pipe-dream features that customers don’t ask for.

Always ready for release
This only applies after you have already released the product at least once, and applies best to iterative products like software.  Never dive so deeply into new features that you can’t release the product at least once a month – even when doing major upgrades.  Release the product frequently to beta testers and trusted customers, but don’t let it stay “down under” too long.  This keeps the bug count lower, and keeps you closer to customer input.

Test twice, and twice again
If you’re like most engineers, you’ll spend half your time polishing and fixing bugs.  But many don’t realize that.  They want to blaze new trails and invent new things – all the time.  But you can’t make a living like that.  Be patient with your product, allowing it to mature into a robust system.  Don’t walk off until you are sure it is.

Good luck with your release, and let me know how you made out.  🙂

 

–ray

On the surface, resource leveling looks appealing.  It offers the ability to spread work out so that an employee never has too little and never has too much.  Sounds good, right?  Maybe not…  Read on and let me know what you think.

The problem I have stems from the term resource itself.  Some of my customers won’t even use the word because it turns employees into machines.  Are “resources” human beings?  No, they are just “things” to be used.

I don’t go that far with my interpretation.  I’m okay with the word “resource.”  I know what it means, and what it doesn’t mean.  But still, when software attempts to tell the employee when to work, something is wrong.  Shouldn’t it be the other way around?

Spreading work around (as is in resource leveling) removes the human element from the project.  It turns employees into machines who crank out project hours, task after task after task with no regard to content.  One task is the same as another, right?

I’m sorry; people don’t work that way.  Machines do.  They love steady work.  Give them something to do, and they will churn it out day after day.  People work differently; they are diven by passions and love for the job.  They get excited about one task, and then another.  They schedule them in order of passion for the task at hand.  No passion – no work.

As soon as you allow software to tell your people when to come and go, the passion is gone.  Make sense?

 

–ray

I had the misfortune of incorrectly accusing a vendor, one of my company’s main suppliers, of neglect. It turns out…they weren’t neglectful at all!  I was wrong and had received bad information!!

I worked in the new product engineering group with a company that sold a lot of knick-knacks, similar to what you find in card shops like Hallmark.  We did catalog sales without a storefront.  My company had tens of millions in annual sales.  Part of my job was creating a new quality control program to improve the products we purchased from our manufactures.

One bright day I sat across from our main supplier and delicately challenged them on a few quality issues we had found in one of our recent audits.  You can only imagine my embarrassment to find that the product I trashed, was not theirs!  An auditor on the QA Team had incorrectly identified this problem product with the wrong vendor!  I had discussed three products in total, two of which belonged to them, the third did not.  Rather than making progress and improving the two products correctly identified as theirs, I spent the better part of two hours mending fences and eating crow.

Needless to say I had a long discussion with the auditor that filed the flawed report.  We put in place procedures to double check and verify products and correctly assign them to the right vendor.  I learned a valuable lesson that day.  Accuracy is important and usually doesn’t take much effort.  This was a lazy mistake that nearly brought down a 10 year relationship and wreaked havoc for thousands of other people.

Whether it is simple or complicated…having solid accurate information is a must.

 

–Warren

I’m going to put in my two cents regarding the sexification of enterprise software.  The argument of whether enterprise software needs to be sexy (to keep up with consumer products) is still on the table.  See the CIO article below.  I vote “Yes” and here’s why…

CIO article by Brian Watson: Newer innovations like software as a service, Web 2.0 and mobile applications are broadly available to those outside the IT department. For those consumers of business software, freshness and flash are key selling points.
http://www.cioinsight.com/c/a/Foreward/Why-Enterprise-Software-Must-Be-Sexy/

Enterprise apps are made to serve a specific purpose.  They track project time (like Standard Time®) or access human resource records (like SAP®), or any number of specific jobs.  People use them every day, and their value lies in the depth of service they provide.  Apps that do a lot, command the big bucks.  Try to replace them, and you’ll have a huge battle.

But still, people have to use them every day.  And if they don’t like them, they gripe.  That huge battle to replace them suddenly looks pretty small compared to dealing with unhappy employees.   No big app can last forever in the face of employee dissatisfaction, regardless of its value in the enterprise.

And guess what?

All those employees have consumer items they compare the enterprise apps to.  Cell phones, big screen TV’s, PDA’s, cordless phones, etc.  They begin to expect the big enterprise apps to employ some of the sexy usability enhancements they find in their personal consumer items.

Think about it…  Would you rather use an enterprise app with 80’s-style “VCR” controls or those of your cool new MP3 player?  That’s why enterprise apps need to be sexy.

 

–ray

For product development teams, outsourcing almost always means “buying time.”  Every project has three aspects in contant tension: Time, Cost, Quality.

1. If you want to save time and get your product to market faster, you can pay more (cost) or make a smaller product (quality).

2. If you want to spend less money, you can delay the delivery date (time) or cut features (quality).

3. If you want a high quality product, you can spend more money (cost) or wait for it to mature (time).

Outsourcing clearly cost’s money.  So why do it?  To get your product to market faster, that’s why.  You are spending the money now, so that you can recouperate it earlier.  Beat the competition to market.

No?  You’re not doing it for that reason?  You’re using India as a cut-rate development shop?  Oops, that may be a mistake.  Remember the other aspects in constant tension?  Quality is one of them…

 

–ray