Most of us need to calculate the need for resources but the question is what you calculate.
One thing you can calculate is how much resources you need to complete a task. The first question is of course what do you mean by completing a task. If you’re working with software development, is it the coding, or does it include all the things you need before and after the coding (branching, getting to know the code, writing tests, merging, validating test environment) and does it include stuff that other people do. Another question is if you say something takes 10 days, do you mean 10 days of actual work or do you mean days between you start with a task and when you end the task, the latter concept is what we call Duration in Microsoft project.
In other words you need to know
* The definition of done
* Decide if you calculate Duration or Work
The next thing is that you need to start thinking about the difference between cost of delivery and cost of creating. Lets say you have a task which takes 40 hours of hard labor to complete. Lets say your resource actually completed the task in 40 hours. But chances are great that he will bill you more than 40 hours. People take breaks, the help other resources with their tasks, they do other stuff. Do they report these side things on your project? You bet! Imagine the opposite! Two resources are working on different tasks but on the same project. First one of the resources want a second opinion from his team mate. So he strolls over and they talk things over for 15 minutes. Would you want all resources keeping track on stuff like that. This is one of the reasons we want team rooms but it also gives us a situation when tasks cost more than the cost of their delivery.
As we are budgeting our projects, I must surely keep this in mind. In my budget, I must take into consideration that this happens so even if I use the scenario that 60% of time is spent on tasks, I need to calculate that they work 100% anyway. So I need to take into consideration:
* The number of hours tasks take
* The number of hours tasks bill the project
In other cases, thing become more complicated. Take the product owner role. That person should sit 100% of his time with the team but he doesn’t have to work 100% on project tasks. He can do other stuff in the team room (as long as he can be pulled from these tasks whenever someone needs help and that the other stuff doesn’t bother the other team members). If you do have a product owner who works 100% in the project that is perhaps more of a warning sign: you might have a product owner proxy or someone who’s not involved in everyday business work.
Sorry I haven’t written lately but neither has Shakespeare… I simply don’t have a good excuse rather than priorities have been elsewhere.
But finally I’ve collected all the post links on one page.
One aspect of the agile community which I love (or is it all software developers, or people, I don’t know) is the eagerness to share and help out. As I explained in a previous post, I have no file archive so you needed to e-mail me to get my sample Project files. But Jochem Bökkers volunteered to help me out. So, now you can download the files from here.
Well, the files are nothing special. In the file Project1, I just added the settings described in Tutorial Part 22. I’ve also created a number of sample files, showing how Project can be used through out the project.
Get back to be if you have questions and input!
In this file, I have used the Resource Usage View. In the diagram (right side) I’ve changed the time scale to visualize weeks and changed so that also Baseline work is displayed. This means that I can compare my original plan (baseline work) with current plan (Work). In the left table, I’ve added the fields % Work Complete, Baseline Work, Actual Work and Work (planned). This is a view which can be used to see how resources are used and how we planned there were going to be used on a weekly basis.
In this file, I’ve used the Resource Usage view, changed the time scale to view weeks and changed the right side so it shows actual work. This means that time reporting can be done directly in the graph. On the left side I can also adjust Work (the planned work) and compare plan (work) with original plan (baseline work) and actual work.
In this file I’ve used the Gantt chart but changed the diagram so it shows weeks (you can guess this is my favorite). I’ve made a split to the view so I can select and edit specific sprints. To the table, I’ve added some fields so I can track progress. In the example, I’ve also visualised a cut sprint and an added sprint. Sprint B was cut short and Sprint D was added. I can see the added sprint by it lacking Baseline values.
In this simple example, I’ve just added two versions of a project and I’ve used the Gantt chart but have some added columns (Cost & Work) which is useful to the customer.
This is a simple template which uses my common settings for a new project. Note that I often change views (as can be seen in the other files) so you will have to customize your views after your needs.
I promised too long ago a sample project file for an agile project. Well, I finally came around to do one just to learn that I cannot share .mpp files on my WordPress file share. So, post a comment here or contact me on my e-mail or twitter (nnaa) and I’ll send it to you.
I’ve received a couple of questions lately concerning Microsoft Project, which I haven’t covered in a while, so I’ve decided to write some more posts. I will, as I’ve previously posted, also post an example file for an agile project in Microsoft Project. But what are YOU interested in? Post a comment or e-mail me if you have any specific topics for me to cover.
What is an estimate?
According to Dictionary.com the verb means:
to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education.
to form an opinion of; judge.
and the noun means
an approximate judgment or calculation, as of the value, amount, time, size, or weight of something.
a judgment or opinion, as of the qualities of a person or thing.
a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work.
So, why is that a bad word? Well, I don’t think it’s really a bad word, but in the case of software development, the use of the word results in some serious problems.
Case 1: A developer leaves a task unfinished, that is not according to Definition of Done. The reason is that he’s run out of time according to the estimate so he drops it or finish it with lacking quality.
Case 2: A developer starts working on “something else”. The reason is that he finished what he was supposed to in less than the estimated time and felt free to spend the rest of the time with that other stuff.
Case 3: A project manager gets upset that a project is late. The reason is that he feels that the project is late because things took longer than the estimates.
So, why is estimate a bad word? It’s because it can cause people being pushed into not completing the tasks or not doing the things that have the highest priority. It causes confusion.
And if you consider a project where Case 1 and Case 2 are common, what happens? It causes some stuff to be bug infested which probably causes later delays and you’re never able to make up the time since when the developers are faster than the estimate, instead of moving on to the next item, they fill up the time with other stuff. Observe that I don’t assume that they are surfing the web or just idling, perhaps they refactor or something else. So, it is often good stuff, but not the most important stuff. And it does not help in catching up. So, what does this lead to; Case 3. If the project delivers poor quality and unfinished work and never makes up the time, of course the project will be delayed.
So, what word is better? Planned? Don’t think so, even if Microsoft Project use that word. This word most definitely leads to all these cases. Assumption is no better. When you think about it, you just have to realize that the word will lead to misunderstandings. So, what do you do?
Well, to handle Case 1 & 2 you need leadership and here I think that Kanban is a real savior. You cannot just drop the work and you cannot use the estimate as “your time”.
But what about that project manager? When it comes to the project manager’s need for planning, it’s important for him to realize that an estimate is a guess. A good or a bad guess. And when you’re guessing, you need to know the value of the guess. I like working the PERT analysis when this is a big issue (isn’t always??). You give three estimates; an optimistic, a probably and a pessimistic. Here is an excellent presentation on PERT analysis by Ricardo Vargas.
You can also add a value of risk to the estimate. So, when you estimate something, you estimate the size and the risk. And you would be stupid if you don’t realize that if you have a big task with a high risk, you cannot take that estimate for granted.
From a project manager’s point of view
On 2009-06-25, I and a colleague listened to a seminar concerning news in Team Foundation Server (TFS) 2010. We are currently using TFS 2008 mainly for source code handling and tracking progress (using the work item tracking functionality) during projects. Here are my notes.
TFS 2010 include a new client, especially for testers, Test Essentials or Test & Lab Management. This will mean that to be able to work effectively as a test leader or tester, you don’t need a Visual Studio installation. It is today unclear how licensing will work with the new client.
The integration with Microsoft Office require Office 2007.
SQL 2008, SP1 is required.
You can run a VS 2010 client against TFS 2008 SP1 and using patches, a user can run VS 2008 against TFS 2010. This enables a step by step upgrading of the environment.
The installation of a new server is complicated and takes a lot of time. You can though make the installation first and make all configuration in a second step, This means that the person responsible for installation does not need all configuration variables to complete the installation.
The possibilities for load balancing has been increased which would enable us to runt TFS on multiple servers and also make use of several SQL Server.
Work item tracking
The most important change here is the possibility to not only link work items but actually specify how items are linked. You can for example:
- Specify a hierarchy. This would mean that we can specify which tests are included in a test plan or which tasks belong to a product backlog item.
- Predecessor/successor relationship. This would mean that we could specify that one task is dependant on the for filling of another task.
- Related items of a specific work item type. This would mean that we could specify requirements in the form of tests and we could then specify on a task Definition of Done in the form of which tests are to be passed to see the task as completed.
A smaller change is that you can group different work item types to ease the creation of reports and queries. Using our current development process, we have no need for this.
The reports are as before available in Reporting Services format but there is an increased number of Excel reports, which also use the data warehouse. This would make us less dependant of reporting services for our project management.
There is also a specific report called Agile Workbook. In this, a number of reports, focused on the product owner and scrum master roles has been gathered.
The concept of Gated Build is introduced and means that when a developer checks in, he can make a test build before an actual checkin. This would better hinder checkins which breaks the build.
The build scripts use Workflow 4, which enable a more graphical view of builds.
TFS Admin Console
A new client, targeting the administrator wanting control of his TFS and include the functionality which an administrator needs.
Test & Lab Management
This is a Windows client which does not require Visual Studio and target the needs of the tester. Here a tester can set up test manuscripts, run tests and report bugs. What was also really interesting was that while running tests, a tester can choose to record his steps and when filing a bug, he can automatically send a film or pictures of the situation. The recording can then also be used when verifying that a bug is fixed: the macro retakes all steps to the failing step, which makes the validation faster.
What also was interesting was the possibility to set up virtual environments for different test scenarios, for example different cultural settings and configurations. Since a test is run in a specific environment, we can keep better track of the environment in which the tests are run and not run. Also, when filing bugs, a snapshot of the environment at the time of the failure is possible.
Visual Studio for Architects
The seminar did not cover functionality in Visual Studio but notable is the inclusion of modeling in UML using Visual Studio. Use cases and processes can be directly modeled in Visual studio and linked to code and work items. Also, it is possible to automatically derive a model from a current system.
Since this is stored in the source control system, the models would be source controlled, which means that you can track changes of the system and even see which checkins have changed the model.
The visualization of a search result has been improved since you can view a tree view or a link of the items and their directly related items. You can also click and drag to move work items in the hierarchy, for example if you want to move tasks between sprints or product backlog items.
Queries can now be collected in folders and you can also make rights settings these folders to hinder users from accidently changing common queries.
You can in TFS see graphically how branching and merging has occurred and using a graphical tool merge.
The user interface in the web access has been improved and include a dashboard functionality to enable views which are specific for the different types of users.
I guess the main reason for most project managers to use Microsoft Project is drawing the traditional Gantt chart. It’s kind of obvious, since the Gantt chart view is the default view of the program. This view is also confirmed by the default fields that are visible. A task is in Microsoft Project described by over a hundred fields but only eight of these are visible using the default settings.
If you just start up a default session of Microsoft Project and don’t change any setting, this is how you define a Task:
· Name (Text)
· Duration (Days)
· Start (Date & time, even if only the date is visible)
· Finish (Date & time, even if only the date is visible)
· Predecessors (Numbers – ID of tasks which the task directly depends on)
· Resource Names (Names of Resources)
If you open one of the templates provided by Microsoft, they all look something like this:
There are all these tasks where one leads to the other and where the assignment is already done. You’re supposed to enter the Duration (in Days).
What is important is to understand what Duration is and what it’s not. In agile methodologies such as scrum, when defining tasks during sprint, you estimate how much work a task should result in. In other words; how many man hours it is estimated that a task will result in. This attribute is in Microsoft Project referred to as Work. And that is not the same as Duration. You cannot even see Work with the default settings. Work is what you get when you add resources to a task. But why is this? I believe that it all comes back to what I assume is the basic use for Microsoft Project; drawing the Gantt chart.
The Gantt chart is made up of all these blue bars, all connected to each other and leading to the end of the project. So the assumption of the Gantt chart is that if you make a Gantt chart, you can calculate when the project should be completed. That sounds great! Just what my stakeholders want.
The individual bars in the Gantt chart have a length and a place in time. The length is the attribute Duration, and therefore it makes sense to have the attribute Duration clearly visible and editable. And to place the bar in time you can use two methods, you can either link them together or you can place them on a specific date. The linking information is saved in the field Predecessors and you can specify a date by changing the Start or Finish Columns.
The final touch to the Gantt chart is the displaying of the resources names and that is stored in the field Resource Names.
So, there you have it; the columns in the default view of Microsoft Project are the ones which you need to draw the Gantt chart.
But does this mean that you can calculate the finish date of the project based on this? Well I think that experience talks against this. Just the fact that you cannot see the assumed workload makes the planning blind. And as I’ve previously discussed; since the focus factor is 100%, no holidays are in the system and the slack is 0, we all know that this is an illusion. Looking at the Gantt chart, I see the similarity with stairways and you get the feeling that all tasks are individual steps on the stairways. You just have to walk down that and you’re done. You can just check of the steps as you fly by them. Right.
Another problem with having the Gantt chart as the objective of your planning is what you want to do with that Gantt chart. Yes, you want that planned end date but you also want to show the chart to your steering group. And then you need to print it or take a screen copy and enter it into your PowerPoint presentation. Let’s see what happens when we open one of the templates:
But hey, I can’t see all those bars, and I cannot see all those rows! But then I need to collapse the heading tasks and change the timescale:
But then I’m missing out on my nice blue bars and it looks strange. So, to keep my project nice and clean, it’s better to keep the number of tasks down. Also, linking in the Chart view is a pain if you cannot see all the tasks at the same time.
And here, we also see a conflict with agile values. In most agile methodologies, you want to keep the tasks as small as possible to enable more accurate estimates. But this clutter up the Gantt chart, making it hard to read and linking becomes complicated.
Finally, we have another problem with having the Gantt chart drawing as the objective of our planning. The product backlog does not fit into this scenario. A product backlog is a prioritized list of requirements but this does not mean that the product backlog items are interlinked. So you cannot link them in the Gantt chart. But if you don’t link them, you don’t get your Gantt chart.
Next time you start Microsoft Project, ready to create the plan for you next project, keep your objectives clear; is your goal drawing a dreamy Gantt chart or do you have higher goals?
I’ve on this blog posted a tutorial on using Microsoft Project as a planning tool. I cannot say it’s easy but neither is planning. Thinking that you’ve planned your project just because you have a Gantt chart to show your steering group is a first step towards a challenged project.
Wouldn’t you say that it’s hard to be Sarah in this example:
When you view the Resource Graph (View—>Resource Graph), it can look something like this.
On the left side you have a resource. If you scroll the left scroll bar, you select resource. And on the right side you have the graph, showing some kind of information. But what are you look at?
Well, if you look at the text just over the left horizontal scroll bar you can see that it reads “Pek Units”. This means that Sarah has assigned AT THE MOST 200% during Q2 2009.
If you change view to Gantt chart, you can see that she’s not so very booked after all:
She’s actually booked 200%, but just during 1 minute. So, don’t take the resource graph too seriously.
But the resource graph can be used. If we switch back you can see that you can right click the diagram part and choose metric. And here Work probably says more that Peak Work:
And if we use a better project, it actually says something. When I changed to a real project, changed metrics to Work and customized the timescale (double click timescale) to show months and weeks, I can see the work load for each resource per week:
Compare this with the same view but with Peak Units selected instead;
Every time I write a new post in my tutorial, I think it will be the last. And then I realize that there is something I’ve missed. And of course, I’ve missed the grouping and filtering functionality.
The most basic grouping functionality has already been covered: the usage of heading tasks:
All tasks have an ID but they also have a WBS code. WBS stands for work breakdown structure and if you right click a column and select Insert column, you can select to insert the WBS field.
The column to the left is the ID field while the WBS field is the field to the right.
You can actually customize the WBS codes. This is very useful if you have inserted projects, when both the ID column and WBS column will have duplicates.
So, to customize the WBS code, you select Project—>WBS—>Define Code.
This dialog box is empty if you view it on a new project, which means numeric values are used and the different levels are divided by dots(.).
On the first row, you can see a preview of your defined code. On the second row, you can specify a Project Code Prefix, and this is as I mentioned; a very good thing if you have inserted project files.
In the grid, each row specifies a level in the WBS code and if a level isn’t defined, the rule with numbers and dots is used. On each level you specify what kind of symbols divides the different values and here you most commonly choose between numbers and letters. You can also see that you can choose between uppercase and lowercase. In the column length, you can specify how many signs can be used in that position, so if you select 1 there can only be 1,2,3,4,5,6.7.8 and 9 in that position. In the separator position you specify which separator is used.
As you can see in the bottom of the dialog box, you can also select to not making the WBS code automatic. The reason for this is that if you refer to this number in other documentation and the insertion of new tasks are done, the WBS codes of other tasks can be changed.
Confirm with OK and have fun with your WBS codes!