Posted on

I Quit!

I’ve decided to quit the software development and project management biz to get into the more lucrative, albeit illegal spam biz.  I could spend a billion spams a day!  If you’ve been following my blog, don’t dispair.  You’ll still hear from me, just in the form of men’s health emails.  (That’s a joke, folks!)

CIO Insight did a short piece on eleven reasons to quit your job.  See the full story here.  It’s so funny!

http://www.cioinsight.com/c/a/Careers/11-Outrageous-Reasons-to-Quit-Your-Job-758179/

Do you have a trust fund?  That’s a good reason to quit.  What about if you are making too much money and don’t feel you deserve it.  Well then just quit!  Those are just a few good ones from the survey CIO Insight did.

Prototype

CIO Insight

Actually, those are great reasons.  In fact, all the items on the list are great – for the employer, that is.  That’s because you don’t want a person like that on your team.  If they’ll quit because they can’t get up in the morning or there’s a must-see sporting event one day, then you can live without that person.  Reasons for quitting tell you a lot about a person.  It’s a window into their true character.

But wait a minute…  You want to know their character before you hire them.  Oh, yeah…

The time to test a person’s character is before you add them to your project team – during the interview and selection process.  That means you must either be a really good judge of character, or use a test to weed out the deadbeats.

During my career, employers have used multiple interviewers.  On “interview day” you go from office to office talking to a half dozen team members.  Those team members report back to the HR department with a score, and anecdotal feelings about your “team player” aptitude.  Of course, prospective employees are on their best behavior during such sessions, so you can’t get any dirt on them.  But if your team members are each good judges of character, you’ll have a good idea what you’re dealing with.

One employer put me in from of an impossible-to-finish test.  They said I had two hours to compete it, and that I should answer as many questions as I could.  Problem is, the test would take any normal person four hours to complete.  So what’s a guy to do?  Rush through it, scribbling down answers as fast ask you can?  Or take it slow and easy, answering only the ones you know you’ll get right?  Clearly this was a trick test to see how a person reacts when given too much work to complete in a given time period.  Will they make a big mess of the job by rushing?  Or are the smooth and level-headed.  A test like this will reveal their true character.

Another idea is to take them out to lunch and gang up on them.  See how they react in different settings.  What comes out of their mouth when they aren’t guarding it so closely?  Ask them to gossip about the worst boss they ever had.  Do they take the bait and spill their guts?  Or do they say all their bosses were saints?  You could ask them to rat out their worse coworker.  Same trick…  Do they partake in vicious gossip about their previous workplace?  If so, it tells you that they’ll do the same at your company.  They may even say similar things about you.  Or they may walk off the job to join a rock band!

Posted on

Engineering Begins with Prototypes

I was talking with a senior software developer last week about the importance of early prototypes to define products. We concluded that it is pointless to begin developing any real architecture or engineering until the prototypes are finished and signed off. You must put your ideas into tangible form before you can trust them to the discipline of engineering. And customers must see examples of the finished product before you can move forward with deep development. Here’s why:

Under-the-hood engineering depends entirely on what you plan to sell. Notice I did not say what the developers thing might be cool or trendy. It’s what you plan to sell. Period. It doesn’t matter if you are selling transmissions or skyscrapers or operating systems; you have to know what the customer wants before you can build the most efficient version of that. Just try to dream it all up alone on a deserted island – without any input – without customers telling you what they will pay for and what they will not. That’s a lot like what you’d get if the developers in their Tommy Bahamas island shirts said, Oh, yeah! That’s so cool. Let’s make that!

Prototype Prototype

Take the automobile transmission for example. If you designed it on a deserted island, and sent the designs straight into production, the risks would be enormous. The finished product would likely have extra gears, “cool” new ideas, and “special” modes that the customer never asked for. And won’t pay for. All those extras make the product less efficient, more costly to manufacture, and more costly to maintain. You probably can’t afford that. Only the most efficient and cost effect designs survive. In other words, only what the customer asked for – nothing more.

Sure, you can get creative and throw in some extras. I call that “programmer candy.” The product doesn’t have to be a total bore. But make sure your core competencies are taken care of first.

 

Prototype

 

Also, it should be understood that prototypes can rarely be morphed into shipping products. (Managers don’t get that.) They are usually throw-away models, so expect to add that extra time to your overall project schedule. For instance, take the old clay automobile models as an extreme example. Remember them from the 1950’s? Even after sanded and painted, they still couldn’t serve as production automobiles. It’s almost humorous to imagine. But still, it has always been a strong desire in engineering circles to go from prototype to shipping product with the stroke of the pen. After all, the prototype looks so real, why not just clean it up and ship it! That’s what the manager usually ask for. Actually, that goal is not far off in computer-aided design, like software development, because editing is so easy. Not so with clay models.

Posted on

That’s Where Experience Comes In

