Posted on

CIO Insight: How to Retain Top IT Workers

CIO Insight did an article listing the top 10 ways to retain IT workers.  The link to that article and results are listed below.  It’s pretty interesting, but appeals strictly to the least-common-denominator or employment.  The results could apply to a landscaping firm.

http://www.cioinsight.com/c/a/Management/How-to-Retain-Top-IT-Workers/

 

They rated each criteria from 1 to 3, with 1 being the lowest, and 3 being the highest.  Notice that the results have little to do with IT workers.

    Lowest                                                       Highest
        1                               2                                3

    1. Salary: 2.82
    2. Training: 2.47
    3. Incentive pay: 2.40
    4. Paid Time Off: 2.38
    5. Flex Schedule: 2.36
    6. Work Facilities: 2.26
    7. Insurance Benefits: 2.26
    8. Retirement: 2.13
    9. Work at Home: 2.06
    10. Social Environment: 1.99

I’d like to add an intagible criteria to the list: “IT Imortality.”  And I’m wondering where you would place it.  A 1 or a 3?  Send in your comments.

IT Imortality is the chance to rise above your peers in a significant way, building products that change the industry.  It involves working with the brightest and most motivated individuals on the planet.  It means leading (or participating in) a product development team that makes a true impact on your generation.

Although I cannot say I’ve achieved such a lofty status, the lure has certainly been there for every company I’ve worked for.  And, at least a few of my projects have impacted individuals around the world.  That’s offers a sense of achievement that no cubical job can.  I rate that somewhere near 3.

–newshirt

Posted on

Use Agile Method for Ongoing Maintenance?

A programmer friend of mine told me that his ongoing maintenance projects didn’t really require the Agile Method.  He said that he liked the idea, but his small team was just working on short, simple updates to an existing program.  He didn’t need a methodology to assist him on that.

We discussed the fact that the Scrum method was light, but still injected some measure of oversight into projects.  But he insisted that his ongoing work needed no such oversight.  He knew what he as doing, and didn’t need a babysitter.

Knowing this guy, I tend to believe him.  He’s been doing C++ programming for two decades, and knows exactly how to get a project done.  But the idea still bothered me.  Isn’t Scrum for everyone?

I believe the answer lies in the size and competency of the team.  Small, highly competent teams, who perform known work, can bypass the methodology.  Just like my friend said, they know what they are doing, and don’t need any “process” help.

But this guy is a rare beast.

Most engineers face a large number of unknowns, and need a simple system to guide the project team to success.  Scrum does that.  If you are unfamiliar with the method, consider getting a little help from these folks: http://www.controlchaos.com/ or these guys http://www.agilealliance.org/

 

–ray

Posted on

My Dead Project. What Went Wrong?

Last night I attended a party at an old friend’s house.  After small-talking my way around the deck, I hooked up with some old acquaintances, with whom I had participated in a software project.  The gig we shared had taken place back in 1999, in Atlanta.  It was one of those 90’s love-fest dot-com jobs.

While sipping cokes and gobbling slices of homemade pie, we discussed the project’s failings.  “What went wrong?” I asked my colleagues.

“I think it was the fault of the CEO,” one said.  “He just had no experience, and wasted all the money.”

“No, the development organization was all messed up,” the second said.  “The lead engineer kept jumping in and changing everything I did.”

“Well, I think they spent all their money on marketing before they even had a product to sell,” I put in.  “You have to make some sales and get customer feedback before you can spend millions on marketing.  Don’t you think?”

The discussion heated up for the better part of an hour, and I realized that none of us, even ten years later, knew exactly where the faults were.  Who had messed up?  What had gone wrong?  Why hadn’t we succeeded in shipping a product and engaged the sales channel.  None of us knew for certain, yet we all saw some pretty gross mistakes.

That really got me thinking…  Sometimes project failures are not as easy to diagnose as one might think.  Even by salty old dogs like us.  And everybody has their own opinions.  Think about that the next time your project bites the dust.  Or before it does.

 

