projectified

Sort Order of Groupings in Project Center Views

OK, so you have a nice view in Project Center and it groups by a given field, we will call it Location. You get all your projects into the system and you notice that the grouping works as expected but the sort of the grouped headings is odd. Not even alphabetical.

Now, this is an “issue” that I'm sure has been around for as long as there has been a Project Server but I only just found it because on this engagement I’m on I broke with my normal process and did not prepare my custom field information the way I normally do. Normally, I gather up the lookup table values and set them up in Excel first. By force of an old habit from other systems I would either sort them in Excel or for those that did needed to be in a non-alpha sort I would put numbers in front of the values. Then I would put them into lookup tables.

I know that Project Server allows you to control the display order of the lookup table (see  below) but I have always done this and habits are hard to break.

 

So what was my problem with the sort of my groups? Project Server views sort the group headings according to the display order set in the lookup table of the field you grouped on. My issue was that I had not put numbers in front of the values and I did not pick Sort Ascending. The default is By Row Number and that has always worked for me given my odd ‘pre sorting’ that is part of my normal routine. I went in and changed the sort order or my lookup table and my grouping was correct.

The moral of this story could be “Don’t break with your process” or maybe it is “Update your process”. I'm going to go with the idea that it is “Don’t break with your process!” :-)

Deployment Practices: Required Fields

Few things are more frustrating then using a system and being presented with a field you MUST fill in to continue at a time when you don’t know which value is appropriate for that field. Project Server is no exception.

You can make any enterprise custom field in Project Server a required field. At the project level this means that a project cannot be saved until each of these fields contains a value. This is great if you know for sure that the project manager will always know which value to pick from the list at the time they first save their project. But if they don’t you have a couple of things that are going to happen and you need to be prepared for them and decide if they are your intended consequences.

1. The project manager will NOT save their project until they find the answer (remember that the answer COULD be several days away.) Do you really want the PM to NOT save the project because they don’t have the answer to this one field? Where will they start their planning in the mean time? Where will their data go?
2. The project manager will pick one of the values from the list just so they can save the project even if that value is not right. Remember that they may not remember to come back and fix it when they have the right information!
3. The project manager will curse you (the administrator) and pray to their God that you be injured in some way very soon.

Number 3 is going to happen for sure, count on it. What you have to decide is if you want number 1 or number 2 to be happening while your curse\injury takes place. The easy way to avoid all three is to either NOT make fields required unless you 100% sure that the project manager will know which value pertains to their project OR provide them a “Not Yet Known” value in the lookup table.

I tend to prefer the “NOT YET KNOWN” option. It allows your views and reports to show which projects have complete field profiles and which projects are in need of more complete data. Just make sure that the people you have creating reports and views know to allow for this value in their filters. This means that if you want to show all projects where a field equals “X”  or “Y” that it should also contain projects where it equals “Not Yet Known” because those projects MIGHT be "X” or “Y”, we just don’t know yet. :-)

 

Technorati Tags: Project Server,EPM

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

Project and Project Server SP1 Are Here!

The haters should note the date please. :-)

This TechNet article covers the how to (Read it before you update):

http://technet2.microsoft.com/Office/en-us/library/c3b86049-7cba-4b9c-8335-e37fb6e7518a1033.mspx?mfr=true

Here is WSS SP1:
http://www.microsoft.com/downloads/details.aspx?FamilyId=4191A531-A2E9-45E4-B71E-5B0B17108BD2&displaylang=en

Here is Office Servers SP1 (which includes Project Server and Office SharePoint Server):
http://www.microsoft.com/downloads/details.aspx?FamilyID=ad59175c-ad6a-4027-8c2f-db25322f791b&DisplayLang=en

Here is Project 2007 SP1:
http://www.microsoft.com/downloads/details.aspx?FamilyID=CEC3E1E2-D802-4A03-BC78-05C48472559B&displayLang=en

Here is the Project Server MUI SP1:
http://www.microsoft.com/downloads/details.aspx?FamilyId=D322BA67-B199-4503-8AFF-6813B320D708&displaylang=en

Here is the Office Server MUI SP1:
http://www.microsoft.com/downloads/details.aspx?FamilyId=3A6C26FD-0BEB-40D5-8CBA-15164FAAB150&displaylang=en

And for Good Measure here is the Office 2007 SP1 download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=9EC51594-992C-4165-A997-25DA01F388F5&displaylang=en

Iterative Design\Build Loops in the Configuration of Project Server: First Pass and Initial Thoughts

I have always been a fan (and in fact a major proponent) of the idea of iteration in the long term deployment and roll out of Project Server across an organization. Myself and Russ Young of QuantumPM were one of the first ones to talk about this in the Enterprise Project Management Deployment Guide way back during the Project Server 2002 days. Our work in this area was based on ideas that were widely held not only in the Project Server consulting world but in almost all enterprise software organizations. These iterations were fairly large scale ones dealing with the staged, incremental roll out of Project Server to the many organizations within a larger organization as opposed to the massive one-time dropping of Project Server on the entire company. This approach started with a small but representative (as much as possible) group or small organization and then using the lessons learned from this group the system would be adjusted (new fields added, new views, server architecture adjusted, etc) and then another group would be added. This process would repeat until the entire organization was using the tool. Each iteration added not only new people but also new or fixed functionality in the form of views, security, process, etc. This method is now used by virtually every consulting company doing Project Server deployments.

The kind of iteration I’m talking about here happen on a much, much smaller scale and deal with the actual design and production of the configuration of the Project Server system for a given organization. Instead of dealing with the successive roll out to new organizations I'm now talking about the iterative design\build loops around adding new fields, views, security configurations within any one of those larger iterations.

