YouTube Video: Consulting Software

This YouTube video for consulting software is pretty neat. It covers a lot of ground in five minutes, and is worth taking a look at. Amateur, but neat. The premise starts with a timesheet and closely related time log view where consulting hours are displayed. Of course, the timesheet is a typical Monday thru Friday grid with client projects on the left. Things got cooler with the time log ivew. The time log displays the same records as the time sheet, but in a top-to-bottom view.

Consultants will drool over this. Trust me.

For every time log record (which is also displayed in the timesheet) you get a client field, project, category, start and end times, actual work field, client rate, client cost, billable, and billed columns. There are other columns not shown that can be added to this view. Plus, you can filter that time log view to show only the work you did for a certain client or project, or only the work for a selected consultant. Or only work for a selected date range. That’s slick! You can also filter out the non-billable records and only see what is billable to the client.

But this is only where the app just begins…

The video goes on to show a glimpse of the billing rates window. (Wish it showed more.) It seems that you can set the billing rates for each consultant, and for each project they work on. So every consultant has his own rates for every project. And they only see the project they work on. Nice. But again, the video is brief, so you have to check this out for yourself – it’s just a five minute overview.

If time tracking is not enough, there is a menu item to show project revenue over a 12-month timeframe. This lets you see trends for the coming months and identify bad months that require attention. If only it also showed historical results for the last 12 months… That would be cool, but probably not as useful. Every project has its own win/loss percentage projections so it acts like a sales funnel. But all that’s a side issue that consulting companies get for free. Sure, you’ll use it, but the real stuff is logging billable hours.

The video sticks right to the point: client receivables and consultant utilization rates. That’s is the heart and soul of consulting. Get those wrong and you fail. So those reports let you see where your money is coming from, and what your effective billing rate really is. In other words, how much is your organization is billing for the work it does. Reports like this naturally raise the question, “How to increase your effective billing rate?” Edging out small increases is what consulting is all about. If you spend too much time on non-billable or in-house jobs, you die. If your effective billing rate is too low, you die. If you don’t book gigs, you die. If you don’t invoice billable hours, you die. This program seems to get that.

What is not mentioned in this video is equally valuable: expense tracking, client invoicing and QuickBooks integration. Yes, the product has those things, but the video fails to highlight them. Why? Not enough time, I suppose… I’m not sure. But it’s nice to know that there’s more to this product than the basics that can fit in a 5-minute video. Definitely worth a look.

Check it out: Consulting Software

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!

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?  🙂

Task Lingering: Employees Avoid the Unfamiliar

Actually, not just employees… Everybody avoids the unfamiliar. But this post is about employees, and specifically project team members that engineer or develop new technologies. It’s about how employees sometimes try to settle into familiar tasks and avoid new and unfamiliar ones. And it’s about how to prevent that.

But wait… why prevent it? Isn’t efficiency gained by perfecting the familiar? By polishing your craft so you can perform it virtually without thought?

Yes, but this isn’t really about that. It’s about the propensity of employees to spend too much time on project tasks they have become familiar and comfortable with, to the exclusion of those upcoming tasks they dread the thought of.

I’ve heard reports of engineers racking up 200 – 500% extra time on tasks that could have been completed at the estimated time. Here’s the reason: people become comfortable with tasks they’ve spent significant time on and don’t want to leave them. The next task on their list may be unfamiliar and scary, so they stay on the one that doesn’t give off those vibes. The justification is that the current task could use some more polish.
Problem is, you’ve got to keep marching on. Your projects must be completed and delivered. You can’t afford to dally on project tasks you’ve already completed.

Here’s a technique you can use to discourage task lingerers. Set your timesheet “percent warning” to 75%. At that time, the task will begin reminding the employee that it’s time to move on. Of course, they may resist, but it’s a good reminder. Then set the “percent error” to go off at 125%. That stops team members from entering any more time. You can extend it with an administrator override, but at least you have some controls to monitor and manage task lingering.

Here’s a YouTube video that describes task lingering.

Presenteeism is the new Absenteeism

You can easily measure absenteeism in your project team.  Just count the number of days employees miss.  Bear down on them enough, and they’ll come in to work… like the walking dead.  That’s presenteeism. You are present, but not capable to work.  That’s the topic of a CIO Insight article at the link below.

http://www.cioinsight.com/c/a/IT-Management/Depression-at-Work-New-Initiative-Addresses-Lost-Productivity-663213/

 

Presenteeism is when your project team is half slaughtered by the stress and worry of everything around them – threats of layoff, political, economic, worldwide – yet they drag into work anyway.  Hey, it’s better to eke out a few hours of work than sit around on your duff, right?

I don’t suppose there’s any good answer to this. It is what it is.  We’re not living in a 1950’s ‘Leave It To Beaver’ sitcom anymore.  This decade is hardcore depressing.  Layoffs are happening all around us, businesses are failing, others are hanging on for an elusive economic uptick, but few are prospering.

My advice: just recognize this in your project team.  Be sympathetic.  Don’t bear down for more production.  Just try to be a pleasant manager if possible.  We’ll come out of it eventually. What else can we do?

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!

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.

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.

Ethics in Project Management

With all the pressures of managing a project, it is easy to be swayed and make poor decisions. Pressure can cause a person to rise to the occasion, or crumble in a pile of heap. Most often, however, a person may do things they thought impossible…cheat, lie, twist the data? Unfortunately, this happens more often than we would like. As a project leader it is important to maintain character and integrity. Short term gain based on any type of shenanigans will cause long term pain. For example, say you’re leading an IT project and your developers are having trouble meeting deadlines. You instruct them to “dump” a few outlying features…the customer won’t even notice or use that feature until long after we are done. It’s not a big deal. Two things are going to bite you, one is obvious, the other not so much. The obvious gotcha will come when the customer realizes you didn’t fulfill one of the expected features and becomes upset and makes some waves. The other less obvious problem, your team won’t trust or respect you. They see clearly how you manipulated the situation and trust is broken…even if they agree and would have cut corners too! Take the issues head on. Consult the customer on the scope and change and instruct your team accordingly. You may disappoint the customer now, but your project will keep integrity and your project team will respect your leadership.

Give Up Chocolate to Telecommute?

In the recent CIO Insight poll (see link below), 29% of the respondents say they’d give up chocolate to telecommute.  Yeah, right!  For how long?  17% said they’d give up a salary increase for telecommuting.  And 5% would even ditch the spouse.  Okay… that’s going a little too far.  But evidently, that’s what they said.  Check out the story here.

http://www.cioinsight.com/c/a/IT-Management/What-Your-Employees-Would-Give-Up-to-Telecommute-503693/

Evidently, people will do almost anything to work at home.

I can tell you from first-hand experience that the productivity boosts are enormous.  Focus comes so easily.  But only if you are self-motivated person with autonomous tasks.  Project team members with frequent ties to other employees can’t pull this off well.

There is also no substitute for face-to-face interaction.  Ten times the information passed between people when they look each other in the eye.  Information fidelity drops as you employ lessor communication tools like telephone, email, and finally the worst, text.  Even Morse code is faster than text, as Jay Leno demonstrated, but not by much.

But the upshot is, employees will give up almost anything to telecommute.  Just remember that, project managers!