–ray

Posted on

Project Overload: Too Many Requests

I once read a bizarre statement, written by an overloaded IT manager.  He was complaining about the heavy workload his executive management was throwing on him.  Here is what he said:

When a new project request comes down, I just ignore it.  I ignore it until management makes it clear my job depends upon it.

Wow!  That’s revealing!  Evidently, this poor soul is so swamped with exciting new projects that he is forced to ignore the bulk of them.  I can vividly see how these superfluous demands go down.

First, the executives get a great idea.  Yeah!  Let’s restructure the customer database to maximize the communication [read: spam] we send out.  We’ll get some great sales!

The project is handed off to Harold in IT.  “He’ll make it happen,” the suits say.

Harold comes in Monday morning, sorts through 400 spams, and finds the outlandish request.  He rolls his eyes and drops it into the “Oh Boy!” folder.  And then he checks the ESPN stats.

The execs never give the project another thought.  They just go off and reinvent the company ten more times, dumping an equal number of requests on poor Harold.  And he ignores them all.  He doesn’t have time for the fun.  He’s got real work to do.

Am I off?  Got it all wrong?  Honestly, I don’t think so.  I’ve seen numerous projects like this get swept under the rug.  Execs don’t run the show, the little guy does…

 

–ray

Posted on

Down Economy: Billing Clients Imperative

I suppose it goes without saying, but with a down-economy, now’s the time to bill clients for every hour you’re entitled to.  And to watch your resource utilization more closely.  Below are some areas to watch for.  Consider a product like Standard Time® to make them happen.

Resource Utilization
Resource utilization is the percentage of billable hours your employees are working.  Let’s say there are 172 billable hours in a give month (every month is different).  And let’s say Fred only worked 45 of them, and Angie worked 100.  The utilization rates would be 26% and 58%.  Not great, but workable.  Can you make money at those rates?  Well, that depends upon employee salaries and overhead.  Increase your utilization rates, and you win.  The image below is a report of utilization rates.


Utilization Rates

Correct Billing Rates
For every hour you bill clients, you have a billable rate.  Those rates depend upon employee skillsets, and the tasks performed.  Research and Development will naturally bill out at higher rates than travel and meetings.  I recommend using Standard Time® to monitor those rates for each employee.  Make sure you’re billing at the correct rates, and for every hour your people are employed.

Communications and client Login
Clients like to see what you’ve been up to.  Without a client login into your time keeping software, they aren’t certain what’s being done on their projects.  They begin to wonder.  Give them a client password, and let them peek into their own projects.  It will aid in your communications efforts.  Communications is everything in client relations.

The folks at Standard Time can demonstrate all these areas:  Give them a ping!

–ray

Posted on

Fix Your Bugs!

The early World War I fighter planes had machine guns mounted above the fuselage.  They fired right through the spinning propeller.  That worked most of the time, but occasionally cut the propeller right in two!  I’d call that a bug.

I’ve learned over the years to fix my bugs quickly.  As soon as they are discovered.  Leaving unfixed bugs in a product can result in some nasty consequences.

Suppose you’ve got a small bug that bothers a few smaller customers.  It may not cost you anything in lost sales.  Most people can live with it.  But then along comes a big demanding customer.  When he sees it, maybe along with a few others, he freaks out and decides not to purchase.  You just lost a great sale because of one little bug.  A bug you could have easily fixed.

Moral of the story: don’t cut your propeller in half.

–ray

Posted on

How To: Resource Allocation in Standard Time

Resource allocation in Standard Time®is very straightforward, mostly because ST does not have the complex scheduling capabilities of Microsoft Project.  The image below shows a (compressed) screenshot of the resource allocation window.  We’ll discuss how to display and manage task allocations.


Standard Time Resource Allocation Window

 First, you should realize that the bars represent hours worked in a time period.  The resource allocation window collects all tasks assigned to each employee, and assembles them into time periods based on their starting dates.  If you have ten tasks that all add up to 80 hours, you might see two bars, one for each week.