Understanding of the Environment and the Problem(s) to be solved
This includes the collection of what the users want the system to do for them in addition to the observation of the system at work so that you as the consultant can help make suggestions.

Configuration\Build
From the knowledge gained so far the system is configured to the best of your ability. Fields, views, security, etc.

Simulations
most organizational uses of tools like Project Server revolve around the capture and editing of project data and then in the use of that data to make specific business decisions that effect the ability of the organization or project team to function with regard to projects. I look at kernel, the very core of Project Server’s use in an organization as the viewing of data via views or reports by decision makers. Everything else that project Server does supports this in some way or another. With this driving principle in mind the check or test of the configuration\build ‘stage’ is a simulation where decision makers use the tool as it is currently configured to simulate the decision making processes they must go through to manage their work\projects\portfolios\etc. These simulations have the decision makers using the tool in a conference room with the design team and other decision makers up on a projector. Talking through the decisions they need to make and what data they would need to see to make them. How it would need to be displayed, grouped, sorted, how it should be secured, who can see it, who can’t see it, etc.All effort toward a better understanding of how the tool will be used and what decisions it will be used to support.

Revisiting the build stage…
At this point we jump into a loop of Configuration\Build and Simulation loops that successively improve the suitability of the Project Server configuration to the needs of the decision makers that will be using it to run the business\projects\work.  If this means new views or fields then so be it. If it means configuring and rolling out the use of timesheets to those doing the work or the development of custom OLAP cube building routines to provide company specific data in Portfolio Analyzer views then that is fine too.The point is that the design\configuration happens based on simulated use of the product as it is configured currently.

___

This process can take place either prior to the system ‘going live’ or as part of the addition of new users to the system. Also, a variation on this process happens on an ongoing basis while the system is being used by the organization. As people touch the system and use it as part of their project management\portfolio management processes their new experiences and new expectations become, often, new requirements for the system. The administrator of the Project Server system should constantly collect suggestions and new requirements and evaluate them with the team for inclusion in the system. This constant updating of the product’s configuration ensures that it keeps up with the most current processes in use within the organization.

___

Obviously this is not rocket science and I'm not claiming to have ‘invented’ it by any means. I’m sure that many others are using similar processes for their Project Server (or other PM software) roll outs. I should also mention that this process is only suitable where the organization is able to devote several weeks (at least 3 or 4) to this initial design process. Often organizations that are rolling out Project Server have only a very short time to do their initial design and configuration. In cases like this the process laid out here may require too much time. But it should be said that while this process requires more time than many methodologies it is much more likely to produce a usable system. Shorter term processes get you up and running very quickly but at the cost of fully understanding the processes and needs of the organization.

This is just an initial layout of rough thoughts on this process. It is by no means final.

 

Now THAT'S What I'm Talkin' About!!!

Dieter talks SERVER SIDE SCHEDULING ENGINE for the next version of Project Server!!!

Nice!

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! :-)

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.

Technology vs. Culture

Frank Patrick talks here and here about the difference between a technological solution and a cultural solution based on a thought on GapingVoid.

I could not agree more. The word ‘Culture’ comes up a lot when I do deployments of Project Server. Obviously Project Server is a technological solution but I go to great lengths to make sure that the people I talk to about it know that it is just part of the “nutritious breakfast”. When I worked for QuantumPM we all did our best to fix the all to common misunderstanding among some clients that installing Project Server was going to suddenly make them better at doing projects. Sadly, it did not always work. Technology is easy. Project Server 2003 is pretty darn easy to install. Configuring is more difficult but only because it requires an analysis of the culture of the organisation and of it’s processes. Here before the tool is even ready to be used the importance of culture is right there having an effect on the success of the technology.

Timesheets\task status was the place where the importance of culture was the easiest to get across to clients. Collecting status via an electronic timesheet (like the one in Project Server) seems, on first glance of the client, to be pretty simple: Tell your team members they should go to a web page and enter their time each week. No problem, right? WRONG! What if they have never had to do this before? What if they think you only want this to see who is not putting in ‘enough’ hours in a week? What if they don’t trust the managers to use this info in a way they agree with? These are all important cultural factors in an organisation that need to be addressed before rolling out a timesheet type solution. I remember first seeing this when I worked at Pacific Edge Software. We had the same problem with our clients there as many Project Server clients: team members resist the deployment of timesheet type status collection methods because the organisational culture was one of mistrust and fear of what would be done with that information.

I always try to do my best to correct my clients when they refer to what we are doing as “installing” Project Server. Installing Project Server is something that happens but it is not why I’m there (even if is why you THINK I'm there). What companies like QuantumPM are doing is project management process improvement that just happens to install some software in support of the larger deployment of new processes (read process as ‘culture’).

There is a HUGE difference between ‘installing’ and deploying. Installing Project Server takes about an hour or two. Deploying Project Server as a part of a larger process\culture change program takes months if not years of ever evolving changes, tweaks and improvements.

Invalid Node Name Error when Re-Activating an Inactive Resoruce in Pro

I have seen several people on the newsgroups get this but I never had anything to help them until today.

The problem was that you get the error below when you check out an Inactive resource from the Enterprise Pool and then try to Activate them (uncheck the Inactive box on the Resource Information dialog) inside of Project Professional.

Project Server was unable to process the request.

An invalid node name parameter was specified.

The workaround for this is to Activate the resource from inside the Modify User page within the Admin area of Project Web Access.

Microsoft is aware of the issue and I think it is only a matter of time that it finds itself into a hotfix or Service Pack down the road.