projectified-old

Deployment Practices: Why Resource Max Units Should Never Be 100%

Reason number one is that in all but the most extraordinary situations it is modeling a situation that is just not possible.

But first some background on what Max Units really is. Max Units defines the percentage of a resource’s full calendar working “period” that they can be assigned to work on tasks before Project sees them as being over-allocated.

Example:
A resource’s calendar says they come in at 8am and work until 5pm and take a 1 hour lunch. They do this Monday – Friday. That is an 8 hour work day\40 hour work week. So if the Max Units is 100% then if the resource is assigned to work 9 hours in one day they will be seen as over-allocated. Same for if they are assigned to work on 2, 1 hour tasks during the same hour. This goes down to the minute level too so if two 1 hour tasks overlap by 1 minute then for that 1 minute they are over-allocated.

This helps the PM create models of assignments and get an idea of how many hours each team member is being assigned to tasks and how that falls across time, other assignments, etc.

So now you might be seeing what is wrong with 100% Max Units. It says that if I work an 8 hour day, I am available to work 8 hours on tasks. On it’s face this sounds logical but dive a little deeper and it becomes obvious that this is just not possible. Nobody ever arrived at work at 8am, took a 1 hour lunch, and then left promptly at 5pm AND got 8 hours of work done on tasks. EVER.

OK wait, I take it back. It is possible that someone did this on your project:  IF your project schedule has tasks for things like: going to the bathroom, answering non-project related emails, going to a company meeting, being tapped on the shoulder by your cube-neighbor and being asked for “just a quick 5 mins. of help” (that turned into 30 mins), the list goes on and on. So if your project contains a task for every possible distraction from YOUR project and you expect your resources to track all of that then never mind. You can set your Max Units to 100%. (just count on a lot of churn on your team.)

But for most of us it is not possible to work 8 full hours on PROJECT WORK in an 8 hour day. Doing so means that you were present for more than 8 hours so that all the other things had time in your day along side your real work. The best way to help our models (because that what project schedules really are: models of what we want our project work to look like) be more accurate is to lower Max Units to something more like 85%. That would be the highest I would ever go on any project I was managing. I have seen it set as low as 75% at some sites but generally I see 80-85%.

What this means is that if you have a 1 day duration task and you assign a resource that has an 85% Max Units value, Project will calculate the Work for that task to be 6.8 hours. This means that you are modeling that on average this resource spends 1.2 hours of their 8  hour day doing something OTHER THAN working on your project. A Max Units value of 75% means that 2 hours is spent doing other things. Of course some will get more than 6.8 done in a day and some will get less done. It depends on the nature of their job, their relationship with other projects, other teams, etc. So the value you set will never be perfectly accurate but it WILL certainly be MORE accurate than 100% which is nearly always wrong. The point here is to make your model as accurate as you can.

 

____________________________________________________________

I’m hoping to start a small series of Deployment Practices posts here covering things I have found to be useful ideas, practices or methods for deploying Project Server. Please email me if you have suggestions or questions.

Technorati Tags: Project Server,Resource Management,EPM

Podcast from WHYY Public Radio in Philly about Multitasking

Multitasking is evil and does not make use more productive. Many project management folks know this, there have been studies and books written about it. Here is a radio show interviewing two experts about it.

In Microsoft Project scheduling terms the implications are: Should you really have 1 person assigned to do 10 tasks this week all at 10% Assignment Units? Hint: The answer is NO.

Tags: multi-tasking, multitasking, work management, project management

When did "Resource" or "Coder" Become 4 Letter Words?

I was recently involved in a conversation where it came up that the term “coders” when used to refer to software developer was dehumanizing, offensive and inappropriate as it was indicative of a state of mind of the interchangeability and essential sameness of all software developers. This is not unlike the ongoing discussion that says the same thing about the use of the word “Resource” or “Resources”. Those that find these terms wrong base their opinion on the premise that referring to those that work on a project as resources reduces them to interchangeable cogs within a machine where if one gets sick or leaves they can just be replaced like a lego brick.

I have a problem with this line of thinking. I tend to hold that it is sometimes required to refer to groups of people with a term that differentiates them from other groups of people. This might be Software Developer, Coder, Systems Analyst, Technical Writer, Accountant, etc. Is the use of any of these terms offensive? Is it the term used or the fact that ANY term is being used? If ANY term is acceptable then would it not also ‘reduce’ the group in the same way? If so how does one refer to a group of people with a similar set of skills? Is it possible to do so?