Recently, I overheard a senior project team member reminding a junior software developer to make sure his code built and could be checked in every day. He reminded the junior coder that we now have more coders on the project, and that leaving files checked out for multiple days put others in a difficult position. They could not get his changes until he checked it in, and long delays held up forward progress of the project.

That conversation got me thinking about all the little things you learn throughout the years. Here are some more to consider.
A few things experience has taught me:
• Check your code in often
• Don’t go dark for long periods of time
• Make yourself accessible
• Research everything you don’t know the meaning of
• Try new things
• Don’t get locked into legacy products
• Upgrade your development environment often
• Get a new development machine every three years
• Network with team members
• Answer every email you get, and in timely manner
• Get on Skype
• Blog often
• Re-read your emails before sending
• Let no bug survive
• Don’t be an obstruction to others
• Clear obstructions for those who work with you
• Take a vocabulary class
• Use good grammar and punctuation, not IM slang
• Decline unproductive meetings
• Produce a lot of code
• Design before you code
• Get peer feedback
• Learn to spell
• Work on communication skills
• Make a lot of friends

Got something to add? Become a contributor and add your comments below. I’d love to hear them!

Posted on

Overtime: The Devil’s In The Details

I keep running into the same old product development story: All the developers meet for a status update to compare with the project schedule (and this isn’t just a fault of project schedules… it happens with scrum stories as well) but the engineers are just a little behind schedule. Gee, what’s new? They all have just a few more tasks to complete their stories, just a few more details… And that goes on and on and on… It’s enough to shake my faith in project management methodologies. Not enough to shake my faith in the project team, just the narrow ruts we find ourselves channeled into. It’s the same old story. The program manger doesn’t have a full grasp of the detail that team members must face to complete their tasks. In fact, you can’t know that level of detail until you are the one doing the tasks. And sure enough, every one has 50 – 100% more detail than initially scheduled for. So… the schedule blown, and everybody is in trouble. And working overtime. Who made that up? Okay, I complete get that companies have to fight hard for an advantage. Overtime is a necessity just to survive sometimes. If you don’t do it, you shrink back into oblivion. So yes, overtime is good. But I’m not sure I like how it’s arrived upon. It’s always “our” fault because we haven’t completed our tasks, so there’s a mad scramble to complete the project on time. Overtime is never pitched as something good for the species. Or necessary for survival. Instead, it’s simply because we haven’t competed our tasks in a timely manner. Ooo, gosh.  I guess I’ve been complaining, huh?  🙂

Posted on

Timesheet Administrators: Lock Your Timesheets Quick!

Have you ever locked your company timesheet when the week or pay period is over? If not, you’re probably wondering what for? Why lock an employee timesheet? Or you might be wondering how to do it at all.
Locking employee timesheets is done for two primary reasons: payroll and client billing.

First, payroll: If you use your timesheet hours to pay employees, those hours must be verified and deemed correct before entering them into payroll. Nobody wants to be shorted just because they missed a few daily entries, but it happens. You also don’t want to pay crafty employees twice what they should get, just because they entered 80 hours in for the week. Again, you’ve got to verify and certify before timesheet hours go to payroll.

But what happens if an employee makes a change after the hours have gone to payroll? For instance, they realize later that they actually worked a few hours overtime. Understandably, they want to be paid for those hours. But they may not know you have already cut the check. So they innocently enter the extra overtime hours, and nobody notices! The check was already cut before they entered them. Yikes!

Locking all the employee timesheets before you cut checks is the only safe solution.

In the example above, the employee would not be able to enter his overtime hours for the previous pay period because it was already being processed. Lock it down and they can’t enter any additional hours. Of course, they’ll come back screaming, but at least you won’t miss the hours. Just tell them to enter the hours for next week and they’ll get paid for them in the next check.

Second, client billing: It’s the same issue as payroll above. Employees who enter time for the purposes of billing clients may not know the exact time you cut an invoice. The scenario is the same: The Accounts Receivables department cuts an invoice for the previous month’s work… and then a day later one of the employees working on that project enters some additional hours – AFTER the invoice was already cut!

That’s a bad situation!

The Accounts Receivables department doesn’t realize that more time was added to this invoice date range, and, the employee doesn’t realize that the invoice has already been cut. So the billable hours he entered are effectively lost. Sure, they are in the system, but nobody knows they should be included on an invoice.

Oops!

Again, the safest solution is to lock the invoice date range before cutting an invoice. This prevents any new hours from being entered. Employees will get an error and realize they should put the hours into the next pay period instead.

Try locking your timesheets, if you deal with payroll or client billing!

Posted on

Give it to a busy person

Here’s an old saying, “If you want something done, give it to a busy person.”  There is a particular commonality among busy people: they complete an astonishing number of tasks each day.

Busy people feel they have to complete each and every task given to them.  Plus, they feel they need to do every one of them well.  Nothing is half-baked.  No detail is too small.  But to a busy person, all that work is not a burden, it’s an investment.  But still, they sometimes feel overwhelmed but keep motoring on day after day, doubling the number of tasks that normal people complete.  They rarely wait for someone to tell them to do a task twice, or even once for that matter.

