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

Define: Fixed Duration, Fixed Units, Fixed Work

Fixed Duration: The task calendar ‘Duration’ will not change when you change the ‘Work’ or add resources.

Fixed Units: The resource percentage of work will not change when you change the task ‘Duration’ or ‘Work’ hours.
Fixed Work: The ‘Work’ hours will not change when you change the ‘Duration’ or percentage of resource work.

Double-click on a Microsoft Project task to display the dialog box below. The field we’re describing is highlighted below: ‘Task type’.

Task Properties

The default setting for ‘Task type’ is Fixed Units. That means the percentage of resource work (Example: “Buzz[50%]”) doesn’t change when you enter a new number for the work hours. For instance, if Buzz is set to work 50% of his time, changing the amount of work won’t change that. He will still work 50% of his time.

Changing the ‘Task type’ to Fixed Duration causes the Duration field to not change when you enter ‘Work’ hours.

Changing the ‘Task type’ to Fixed Work means that the Work field won’t change when you update the other two fields.

Posted on

False Front Prototypes

When you watch the old Westerns like ‘3-10 To Yuma’ you are usually treated to a Main Street with old-time businesses and homes on it. Horse drawn wagons lumber by. Victorian dress is on full display. A child taps an iron barrel ring down the dusty street with a stick. There’s the obligatory livery station, bank, gunsmith and hardware store, and cobbler. They all sport a nice tall false front, as the turn of the Century buildings often did. It’s exactly like “real life” in 1880.

But what you don’t see is the backs of those buildings. The Hollywood cameraman never goes back there. Guess what? There’s nothing back there! The buildings are literally just false fronts. You couldn’t actually live in one of those houses or do business in one of those stores. Sure, there are a few sets where you see characters going into and out of those businesses, but those movie sets may be in a completely different sound stage. Nothing is as it seems; it’s all staged for the camera.

Got your attention? Now consider how this happens in engineering…

In engineering, we build prototypes to help people see what a finished product will look like. What people? Customers, potential investors, buyers, company executives, project stakeholders. Everyone needs an idea what a product will look like when the engineering is complete. It gets everyone on the same page, and dispels misunderstandings. Sure, the prototypes have a few warts. It can have reduced functionality, but it must *look* like the finished product, and must allow the sales force to tell the story and make the sale.

The problem with these prototypes is that they have almost none of the proper engineering – much like a Western movie set. Sure, they look good, and may even appear to work. For the purposes of a First Look, they satisfy everyone curiosity and need to see something tangible, and they get everyone thinking in the same vein. But they may not have any of the correct functionality! That fact alone leads to a false sense of completion.

Project managers, engineers, project stakeholders, and everyone alike can be lulled into a false belief that these systems are just a step away from completion. In actuality, they are like false front Western movie sets. You could never consider actually using them for everyday purposes. But after looking at them for an extended period of time, you come to a false belief that you could. You forget how far they are from reality.

It’s that “one step to final product” illusion that gets everyone into trouble — especially the engineers. They are the ones tasked with readying the product for release. Everyone around them believes the product is almost there – almost finished. But it’s not. The stakeholders have big money riding on a swift move from prototype to production. Customer expectations have been set, and they are waiting – sometimes not so patiently. Problem is, there is no swift move. The prototype must be thrown away and the “real” engineering begins. It’s like throwing away the Hollywood false front hardware store and building a real one. You can’t just build onto the false cardboard buildings. They have none of the real factors that go into a real building. Real hardware stores are expensive! And they take a long time to build! They are nothing like the quickie cardboard movie sets.

�

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

Failure, ouch…

Failure is simply the opportunity to begin again, this time more intelligently.
    — Henry Ford

 

These are not from Henry:

Project failure is a luxury few can afford.  Multiple failures can bankrupt you.  See that they don’t…

It really is true that project failure is an opportunity to redesign and restart.  If you think about it… why do projects fail in the first place?  They fail because of some huge flaw that nobody recognized at the outset (or that the stakeholders ignored).

So starting over with those flaws corrected is what Henry is talking about.

There were 13 years of development leading up to the Model T.  (1896 – 1909)  There was another 18 years of development that lead up to the Model A.  (1909 – 1927)  That’s a lot of failure!

But think about it… it’s also a lot of success!

Posted on

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.

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

Hook a Timesheet to MS Project

PMO’s and project managers, have you ever considered hooking a timesheet to your MS Project MPP file? You spend a good deal of time pouring over your MS Project files, scheduling tasks, and assigning hours, but are you ignoring the ‘Actual Work’ field?

Do you have an automated way to input actual work?

Hooking a timesheet to the Actual Work field turns your static project schedule into a living, breathing document. You’re now releasing the beast into the wild, and you might be surprised at what it turns into! What, exactly, does that mean to release the schedule into the wild? It means letting employees enter their own actual work against their own tasks. It means hooking a timesheet to your project schedule. See this timesheet program for an example.

 

Getting actual working hours from employees might completely surprise you. Many project managers are uncertain how long tasks take. They have a good intellectual guess, or even some estimates from the actual engineers on the ground, but actual hours from employees can be a huge eye-opener. They are almost never what you expect. Project tasks often double or triple from their initial baseline estimate. No kidding! And when that begins to happen on a regular basis, panic sets in! You now have to either rein back your initial proposal or force employees to be more efficient.