The red bar in the image above represents a over-allocated week.  That means you have too many tasks to be performed in a single week.  Yellow bars indicate to little work (or under-allocation).  Blue bars are just about right.

Simply create new project tasks and give each one a starting (and optional due date).  When these tasks are assigned to employees, the resource allocation window shows them split up into time periods.  That’s about all you need to do!  It’s pretty simple.

–ray

Posted on

Define: Effort Driven Scheduling

 Effort driven scheduling: Calculating project task duration based on assigned resources.

 

When you assign resources to a project task in Microsoft Project, it recomputes the ‘Duration’ field.  The screenshots below illustrate this.  We’ll begin with plain tasks with no resource assignments.  After creating the tasks, we’ll assign the first resource, and then all the rest.  We’ll show that the ‘Duration’ column is changed when more resources are assigned.


Tasks with no resources assigned

 

Why does Microsoft Project recalculate the ‘Duration’ field when new resources are assigned?  The ‘Duration’ column indicates the calendar time that will elapse as the task is being completed.  That may be different than the ‘Work’.  If more resources are added, the calendar duration will go down.  That is effort-driven scheduling – based on employee effort.

 


One resource assigned

 

A magical thing happens when we assign multiple resources to tasks.  Notice that the ‘Duration’ column is reduced to reflect the extra effort applied to the tasks.  Since the tasks are effort-driven, they require less calendar time to complete.

 


Effort-driven task scheduling

–ray

Posted on

Advice: Develop Products for the 98%

Here’s some project management advice: And I’m going to complain a bit…  Hope you don’t mind.  🙂  I notice user interface design – especially in software products.  I notice menu placements, dialog box layout, screen widgets, and everything else.  And there’s one thing that always bothers me.

    Complex products seemingly designed for 2% of the intended users – %*^$*#

Developers fall into a common trap: adding too many menus and screen gadgets.  Here’s how it happens…  Sales managers, product managers, and CEO’s all want products to do something new.  Something big and flashy.  Something they can sell.  So, they call down to the developer’s cubes to make it happen.  And it does!  Unfortunately, so do dozens of other feature requests.

Developers often don’t know how to bury the obscure features and highlight the common stuff.  Everything is given equal weighting in the user interface.  That’s okay until you have a hundred big features.  And then everything runs together.  Users see so much stuff, they can no longer gear the product to their own purposes.  It takes a Masters degree to figure it all out.

A better approach is to develop the product for the 98% of customers who will use it.  In other words, MAKE IT SIMPLE!  Bury the features intended for the other 2%.  That doesn’t mean you’ll only bury 2% of the menus and dialogs because normally about 50% of the product falls into the “obscure” category.  Bury all that, and explain it to the 2% who need it.

 

–ray

Posted on

CIO: Are You Involved?

CIO Insight had a short article that got my attention.  See the link below.  It caught my attention because it lists the business areas where CIO’s are not typically involved.

http://www.cioinsight.com/c/a/Foreward/What-IT-Leaders-Dont-Do/

Areas CIO’s are not involved: 

  1. Choose geographical markets to enter
  2. Choose product markets to enter
  3. Choose product lines to enter
  4. Hiring non-IT employees
  5. Acquiring other companies
  6. Merging with other companies

 

I’d like to hear your opinion!  Should CIO’s be involved in these areas?  The first three are the domain of sales and marketing executives, and the last three belong to the CEO (who the CIO normally reports to).  So what involvement should the CIO have in these areas?  I would think little, if any.

CIO’s typically care about the information infrastructure of their organizations.  So how do these things apply to that.  Well, there’s web sites, databases, web services, network traffic, logins, etc, etc, etc.  I suppose that’s a fair degree of overlap.  But does it warrant anything more than a token seat at the conference table (when discussing the issues)?

Your thoughts?

 

 

–ray