Project Team Blog

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!

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.

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.

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

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!

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’.

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.

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.

�

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? 

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!

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.

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!

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!

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

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.

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

�

That is the question…to cloud, or not to cloud?  I recently read an article by Sarah Fister Gale, found here: http://www.pmi.org/~/media/PDF/Publications/PMN0312%20cloud.ashx
It is interesting how many people go to the cloud without knowledge of security, back-up, redundancy, and so forth.  There is little doubt that the cloud has many positive attributes.  That is why cloud usage continues to experience robust growth.  However, too often people just assume the cloud is a magical solution with hardly any issues.  Well, that is normally the case…unless you happen to be my brother-in-law.  His company was utilizing a cloud hosted credit card processing service.  And things were great for nearly two years, until the cloud server went down and there was no back-up plan in place.  It took 3 days of hand wringing and lost sales to get back online.  In addition to immediate lost revenue, he lost long term customers.  The article above will certainly give you an idea on specific questions one should ask and a basic outline to help you make a solid choice for your cloud solutions.

�

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?

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!

Work Contour: The distribution (or “shape”) of working hours over the duration of a task.

In Microsoft Project, working hours are not always spread across the duration of a task like peanut butter.  In other words, they don’t have to be evenly distributed.  They can front-loaded so that most of the work is performed at the beginning of the task.  Or, they could be back-loaded, to represent most of the work being performed at the end of the task.  In fact, there are several choices for the Work Contour.

Here they are:

1. Flat
2. Back-loaded
3. Front-loaded
4. Double peak
5. Early peak
6. Late peak
7. Bell
8. Turtle

The images below illustrate how to choose the Work Contour for each resource in each task.

First, choose View, Gantt Chart to create tasks and assign resources to them.  Then set the duration.

Next, choose View, Task Usage.  Insert the ‘Work Contour” column.  After choosing various contours for each resource, you will see an icon representing the distribution of hours across the task.  Notice how the front-loaded task has most of the hour distributed in the first few days while the back-loaded contour has them distributed at the final days.  Flat distribution is default.  It simply uses the resource schedule.

You can’t build a reputation on what you are going to do.

  — Henry Ford

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 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.

Planning to take the Project Management Professional (PMP) exam from Project Management Institute? Excellent move! That’s just the right medicine for today’s tight economy. You might even find that your position depends upon it. I hope that’s not true, but I’ve seen it happen.

I found an interesting way to prep for the PMP exam plus get a working knowledge of the language and terminology used in the PMP exam. There’s a North Carolina-based company with PMP and Agile instructors that set up classroom sessions around the country: ASPE-SDLC training. Of course, they also have online classes. You can contact them at http://www.aspe-sdlc.com/ and see the PMP Boot Camp class at http://www.aspe-sdlc.com/courses/pmp-boot-camp/.

I’m considering taking the class to sharpen up my own seat-of-the-pants PM skills. If I do, I’ll blog the daily experience here on Project Team Blog. You hear all the ‘torture’ I’ve been subject to.  But you’ll also get an honest day-by-day account of the course. After all that, you might consider taking the course yourself.

Stay tuned!

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.

Project Baseline: A copy of the project tasks as they were at some point in time, which you can refer to at a later date.

Here is an example of two project tasks immediately after setting the project baseline.  Notice that the ‘Baseline 1 Work’ field has been copied from the ‘Work’ field.  As the ‘Work’ field changes throughout the project, the baseline is still available for comparison.  How did we do this?  Easy.  Just choose Tools, Tracking, Set Baseline within Microsoft Project.

Here we see the ‘Work’ field changed and the ‘Baseline’ unchanged.

Want an easier solution?
Baselining can be complicated and confusing, so “Sir Ganttalot” (a YouTube celebrity) has come up with an easy alternative.  Click here to see the YouTube video:

http://www.youtube.com/watch?v=c7BJ6%5F1pcgc

Essentially, Ganttalot creates a customized field named “Finish Date Changed” to identify tasks that have changed.  Graphical arrow indicators tell whether a finish date has slipped in the future or has tightened up.  These graphical indicators are easier to spot than comparing textual finish dates to baseline finish dates.  It shows you at-a-glance what’s changed from week to week.  Slick, I’d say!

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!

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

