A project management blog for manufacturing and engineering
What’s the difference between MS Project ‘Duration’ and ‘Work’ fields? The image below probably explains it all. It’s a simple task from Microsoft Project that shows both the ‘Duration’ and ‘Work’ columns.
As you can see ‘Duration’ defines the calendar time that the task will be worked on, while ‘Work’ defines the number of man-hours. In this case, Frank is scheduled to work only 40 hours over the next four weeks. That’s only 25% of his scheduled hours.
Percent Complete: The portion of a project task that has been finished. Calculated by dividing the duration by the actual work. In most cases, this the portion of the task with timesheet hours actually logged for.
Example: a 200-hour task with 50 hours logged is 25% complete.
Warren has been expounding on project management methodologies lately, so I figured I’d throw in with him. Consider this explanation of the ‘Waterfall project management model.’ It might be useful to some.
Here goes…
Why is the old project management model named ‘Waterfall?” What, exactly, does that mean?
I believe the term stems from the notion that water falling over a dam is hard to scoop back up to the top. Virtually impossible, one might argue. The term ‘herding cats’ comes to mind.
So how does that apply to project management?
In real life, some projects are like that. Not all, but some. Consider building a skyscraper, for example. You absolutely have to get that foundation right the first time, because you cannot go back and work on it after the ironworkers have laid a million tons of infrastructure on top of it. In other words, reworking the foundation would be as hard as scooping up water that has already fallen over the Hoover Dam.
But are all projects like that? How about software?
No.
Software is malleable. You can work on any part at any time, even after the product ships. So the Waterfall model doesn’t apply as neatly. Or at all. But it’s still applicable to certain projects where it’s hard to rework ‘foundational’ stages.
–newshirt
Make verses buy: The act of building a product for your own internal use as opposed to licensing a pre-existing product.
Organizations with the ability to produce their own products are often tempted to build everything, including the tools they use. This is most common with software companies. They have a bank of software developers, some sitting idle awaiting jobs, and the company is tempted to use those resources to build all the tools they use.
I once worked for a software company that wrote their own compilers and debuggers. For internal use only. Yikes! When Microsoft sells compilers for less than a thousand bucks, this doesn’t sound cost effective to me.
Again, the temptation usually stems from developers sitting around on their hands with nothing to do. Why not put them to work building internal tools? My opinion: bad idea – almost every time. Those developers are saving the company very, very little money. After all, off-the-shelf software is cheap. So, divide the number of hours they work by the cost of the software, and your developers are only making a dollar an hour. Better to put them to work in customer support or sales, cold calling for gigs.
The real killer comes when the software they wrote needs bug fixes and maintenance. Are those same developers still available? Usually not. So who pays for the bug fixes? You. Was it still cheaper to write your own stuff? I doubt it…
–newshirt
Effort driven scheduling: Calculating project task duration based on assigned resources.
When you assign resources to a project task in Microsoft Project, it recomputes the ‘Duration’ field. The screenshots below illustrate this. We’ll begin with plain tasks with no resource assignments. After creating the tasks, we’ll assign the first resource, and then all the rest. We’ll show that the ‘Duration’ column is changed when more resources are assigned.
Tasks with no resources assigned
Why does Microsoft Project recalculate the ‘Duration’ field when new resources are assigned? The ‘Duration’ column indicates the calendar time that will elapse as the task is being completed. That may be different than the ‘Work’. If more resources are added, the calendar duration will go down. That is effort-driven scheduling – based on employee effort.
One resource assigned
A magical thing happens when we assign multiple resources to tasks. Notice that the ‘Duration’ column is reduced to reflect the extra effort applied to the tasks. Since the tasks are effort-driven, they require less calendar time to complete.
Effort-driven task scheduling
–ray
Resource Allocation: The assignment of project tasks to employees over a specified time frame.
The chart below (taken from Standard Time®) shows an example of tasks allocated to one employee over three months. The blue bars are correctly allocated time. Yellow means there are not enough tasks, and red means there are too many.
So what does ‘correctly allocated time’ mean? It means that a project manager has lined up project tasks for an employee to work on, but has not given too many or too few. There are ‘just enough’ for the employee to complete in a given time. The 63 hour week below is as unworkable as the 10 hour week. Anything within 10% of a 40-hour week works.
Resource Allocation Chart
–ray
Feature Creep: Small product feature additions that unexpentantly expand a project scope.
Feature creep is one of the big reasons projects ship late. Some people simply cannot deny themselves. They want more and more features in their great new product, and can’t stop adding them Here’s how it happens.
When a new product feature is complete, there are oohs and aahs from all the project stakeholders. They love it! Why? Because they are sure customers will find it useful and reward the company with more business. That’s only natural. But then something else happens… One of the stakeholders steps up and says, “That’s cool, but can it do one more little thing?”
All the other stakeholders agree. The new feature you added is nice, but the product should do one more thing to be complete. And they may be right. So you add that. And a few more things. And a few more things after that. That’s feature creep.
Little additions creep into your product features until they consume a major part of the project timeframe. The extra features are nice, but can you afford the extra time? After all, you now have less time to implement all the other cool features you were asked to do.
Stakeholders often don’t understand this problem. Later, they’ll come around and ask why your project is behind schedule. You can’t say that it’s because of all the little things they asked for. Why? Because they won’t remember those or they don’t see them as a major time sink. See the problem? You can’t win with feature creep. 🙁
–ray
Project Milestone: A marker in time, usually indicating a the completion of a project task.
Project milestones offer a place in time to stop and analyze your progress. Have you completed the tasks you had planned? Is your project on track?
Project milestones are normally project tasks with zero-duration work. That is to say, no work is expected for such a task, except to stop and monitor your current progress. They often display in a Gantt chart with a diamond shape to indicate that stopping point.
Milestone task from Standard Time
–ray
Resource Utilization: Percentage of hours actually worked, when compared with possible working hours.
Formulas:
Utilization = ActualWork / TotalHours
EffectiveRate = ActualAmount / TotalHours
Standard Time® contains a resource utilization report that looks similar the to image below. Notice the ‘Scheduled Hours’ value, and the ‘Actual Hours’ under it. These number are used in the formula above to arrive at the ‘Utilization Percentage’ of 103.8%. This person obviously worked an extra 1.5 hours.
The effective billing rate is related to these numbers as well. In this case, the person worked on some high-value projects at caused his effective billing rate to be higher than normal. That’s a good thing!
–ray
Actual Work: Hours collected in a timesheet or with a timer indicating the total project hours an employee has actually worked.
Collecting actual work in a product like Standard Time® in important. It allows you to compare your original forecasts with the actual hours worked by employees. This can lead to some valuable metrics, including percent complete and estimation variance.
Assuming your original estimates are close, percent complete will tell you how far along the project is. This is obviously more valuable to project managers and executives who are slightly distanced from the day to day tasks. In some cases this can be their only indicator of the project status.
Refining your estimations can also be valuable, especially if your company performs the same projects over and over again. Only actual work can give you exact numbers, and that can lead to more profits.
–ray