It seems to me that a manager that treats the people working on his\her project as interchangeable is of course not doing a good job of being a manager. But does a manager that treats their people with complete respect as individuals reduce them by referring to them by their job title or skill?

I always put more stock in actions and intentions than in the pure use of a word. I mean a manager could use all the “right” words but still treat their people with no respect. This is because they have no respect and their intent is wrong. But if a manager has full respect for their people but uses the wrong term and has no intent to dehumanize them are they a bad manager?

I'm fully ready to hear that I'm way outside the envelope of reality here. Maybe I'm just not getting it. Set me straight. I know I'm not seeing it but maybe a comment here can word it in a way that I have not seen before. Up to now the explanations I have seen all seemed like political correctness for it’s own sake.

Glen is on a Roll!

Glen is in a groove riffing on Target Process’s post.

It may be the Target Process just needs to get a better marketing plan, cause from where I sit MSFT Project and other "big name" project management tools do everything they claim they do. They'll need some other way to differentiate their product.

I think this is the key point. I looked at their tool and I would not put them in the same category. Project is a scheduling tool and the Target Process tool seems to be a work management\team collaboration tool ala Basecamp. I don’t think these two tools are really competing. I dont see the average customer of their tool having to weigh their product versus Project. There is almost no feature overlap other than that they both contain things that could be called “Tasks” and those tasks are assigned to human beings.

All I can think of as the rationale for this is that it is fun to bash MS and agile dev people love to bash non-agile methods. This is a no brainer: a two bash for the price of one deal! They got to bash MS and non-agile methods at the same time! :-)

 

The Nature of Critique

Jack is Awesome! (plus anytime you can work an Apocalypse Now reference into a post about Project Management you get my vote right off the bat!)

Here he posts about the criticism of PM tools:

There seem to be two classes of people, those who think criticism is about polishing out the scratches and dents (me) and those who think that finding flaws in parts is a precursor or excuse for trashing something in the whole. I suppose it boils down to whether you believe criticism is constructive or destructive.

I would expand this by saying that criticism, and the value you can place on it, is completely dependent on which one of the two types of people Jack talks about above gave you that criticism. If it was someone of the first type (which Jack certainly is) then you can gather great value from it. If it came from the second type then delete it and have a beer to wash it’s residue and after taste away clean. Well really people of the second type should be avoided at all costs anyway and if you do a good enough job of that then you will not have to worry about getting any of their criticism on you to begin with! :-)

The Project 50

Steven over at ProjectSteps, in his post about WOW Projects, reminded me about two of the coolest books I have read: The Project 50 and the Brand You 50 by Tom Peters. I read them both (and the third one in the series the Professional Services Firm 50) all in about 3 days and then turned around and read the Project and Brand You books again! In them he promised another in the series but, sadly, it never got published. As far as I know Mr. Peter’s concept of a “WOW Project” as Steven talks about in his post was first laid out clearly in The Project 50. I was working for Pacific Edge when I found these books and I begged my boss to let me buy copies for the other Project Managers and Program Managers in my group but was not able to convince him it would be worth the $60! (Ironic that the man managing a group of PMs that were designing and managing the building of Project Management applications would not let me spend $60 on Project Management books.) So I bought a set of them out of my own pocket so the group could use them. I feel that strongly about these books. They changed the way I looked at work and about the work I do and how that work is seen and thought of by my boss, my coworkers, my company and my industry (and myself for that matter).

Buy these books (at least the Project and Brand You books). I just dug them out of my moving boxes where they were since my last move and I am re-reading them this week! You will not be sorry!

Call to Arms Redux

Way back in March of 2004 I did three posts I called A Call to Arms for Project Managers

Part I, Part II, Part III

In them I talked about my hopes for how project managers might use things like blogs and other KM type tools within their work.

I wonder how things have changed in the last year? Post a comment or email me if you have seen the types of tools mentioned in the above articles being used for Project Management purposes.