I’ve noticed that busy people even walk faster than normal people.  They seem to be on a mission everywhere they go, even to and from work.  They drive faster and rarely make “quick stops” along the way.  They never say, “I’ll just be two minutes,” which has become a popular saying of the non-busy people of the world, because it’s never really just two minutes is it?

I admire busy people, and enjoy studying them, especially in the project management setting.  You don’t see them in meetings like the non-busy people.  Instead, they’re heads-down or jetting off to the next task.  That’s a discipline few possess, including myself.

Bottom line: if you don’t have a busy person to emulate, try becoming one yourself; someone might being to emulate you.  Prioritize everything, all the time.  Complete every task.  Grind out the details that most people gloss over.  Get a whole day’s work done by 10 AM, and then look for something else to do.  You might just find that the busy life suits you!

 

–newshirt

�

Posted on

No Vacancy

Have you ever dealt with a department manager who claims they have no resource capacity for strategic company projects, yet seems to be under allocated?

You suspect the department of using precious company resources on “secondary projects” with no strategic value, but you can’t prove it.  Either you don’t have tools to track what your departments do, or that department has successfully hidden manpower for their own use… or both.

Probably the first step is a good heart-to-heart company meeting.  All the functional managers should know the necessity and value of strategic company projects.  But how can you know they understand and support you?  Know your people…  That’s the only way.

The next step is to implement a tool that clearly defines the percentage of time expected on key projects, and tracks actual work against them.  This is a supply and demand system.  Such a tool gives you the opportunity to enforce the message in step one, above.  Employees and department timesheets (supply) should track closely to the numbers they’ve agreed upon (demand).  If they don’t, you’ll have a hot topic of conversation ahead.

Posted on

Project Portfolio Management 2

I’ll take the liberty to build on Warren’s Project Portfolio Management post below.  Hope he doesn’t mind!  It’s a great post, but the images below could help solidify the usefulness of project portfolios.  See the Project Portfolio YouTube video here.

There is a wonderful Timesheet software product named Standard Time® that handles project portfolios nicely.  The screenshots below are from it. Standard Time lets you see forecasted revenue for a selected project portfolio.  It also lets you see future task allocations and employee availability for a selected portfolio.  That’s powerful!

 

 

Here you see a project portfolio chosen from the dropdown list at the top-left.  The chart at the bottom forecasts the future revenue from all the projects in that portfolio.  This lets you compare one portfolio to another and focus on the profitable ones, and ditch the rest.

 

 

This screenshot shows project resource allocation for a selected project portfolio.  In other words, you see when your employees are scheduled to work on the projects in that portfolio.  The program takes all the projects in that portfolio, and then checks to see when employees are working on them.  If you decide to postpone a portfolio, you’ll see where you can pick up some extra resources.

 

–newshirt

Posted on

Great Product Features Have Solid Business Case

For our company, great features rarely come from high-octane project brainstorming sessions where the heavens open to reveal the glory of God.  Instead, they come from lowly customers here on earth.

Here’s how it happens:

A customer calls up and says, “Why is your product so lame?  Why doesn’t it do such-and-such?”

“That’s none of your business!” cries an eavesdropping passerby.

Oops, no.  Not the correct response.  Instead I ask, “How would you like it to work?”

Nine times out of ten that question turns into a great new feature.  We discuss the business case and work out an alteration that fits the common usage much better.  Customer is happy; we’re happy.  Now we just need to sell it to the executive management and development team.
Why is this exchange so valuable?  Because it comes from an actual customer with little vested interest in the product.  They just want it to work better so they can get their work done faster.

BINGO!!!

That’s the key.  Anytime you can reduce admin time or improve product usage, everyone wins.  Nobody likes a hard product.  Dreaming up great new features in a boardroom rarely accomplishes those basic goals.  Talking to customers is where it comes from.

Problem is, who’s talking to customers?  Tech support, sales, and maybe a marketing hopeful willing to mingle with the great unwashed.  These are the lowlife employees nobody listens to.  So how does the customer need get filtered up the channel to executives and then back down to the development team?

Give them a database.  Let them submit feedback from the trenches.  If they can articulate the business need clearly and effectively, people will listen.  The best features always come from customers.

Posted on

Reach out to new kids

I remember my first software development job in 1992.  I joined a software company that developed for the “new” Windows operating system: Windows 3.0.

As a junior member of the team, I was deathly afraid of revealing what I didn’t know and lose my coveted new job.  I was sure everyone on the team knew more than I.  So worked 72 hour weeks to catch up.  I studied, and coded, and watched, and listened, and tried to fit in as best I could.  It worked perfectly!  But it turned out I wasn’t the only newbie, and I learned that I knew more than I thought.

So now as a project manager, I’m sympathetic to newbies.  No newbie will lose his job just because he hasn’t been immersed in the latest technologies.  Reach out to the “new kids!”