Author: Nenad Trajkovski
Nenad Trajkovski, born in Zagreb in 1963, is an accomplished professional with a background in Electrical Engineering. With expertise in enterprise systems (ERP) development and implementation, he has served diverse sectors including banking, casinos, automotive, wholesale, and oil industries. Nenad excels in business process management, IT, and financial accounting. Currently, Nenad is a seasoned consultant and Project Manager, specializing in business systems implementation. He is also a respected trainer for Project Management and Risk Management at the Microsoft Innovation Center in Varaždin. Nenad's speaking engagements have earned him recognition, including being named the best speaker at WinDays08 and ranking among the top speakers at various Microsoft conferences. Nenad holds multiple certifications including Certified Accountant, PMP, PMI – RMP, MCP, MCTS – Microsoft Project 2010, and MCT.
Milestones:-Do We Need to Assign a Resource to Them in Microsoft Project?
There is a lot of discussion surrounding the question of resources being assigned to milestones using Microsoft Project. The answer to this question is (Isn’t it always?), “It depends.” The milestone is the checkpoint. Its main characteristic is that it has no duration (duration for a “classic” milestone is 0 (days, weeks, hours…). The best practice is that you should start a set of tasks with a summary task (to group them), and end the set of tasks with a milestone. Here is a simple example: As you can see, there are some tasks for writing the article, and they finish with the milestone which I called “Article done.” The duration for the milestone is 0 days. Each task, except the milestone, has an assigned resource. Now, before I start explaining when and why you should or shouldn’t have a resource assigned to a milestone, let’s take a look at what happens if I mark all tasks, except the milestone, 100% complete. As you can see if the milestone is not marked as completed, and all other tasks are, the summary task (in my case, the whole project) will only show as 99% finished. So, the milestone is 1%! As you know, when a resource is assigned to a task, it has some work effort. According to the magic formula, Work = Duration * Units. Typically, the purpose of a milestone is not to accomplish some work, but to close some phase (i.e. a set of tasks under the summary task) or to check if those tasks are really done. Let’s say that the editor is the resource who should sign the final review before my article can be published on MPUG’s site. If the editor has to read the whole article, and it will take several hours, then he/she likely needs to separate tasks with some effort, and, of course, duration. On the other hand, if he/she needs only to sign off and approve my article for publication and it will take only a moment, it makes sense to assign him/her to the milestone like this: Let me show you a more complicated project: As you can see in the scenario above, we have two summary tasks, and three milestones, one for each phase, as well as one milestone for the whole project. I assigned a resources to each milestone. This does not harm the project plan, or the work effort. To conclude, you would likely not assign resources to milestones if all tasks in a set leading to the milestone complete the list. In this case, the milestone is automatically considered completed when all the tasks have been, so only thing to do is mark the milestone as 100% done. On the other hand, if a responsible person needs to approve all the tasks in a set once they have been completed, he/she should be assigned to that milestone. Both approaches are correct. The last thing to consider is if the milestone involves some work, in which case it should have a duration. When you have a duration linked to a milestone, cost will occur. In a “classic” milestone, with zero work and duration, there are no costs.
Successfully Managing a Waterfall Project with Individual Work by Agile Teams.
As we all know, there are two general approaches or methodologies used for projects: Waterfall and Agile. Before I continue with an explanation of the differences between those two, let me emphasize one major and the biggest difference there is: The PLAN! Waterfall methodologies are plan driven. Everything is—or should be—known upfront. With a Waterfall project, the scope (what should be done), the time plan/schedule (when each activity will be done), the human resource plan (who should work on what and when), and the costs (how much each activity will cost) should be well defined before the project begins. As we all know, when it comes to IT projects, Waterfall methodology is not suitable. With this approach, a lot of change requests (changes to scope, time, and costs) arise, and there is always a problem with extending those three. This is Waterfall: Agile methodologies, on the other hand, follow more of a “plan as you go” model. There may be NO strong and fixed plan defined upfront. In fact, just the opposite is true. Plans are made for a short time period (up to one month), and only some parts of the project are planned at all (for that short time period). After that, the customer (or person who is the beneficiary of the project) can see what has been done, is it OK or not, and according to their judgement, can make further decisions on what is going to be done in the next (short) time period. Yes, Agile is better for IT projects. There is no question about that. This is Agile (Scrum to be more precise, as one of the most known methodologies within Agile project management): The major differences between Waterfall and Agile methodologies are listed below:
Finish to Finish/Start to Start Dependencies with Lag.
This tip explains Lag with Dependencies other than Finish to Start, like Finish to Finish and Start to Start, in Microsoft Project 2013. First we create a simple project: As you can see in the Predecessors field, Tasks 1 and 2 have a Finish To Finish (FF) relationship, and Tasks 3 and 4 have Start To Start (SS) Dependencies. Now, suppose that Task 2 and Task 4 have two days of lag: You get: Task 2 will have a finish date of August 4, 2015 and will start two days later, so its start date is postponed! When we repeat this for Task 4 we get: The same result! The point to remember is that, yes, you can have Lag (and Lead) in tasks with dependencies other than Finish to Start, but be aware of consequences!
About Adding Columns in Project 2013 Tables.
Somebody told me that he could add additional columns to some tables but not to all of them. He wondered if that was a bug. The answer is no, it’s not! Let me show you an example. Here’s a simple project: We can “Add New Column” in this table. Note that we’re using the Entry table. Next, we’ll choose the Cost table and get this: As you may notice, there’s no Add New Column here. To enable adding a new column, follow these steps. Choose “More Tables.” Specify “Show ‘Add New Column’ interface” and click OK: You’ll get this: To disable or enable (the default) adding a new column for some tables, edit the checkmark for each table.
Slack in Microsoft Project 2013.
You may be wondering why you can have individual items with slack in your schedule but then have total slack for the whole project show zero. Is there a way to show on your schedule how many days of slack you have for the entire project? The answer is complicated. First, some basics. Slack is the available time that a task can be delayed (or extended in Duration) without changing the project Finish date. Now, here’s how to work with slack in Project 2013. First, we’ll create a brand new Project and look at it in the Detailed Gantt View: As you can see, the project Start date is Tuesday, November 25, 2014 and the project Finish date is Wednesday, December 10, 2014. The total duration is 12 days. Why? Because Tasks 1, 2 and 3 are on the critical path! Critical path is the path on which if any task is delayed, the whole project will be delayed. Now let’s extend Duration for Task 3 from three days to eight days: That changes the Finish date to Wednesday, December 17, 2014. The total duration is 17 days. Notice that Tasks 4, 5 and 6 have 11 days of Total Slack! So if we extend, for example, duration for Task 4 from one day to seven days, we’ll get: You can see that Finish date is the same, but Total Slack time for tasks 4 through 6 is now five days. Task 7 still has 16 days of Total Slack. So why does the Project Summary Task (Task #0) show Total Slack as zero? Because Total Slack is not the sum of all slacks; it must be zero because on every project there is a critical path, and on the critical path, there is no slack! Because there is no slack, the Total Slack is zero. Now for the complication. In this example, what is Total Slack? Is it 16 days (because that’s the longest slack on Task 7)? Is it five days (because that’s what it is for Tasks 4 through 6?? Or is it 21 (the sum of those two slacks)? Or is it 31 (the sum of all slacks)? It doesn’t make sense at all to have Total Slack for the entire project to be different than zero.
Scheduling with Multinational Calendars.
Here is a question I received from one of my readers: “I’m managing a project for resources in multiple locations using MS Project 2007: US and 3 countries in Europe. I have multiple resource calendars to reflect the different countries. One (1) of my German resources started a task on Nov 28 which is a holiday for the US. When I attempt to change it to Nov 28th MS Project states that Nov. 28th is a non-working day; this is correct for US resources. However since Nov 28th is a working day for the German resource why is MS Project giving me this error. I understand that the standard calendar is used for the Project tasks, but how can I use the resource calendar assigned to the task versus the standard calendar?” I will answer this question using Project 2013, but the steps will be the same for Project 2007 as well. First, I’m going to create a brand new Project: Now suppose that in my project I have a guy from USA, and a guy from Germany. And suppose that in USA we have two holidays: one at Thursday, Jan 8th, and second at Monday, Jan 12th. I will create Calendar with name “USA Calendar”: and then: Forget about reoccurrence for a moment, it doesn’t matter in this Scenario. Now suppose that in Germany we have two holidays: one at Tuesday, Jan 13th, and second at Friday, Jan 16th. I will create another Calendar with name “Germany Calendar”, at the same way I did with USA Calendar. I will get: And now, I am going to create two Resources, John from USA, and Hans from Germany: As you can see, John has USA Calendar as Base Calendar, and Hans has Germany Calendar as Base Calendar. Finally I will assign both of them to my Task: As you can see, Duration is now 12 days. Let’s see at the Task Usage View: As you can see, John will not work at USA Holiday, and Hans at German’s Holidays. Both of them will work 80 hours per Task (because initial Duration was 10 days, and that means 10 days * 8 hours per day = 80 hours). But they will work according to they own Calendar. Hope this helps.
The Resume Fields in Project 2010 and 2013.
Imagine this situation: you have a task with one resource, and duration is 5 days. The task is on track, and it is 50% completed. Suddenly, your resource get sick, and will be able to continue with work after few days. What do you have to do? You can Split Task , or you can use the Resume Field. I’ll show how to do this in PROJECT 2013, but you can also do this in Project 2010. First I’m going to create a new Project with 1 Task: Next, I’m going to create one Resource: Finally, I’m going to assign the Resource to the task: I will now add %Completed, and Resume fields in the Gantt Chart View: As you can see, the Resume Field is N/A, and that is because there is no progress on that task yet. I will now mark a task as 40% completed: The Resume Field is now Wednesday, May 5th. Task is 40% completed, meaning that he worked Monday and Tuesday (16 hours out of the 40 total hours). Now suppose that Resource get sick, and he or she will be back at Monday, May 12th. I will put this date in Resume Field, and I’ll get: As you can see the Finish Date is Wednesday, May 14th and the Task has a Split! It is very easy, and very, very visible!