See what I mean by setting the beast lose in the wild?

When engineers blow past your estimates, or even their own, they have no particular malice in mind. They are just doing their jobs. They may have no idea how those bloated task hours fit into a larger picture, or how they may affect a static project schedule. Again, they are just doing their jobs to the best of their abilities. And if that means a little extra work, then so be it. Problem is, stakeholders and project managers are freaking out as the schedule blows up. I once heard a manager say, “At this rate, we can only do a quarter of what we hoped.” That’s project management panic!

So back to hooking a timesheet to your MPP file… Sure, panic may set in for a while. You may need to rethink your plan. But you’ll be much more educated than if you had left the schedule in an “open loop” system without actual hours from employees. Ignorance is bliss!

A timesheet is the best thing ever invented for a project plan. They are so closely related, they should be in the same package! Fortunately, with this timesheet app, they are. In fact, you don’t even need MS Project. You can create your own project schedules with full hierarchy and project tasks, and then track time to them. You’ll instantly compare estimates with actuals, and avert most of the panic associated with a blown schedule.

Getting “Actual Work” feedback early is the best answer to project management panic!

Posted on

Three Reasons to Track Project Time

Time tracking, for the purposes of project management, is an overhead some companies are not willing to undertake.  (Read this as an exploitable mistake!)  We all know that some level of administrative overhead is necessary to maintain a healthy organization.  And some level of process or methodology is also necessary.  In this article, I’m suggesting that time tracking should be part of that process.

There are three primary reasons to track project time that apply to all organizations.  It matters nothing whether your company is a consultancy, manufacturer, government agency, non-profit, or otherwise.  Time tracking is valuable to all.  Here are the top three reasons to track project time.   1) Reduce budget overruns, 2) Prioritize projects, and 3) Learn your own business.

I’ll discuss these three project tracking benefits in detail.  Feel free to skip to the ones that interest you most.

1) Reduce Budget Overruns
Human beings are curiously bad with two things: time and money.  A huge number of cottage industries are built around helping people manage time and money.  Why?  Because almost every one of us does it badly.  Admit it… your bank account scrapes bottom almost every month.  And you’re late for at least one event per month.  That’s so easy to predict, I don’t even have to know you to feel confident in its reach.  Everyone suffers from the same poor time and financial accounting.

Unfortunately, we carry those same poor principles into our work life.  I’ll venture to guess that your boss, and his boss above him, is also a poor manager of his personal time and money.  Just because he’s a boss, doesn’t mean he’s any better at time management, or money management, than you are.  We’re all crap.

But if you’ll just subject yourself to a little time tracking discipline, you can avert the most common budget overruns.  It’s the low-hanging fruit you’ve heard so much about.  Just track the time you spend.  That time translates into salaries.  Now you know the project cost.  Don’t spend more than you take in.  Simple.

I know a great time tracking product for this.  It’s named Standard Time.  Click here for Timesheet and Time Tracking Software.  You can install this on everyone’s workstations, and start tracking project time.
You’ll see why it’s important in the next two reasons to track time.

2) Prioritize Projects
Instinctively, you know which projects are strategically important to your company.  You know which ones represent a strategic investment that will pay off big-time in the future.  Even the lowest employee knows that.  (Although it’s the company executives that should enforce the participation in such projects.)  So, are they doing that?  Are you doing that?  (Hint: if you’re a low or mid-level manager, here’s your chance to advance:  Talk “strategic projects” at every meeting.)

“Secondary projects” are nice to do when you’ve got time and money to burn.  Have you got time and money to burn?  If not, you must focus on the strategic projects.  They’re the only ones that make money and keep people employed.  And how, exactly, do you do that?  You track time to them!

Collect all your hours for every project you work on, and then run a report that shows you which projects are getting the most time.  You might be surprised!  Even better, categorized your projects as “strategic” and “non-strategic” and run the report again.  Which category is getting the most time?  Are you surprised yet?

If you’ve already downloaded Standard Time (see link above), you can get all these reports for free.

3) Learn Your Own Business
Last thing: learn your own business (LYOB).  It takes 2 -3 years to really learn a business.  You may have a good guess within your first six months of employment, but you won’t truly know it for another two years!  Tracking your project time chops a year off that.  Here’s why:

When you track time to company projects, you learn what makes them efficient, and what makes them inefficient.  You learn the gritty details because you see everything that goes into the work you do.  My advice: pour over the descriptions in every time log entered by every employee.  Submit yourself to the excruciating pain of studying these details.  You’ll perfectly hate it!

But even as you hate it, you’ll love it.  You’ll become an expert on your business and will soon have the information you need to make improvements.  Time tracking provides the information you need.

Best Time Tracking Program

Posted on

Task Drivers

Microsoft Project as a simple method to find out which tasks are driving the ‘Start Date’ for a selected task. These are called “Task Drivers.” In other words, predecessor tasks that affect successor tasks.

Here’s how to find the task driver for a selected task:
    1. Click on any task that has predecessors
    2. Click in the “Track” menu button in the tool bar
    3. Choose “See what is driving the start date of a task”
    4. A panel appears at the left, showing the tasks that drive the selected on

 

 

Here, you can see that “Task 1a” drives “Task 2”, even though “Task 1b” is also a predecessor.  Task 1a is a “Task Driver” to Task 2.