Project portfolios are helpful for grouping work and managing projects individually and as a whole. Many companies start out not utilizing project portfolios. Then, as the company grows projects become unmanageable and the need for project portfolio management becomes clearer. Portfolio management helps companies maintain efficiency and breaks project work load into manageable pieces. It is vital that whatever project management software you utilize, be sure it is scalable to include project portfolios. It is likely you will need it! There is way too much to cover in this short blog. However, a pretty good white paper can be found from Mosaic Project Services at the link below.

http://www.mosaicprojects.com.au/WhitePapers/wp1017_portfolios.pdf

Task Status: In Microsoft Project, the task status field represents the current state of each task.

The illustration below shows all the possible task states: Future Task, Late, On Schedule, and Complete.

How do tasks get into these states?
    1. Future Task:  When the task ‘Start’ date is in the future.
    2. Late: When the completed hours are less than what they should be by today.
    3. On Schedule: When the completed hours are >= to what they should be today.
    4. Complete: When the percent complete is 100%.

One of the more recognized terms in any business is Paralysis by Analysis…or Analysis Paralysis. You know, when nothing moves forward because too many people have to buy off on an idea, or a single person is the team lead and afraid to jump in with both feet. Well, I believe one way to identify Analysis Paralysis is to look for the most common symptom…pathological cases/scenarios. This is easy to spot. When “what ifs”, that are highly unlikely continue to pop up, then you can get stuck in the “what if” cycle, causing Paralysis by Analysis. These pathological cases have a sliver of possibility but cause an overwhelming fear for the project team. Then you’re off trying to plan or prevent the impossible. I have seen this happen many times and more often than you may think. Project leaders and team members can easily become myopic when focusing on their work. In my experience the best way to tackle pathological cases is head on. Politics is one thing, but a never ending project is another.

I understand the latest fad in management styles is the collaborative process. Part of the collaborative process is encouraging multiple people to arrive at a decision as a unit, or on behalf of the unit – where, in times past, there was a “buck stops here” person. Now there is a buck stops here, over there and just about anywhere group of people. While the collaborative process has a place and is effective in many scenarios, it is dangerous when it bleeds over into a non-collaborative project structure. I’m not saying project teams shouldn’t work together to collaborate and solve issues. In fact, just the opposite! Project teams are a TEAM by definition, working together towards a common goal. However, with a younger generation being taught the collaborative process so heavily, it can cause issues when they veer out of their lane and bypass a structural hierarchy or chain of command. The collaborative process is great until a person makes a decision without actually collaborating with the person/persons responsible for that particular area of concern. By the time the “true decision maker” finds out, the decision has been made, announced and partially implemented. Now we have a real mess. Collaborate on that!

I’ve recently been made aware of another method of resource allocation.  I’ll throw it out here to see what project managers think.  It’s a simpler method than the traditional task-based resource allocation.

Before getting into that, I’ll briefly describe the resource allocation method I am most familiar with.  In this method, resources are assigned to project tasks that have clearly defined durations and remaining hours. 

The tasks may also have starting and finish dates.  The resource allocation algorithm spreads the remaining task hours over the date range defined by the task.  If you have too many tasks, you are over-allocated.  Too few, and you are under-allocated.

The simpler method I became aware of doesn’t use tasks.  It also doesn’t use start and finish dates.  Projects are assumed to continue forever, and resources are assigned a percentage of their daily scheduled hours.  That’s it, nothing else.

In the simpler method, resources are over-allocated when they are assigned to so many projects that their daily hours are exhausted.  They are under-allocated when there are still a few hours left in their day.

Timephased: Total project task hours distributed over a period of time.

An example from Microsoft Project of this is shown below.  The hours for each project task are distributed over the duration of each task.  The hours per day is the ‘Work’ field divided by ‘Duration’ field.  In other words, the total work is spread evenly over the duration.  Choose the Microsoft Project views below to see these task layouts.

Tracking Gantt View:
 

Task Usage View:
 

You can see that the 100 hours are timephased over 10 days for the first task, and over 1 day on the second task.

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.