Oh and it should be noted that in Part I, I get in a little dig on Gantthead that was not quite fair. I had some notions of how their content shaped up based on an opinion I must have formed quite a while ago (like 1999). I have visited them recently and I must say that my comment was certainly out of date. They do have some very good stuff over there. In fact Gantthead and Project Connections both have a surprising amount of great stuff to check out. I have been up and checked out the premium side of Project Connections and must say I was happy with what I found. I have not seen the premium stuff at Gantthead (but I'm sure it is excellent as well). Both sites are worth your time to check out for sure.

Tag Cloud is VERY Cool

Jack just posted about a new (or at least newish) service called TagCloud. These clouds are the things that you see on Flickr or Technorati where there is a list of words and some are bigger than others and they are all links to keywords or ‘tags’ from posts on the site. These are also known as Folksonomies. Anyway this is very cool stuff. The best thing about it is that, like Jack mentions, is that this is not just ‘tags’ like Technorati’s listing. It is all the text in the posts. This is what I have been waiting for for this kind of tool. This makes it so that you are not limited by what the author picked as his or her tags or categories. You get a ‘folksonomy’ of all the words in the whole post!

Here is a link to the Project Management TagCloud I just created. It is basically a word index of all the current (and from this point forward since it is ever updating) posts from all the Project Management related feeds I subscribe to. The bigger the font the more posts there are that contain that word. Click a word and you get a list of the posts that contained it. There are at least 10 feeds here about PM.

Here is the cloud I created for Projectified. I modified my feed for a few minutes so that this cloud contains all 138 posts I have made so far.

The great thing about these is that they are updated several times a day so each time you visit it will be different since things are getting added all the time.

I'm very excited about this. It will make it easier to see how topics and thoughts and subjects are flowing across feeds or groups of feeds.

Project Management Systems Don't Kill Project Knowledge, Bad Project Managers Kill Project Knowledge

Jack Dahlgren talks here about the perceived dangers (not ‘evils’ as I said earlier. Sorry Jack) of project management systems like Project Server that use tools like timesheets to gather status information. He also points to Glen Alleman’s post here about the same subject.

Both are basically saying that systems like this are bad because they automate the interaction between project manager and team member and are not as good as face to face interactions between the PM and the team. They are saying that such systems are bad for teams because they do not allow for the transfer of project knowledge or “project wisdom”.

I could not agree more with both Glen and Jack. HOWEVER. the big problem with this is that both Jack and Glen are assuming that teams that use such software never speak. They seem to be assuming that the PM never has any meetings with the team and that the PM never goes and talks with the team. Any team doing this is just flat out wrong. No caveats. No exceptions. I will put it in bold print so there is no mistakes:

Any project manager that expects an Enterprise Project Management application like Project Server to be the only avenue of communication between themselves and their team is not only wrong, they are TRAGICALLY WRONG!

It is not the software. I can tell you with some confidence having worked many times with the team that designed Project Server that it was not designed to replace face to face communication between Project Manager and Team. What Jack and Glen are describing are organizations that are fundamentally broken. The software just helps them be broken faster.

In my work deploying Project Server with QuantumPM we (myself and the other consultants at QPM) were always very clear about the GRAVE dangers of assuming that Project Server timesheets would replace or fix broken lines of communication within the Project Team.

Glen says that PMs should be asking “…simple questions - what do you mean when you say "we're making progress”. I agree. Project Server (and other tools like it) allows for the efficient collection of the progress information in the detailed kind of way that things like Earned Value and many organizations demand (timesheets) This allows the PM to spend their face to face interactions asking the good questions instead of collecting Actual Work numbers and allows them to ask these good questions armed with the data they might need to ask them well.

So in closing: Project Server does not kill process and interaction, bad PMs do.

The Secret Life of Scope Cuts

Over the past few weeks I have been talking with some old co-workers about our experiences with our old clients. One of the things we talked about was how rare it was that project managers really examine closely the real impacts of cutting scope. By this I mean that they often feel that, for example, if they cut a set of tasks from their project that is estimated to take 30 days that this means they actually cut 30 days from their project. While this might be true for things like a construction project it does not always work out for things like software development projects.

At first thought it sure sounds good though. You have a feature that when you add it all up will take 10 or 20 days to develop. You cut it from the project in an effort to shorten your project and you feel pretty good. (Well as good as you can ever feel after you cut a feature you obviously at some point really liked!) Then you feel pretty flush and you figure you can now shorten your QA time in the schedule because you now have fewer features to test! This is getting better and better. Right? Well maybe not.

The thing that I have noticed people forgetting is that sometimes it takes time to NOT finish a feature. How is the feature or code you are pulling from the product linked or related to other features in the product? Do other features or parts of the application depend on code you plan on pulling or not finishing? Will it require you to rewrite other code to deal with the cut you want to make? Was the application designed in a way that will make this hard or easy? If you decide that you do need to make changes to other code to compensate for this cut has that code already been tested? Will you need to retest code because of this cut?

You see what I’m getting at here. It could end up costing you more time to cut the feature than cutting it would save you! Isn’t software fun?