Posted on

Why IT Projects Get Killed

I like CIO Insight.  They seem to hit a lot of relevant issues.  Their “Why IT Projects Get Killed” is a short slide-show with a simple breakdown of the top five reasons IT projects get killed.  A link to the article is below, and I’ll comment on the top reasons.

http://www.cioinsight.com/c/a/Management/Why-IT-Projects-Get-Killed/

Reasons:

  1. 30% Business Needs Changed
  2. 23% Does Not Deliver As Promised
  3. 14% No Longer a Priority
  4. 13% Exceeds Budget
  5. 7% Does not Support Business Strategy

Well, that’s only 87%.  I suppose the other 13% fall into the “Other” category.  I’d like to take a crack at interpreting the numbers.  Here are my thoughts on why IT projects are killed.

30% Business Needs Changed
From the time a project is first proposed until it is started, things have changed.  These are often projects tightly connected to cultural events.  For instance, your proposal for a new drive-through pharmacy may lose 7% of its expected revenue if the price of gas goes to $5.  Anything that tightly connected to consumer behavior must be watched closely.

23% Does Not Deliver As Promised
Oversell and hype.  Lots of people do it, and lots fall for it.  It always surprises me how pessimistic people are when investing money, but how easily they fall for a good story.  Almost a quart of the projects don’t live up to the promise.  But it’s not jsut hype that contributes to this number.  Sometimes people simply don’t realize how big a project is when they start it.  That’s understandable.

14% No Longer a Priority
This feels like reason #1.  Business needs change, and the project is no longer a priority.  But I suppose there other reasons a project may no longer be a priority: Can’t make money at it, Other solutions have arisen to replace it, Employees or customer have changed.  But still…  aren’t these all “business needs.”  If so, a full 44% are canceled just because “things change!”  Yikes!

13% Exceeds Budget
I expected this to be higher.  Most people I talk to go over budget on their projects.  That’s why they use products like Standard Time®.  They know they’ll be cancelled if they go over .  Well, maybe it’s doing its job!

7% Does not Support Business Strategy
This happens when unlearned individuals go off on exciting missions that the executives don’t support.  A project gets started, but killed soon after – once it’s discovered to be nonsense.  I’ve run into quite a few of these individuals.  But I don’t fault them; they try.  And that’s all the CEO really expects of them.

 

–newshirt

Posted on

How To: Filter Tasks in MS Project

Ever wonder how to reduce your Microsoft Project file from thousands of tasks down to a manageable few hundred, without deleting any?  Have you tried filtering?  This post discusses the steps to filter tasks in Microsoft Project.

Filtering is the act of reducing the number of visible tasks so that you only see what you are interested in.  All the tasks will still exist in the MPP file, but you will only see tasks that correspond to your filter criteria.  Follow these steps to filter tasks in Microsoft Project.

Create some tasks to filter by:

  1. Enter three tasks
  2. Set the durations to 10 hours, 20 hours, and 0 hours
  3. The results should look like the image below

 

 

 

Set up a new filter to show long tasks only:

  1. Choose Project, Filtered, More Filters…
  2. Click New
  3. Enter the name “Long tasks” (without the quotes)
  4. Click ‘Show in menu’
  5. Click in the ‘Field Name’ column, and choose ‘Duration
  6. Click in the ‘Test’ column and choose ‘is greater than’
  7. Click in the ‘Values(s)’ column and enter 10
  8. Click OK to save the new filter
  9. Nothing should change in your view

 

Activate your task filter:

  1. Choose Project, Filtered, Long Tasks (the new filter you created)
  2. Your view should now look like this image (hiding all the short tasks)
  3. Choose Project, Filtered, All Tasks to remove the filtering and show all tasks

 

 

 

–ray

Posted on

Sharing is Good

A few years ago I learned a valuable lesson.  I was working for a fairly large company in the order/shipping department to improve performance.  We were losing money on mis-picked items.  A customer order would be placed in a box with 1 to 15 items to ship.  That box would travel through our pick line, stopping at various stations, where human operators would pick the items ordered out of a bin, and place it in the box for shipment.  Too often, customers received the wrong items.  Then an employee would go out of sequence, make a special order and ship the correct item, a second time! 

My job was to reduce the number of incorrectly shipped (mis-picked) items.  To do that, I had auditors randomly inspect the pick line orders.  The ship line auditors despised our presence and we saw no marked improvement over the first few months. 

One day we had a meeting with the shift leads on the pick-line to explain why we were doing the audits.  We explained how a small decrease in the percentage of mis-picks would save our company hundreds of thousands of dollars and add to the bottom line.  In turn, this would increase their profit sharing bonus checks.

Over the next year we had a significant reduction in mis-picks and we received record profit sharing.  This happened in large part because we decided to share a little piece of information as to why we are doing what we do.  All too often we are quick to tell people to do something assuming they already know the reasons or don’t care, instead of explaining why!  I was guilty, and from time to time I imagine I still get in that “just do it!” mode.  However, I’ve learned that it is worth a few extra minutes to share the reasons behind our decisions.

–Warren

Posted on

Ready to Release?

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

Posted on

Why Resource Leveling is Old School

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

Posted on

Define: Earned Value

Earned Value: The amount of money a project has already earned, based on percent complete.

Calculating earned value will let you know approximately how much money is in the bag.  Obviously, it has to pass through the Accounts Receivable department, but eventually the money will be there.  This scheme works well for projects where money tightly follows work.  In other words, you do the work, and the money follows soon after.  While that’s often true of service-based companies like consultancies, it is not always true of manufacturing projects.

When a company manufactures goods, there is a much longer pipeline to cash.  Money does not tightly follow work.  You develop the product, test it, manufacture it, test it again, market it, sell it, and then your customer pays.  That process can take months or years.  So earned value is not as tangible.  And, there is the upside of selling the same design for several years.

Standard Time® calculates earned value based on Actual Work times the Client Rate.  Obviously, this is very tightly connected to the work you perform.  Every hour means billable time.  For consultancies, this matches reality pretty closely.

–ray

Posted on

How To: Set Working Time in MS Project

Microsoft Project offers calendars that can be used to set the working hours for a project and the resources working on it.  In other words, you can set the base calendar for the project, and then override that with resource work times.  This post discusses how to set the working time in Microsoft Project.

The following steps will illustrate the effect that working time has on a task in a Microsoft Project file.

Set up a new task:

  1. Enter a new task
  2. Enter 8 hours for the Duration
  3. Enter your Name as the Resource
  4. You will notice that the task occupies one day  See below.

 

 

 

To change the base calendar for the project:

  1. Choose Tools, Change Working Time
  2. Choose “Standard (Project Calendar) from the dropdown
  3. Hold down the control key and select all the working days of the month
  4. Remove the 1:00 PM – 5:00 PM hours (to make half days)
  5. Notice that the calendar has changed to show your new choices
  6. Click OK, and notice that your task Gantt bar has gotten longer to accommodate the fewer hours per day.

 

 

To change the individual work hours for the resource:

  1. Choose Tools, Change Working Time
  2. Choose your name from the dropdown
  3. Click on the second day of the task
  4. Hold the control key down and select three days
  5. Click the “Nonworking time” choice to signify a vacation
  6. Click OK, and notice that the task has gotten every longer

 

 

–ray

Posted on

Accuracy is a Necessity

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

Posted on

Why Enterprise Software Must Be Sexy

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

Posted on

Outsourcing: Buying Time

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