projectified

It Might be Better Than You Think...

Recently I was working with a customer that was going to deploy Project Server as one part of a larger effort to improve their organizational project management practices and processes. Through our initial conversations I was struck by the negative way they viewed not only how they did things currently (hence the desire to change) but also about their readiness and even ability to undertake these changes. However, despite these negative feelings they were much farther along then they thought.

As the cliche goes the first step in getting better is realizing you have a problem. I have worked with many (MANY) companies that did not think they had a problem. They just wanted software to compliment their existing processes. A few of them were  right, they did do things well but most were not seeing the bigger picture.

The customer I'm thinking of not only knew that they had an issue with things but also had decided on change and had put together a team that had the authority to make the changes needed. They had thought long and hard about what had to change and had even laid out some possible changes for me to look at and talk about with them. All they needed help with was on the specifics of how to go about making the changes. One of these was to put some software in place to give better visibility to those that needed it.

They thought they were miles away from being ready when in reality they were so close they could not see it!

If you are asking the question then you are more ready than you think!

Categories Should be Single Purpose

Categories in Project Server provide users access to resources and projects. There is a tendency that I have noticed in the field for people to try and get one category to give access to all the projects that a user might need access to within all the roles that user plays in the system. For example:

My Projects. Many administrators see this category and correctly assume that this is the category to which their project managers should belong. But then they try to set the permissions in the category so that it lets the project managers see not only the projects they manage but also the projects on which they are resources. This seems fine in theory but there is an important problem here. The permissions that the project managers need for the projects they manage "Open Project" and "Save Project" are generally more than you want to give a resource on a project. You want the PM to be able to these things on the projects they manage but NOT on projects where they are assigned as resources.

 

 

 

 

 

 

 

 

 

 

But if they have the permissions checked as shown above AND they have access to the projects listed below they will be able to take any project where they are assigned as resources into Project Pro and save changes made to the plan, even though they are not the project manager of that project.

The administrator of the this category over-thought the roles that project managers might fill. This admin tried to get the My Projects category to do more than one thing. A better solution would have been to ONLY check the first box in the My Projects category and then also assign the project managers that might be team members to a group that gave them access to a category where ONLY the second box was checked, giving them permissions to see projects where they are team members. This second category would NOT have the Open Project or Save Project permission.

You can have as many categories as you want, there is no limit. Make them single purpose\single role. If a person is going to fill multiple roles then associate them with multiple categories. If a person is a PM for some projects, a Resource Manager of some resources and also a team member then make sure they get associated with the My Projects, My Resources and My Tasks categories and that these categories are constructed so that they give access to ONLY the items that that specific role would need to see.

Think about Roles not about people when building your security model.

 

 

Project\Project Server SP1 is a Two Part Exercise

Both Project Server\Project Pro 2002 and Project Server\Project Pro 2003 now have Service Packs.

It is vital to remember that these service packs come in two parts: A server side install and then a client side install.

If you install only the server side part of the fix and do not install the client side you will NOT be getting all of the fixes. The same goes for the other direction. If you install only the client side and not the server side you will not be doing any good.

You MUST install both sides of the fix to really have SP1.

Project Server 101: Remember the IE Settings

One of the most common things that cause new users of Project Server issues when connecting has to do with IE security settings.

Project Server requires the Project Server url to be in the IE Trusted Sites Zone and that the Security level for the Trusted Sites zone be set to LOW.

Remember that users of PWA and users of Project Pro must add the url for the Project Server to their Trusted Sites Zone AND that zone must be set to LOW for security.

You Read it HERE First, Now it's In the KB!

Back on March 2nd I talked here about a SQL Server error you can see when connecting to Project Server if the version of MDAC on the client is not the same vesion as on the server.

I recently discovered that as part of the Microsoft MVP program I can make contributions to the Microsoft Knowledge Base so...I added this (what I think is handy information) to the KB. You can check it out HERE.

So if you have ever thought to yourself: "I wish there was a KB article that covered...." Let me know via email and I will use my 'secret powers' to get it added to the KB! :-)

Resource Management Gone Crazy II

Frank Patrick made an excellent point on the misconception of resource utilization on his blog a few days ago that I somehow missed! (Thanks, Frank, for pointing this out)

Im glad Im not the only one that sees organizations striving to over-allocate their resources! The worst part of this kind of overallocation is that it is disguised as perfect allocation. Applications like Microsoft Project ask you to define the threshold it will use to determine if a resource is "overallocated". In Project this is called the "Max Units" field. Then you assign resources at a given Units value and if Project sees that for any given time period the sum of the assignment units for a given resource is greater than their Max Units value that resource is seen as "overallocated". So the sticky part is where to set Max Units. 100% is the default out of the box and there are organizations that think that is a goal. It makes sense when you first think about it. "I want my resource to be fully allocated." Well sure. Who would not want that! But if you have someone assigned to even a single project (because you have recognized the evil that is multi-tasking) at 100% then they are not OVER allocated on paper. But they really are because NOBODY is available 100% of their X-hour work day. They answer email, go to meetings, get asked questions by coworkers and sometimes they even get up to go to the bathroom!

Most 'authorities' agree that the real amount of availability for a resource is somewhere between 65% and 80%. Im kind of in the middle of these two figures at about 70%. That gives a resource about 2.5 hours a day to "other things". This also acts as a buffer so that if a resource does have to push it and work more than that 70% they are not automatically in OT territory.

So if you are using Microsoft Project to manage your schedules/resource usage then make a note to examine the Max Units values for your resources. If they are at 100% you may want to rethink it to take these concepts into account.

Resource Management Gone Crazy: Dont let this happen to you!

I was recently working with a person via email to offer some help in the setting up of their Project Server environment. It was a friend of a friend that worked for a nonprofit and so I was donating time to fill in the gaps they had in understanding a few of the finer points. Anyway, one of their goals for deploying Project Server was to "better manage the time of their staff." A laudable goal to be sure, right? Well recently, after they had the deployment underway I got an email talking about how the resources were revolting against the system. I talked a bit about how things were going and asked some questions about how they were using the system. It turns out that the deployment of Project Server helped them see that many of their resources were not 100% utilized, not even close and many were only working on one project while also being "underutilized". Well they soon fixed this and there were some resources that now had 30 or 40 (one had 75) tasks A WEEK across as many as 10 different projects! (in a single week!)

I told him that revolt was not bad and that he was lucky the resources did not band together and have him killed! These resources went from working on 1 or maybe 2 or 3 projects at a time to working on an average of 7 projects in any given week.

I had to explain to my friend the evils not only in assigning anyone at a full 100% for extended periods of time but also the evils of having someone do work on that many different projects at the same time. I referred him to the August 2003 Software Development Magazine article on task switching/multi-tasking by product management guru Johanna Rothman. She does a great job of discussing why continual context switching is a bad thing.

Nobody should be assigned to work on 8 projects at a time and if it MUST be done it should only be for a very short period of time. Johanna talks about the cost of this in terms of time but there is another cost to this and that is the toll this kind of switching has one the morale of your resources. It is draining physically and mentally to have to move between so many different projects. The other factor that comes in is that if there are 6 or 8 project managers in this persons life there is no way they are not being pressured to give one project more time than has been allotted in this complex assignments scheme. Each project manager has only been given a small fraction of that person's time. You KNOW that at least one is sending that person email asking for more time "under the table". Nobody will fess-up but you have to know it is happening. :-)

Do you best to consolidate the assignments on different projects so that they can be done in chunks that require a whole person or at least as much of a whole person as possible. You will get better work out of your resources and you can just a little more sure that they are not plotting your death. :-)

Friends Don't Let Friends Make Direct DB Edits!

Project Server is a great product but it is an even better platform. It provides a basis for customized solutions that can be written for a huge variety of special situations. Way back with Project 98 and Project 2000 I worked with a company that did just that. We had an application that used direct database integration to build on the functionality that the desktop application of Project 98 and 2000 provided.

Many companies are seeing the added functionality that Project Server provides and they want to build on it to develop a specific customized solution for themselves or for their customers. Many of them are still using the direct database editing to do their integration. This is not a good idea.

The Project Server database is essentially two databases. One is used exclusively by Project Server to display and work with data on the web interface (Project Web Access). The other is used by Project Professional, the desktop scheduling tool. The two are kept in synch by Project Server. One of the reasons for this is so that a project manager can publish changes to the server for the 'world' to see but still have the working copy of the project that they are editing that is not seen by the world. Because of this synchronization that is going on it can be tricky to make direct database edits. It is easy to make an edit that seems right but then turns out to cause problems the next time the database is read by Project Pro or synched up with Server.

The irony is that for many of the most common actions you might need to take to integrate an application with Project Server there are methods to use in the Project Data Service (PDS). The PDS is the SOAP/XML interface for making programmatic access to Project Server functionality. You can do just about anything with a built in PDS method. For example it is possible to reconstruct the entire Project Web Access timesheet using standard PDS methods. The entire Outlook Calendar integration that ships with Project Server 2003 was built using standard PDS calls.

The moral is that if you are looking at doing Project Server integration work you NEED to look at the PDS reference found in the Project Server 2003 SDK. It will not only save you the trouble of corrupting your Project Server database with what you THOUGHT was a perfectly good database edit it will very likely save you tons of programming time since the methods most commonly only require you to pass in a few arguments instead of having to write complex SQL Stored Procedures.

Do yourself a favor and check out the SDK.

Timesheets not Important? Oh But they are...I promise.

Jack Vinson of the Knowledge Jolt with Jack blog has some interesting views on timesheets and he mentioned my post about Timesheets.

He says this about why a company where he worked decided not to use timesheets when they went to a Critical Chain Project Management system (CCPM):

The root reason that we decided to not use time sheets for our CCPM implementation is that they are not consistent with the principles of CCPM. CCPM is interested in successful execution of the overall project: Are we working on the right things? How much longer on that task? Is Jan ready to start when Joe finishes? Time cards are focused on execution of individual tasks: Did you start "on time?" Did you finish within the allotted time? This information seems very useful for billing and managing individuals, but not the success of a project. The meaning of starting something on time is almost irrelevant in real project environments where the initial duration estimates are estimates and not carved in stone. It doesn't particularly matter if Jane takes longer than expected as long as the team sees how that will impact their subsequent work and what can be done to recover excess buffer incursions.

Jack mentions that CCPM is interested in things like "How much longer on that task?" and "Is Jan ready to start when Joe finishes?" and I agree that these are key elements of any PM system BUT (there is always a but!) how do you know "how much longer" and "...when joe finishes" without a way of finding out? A timesheet is the way the PM asks 50 resources when they will be finished. Sure along the way it also asks when they started and how much time they have spent doing it but that is also useful info in ANY system CPM, CCPM or otherwise.

Jack also talks about it not mattering if "...Jane takes longer than expected as long as the team sees how that will impact their subsequent work..." But how does the team know that Jane is taking longer? How does the team know the impact on the original plan unless the PM gets this new info from somewhere and then updates the project plan? The timesheet serves this purpose.

I hope that I did not make it seem like a timesheet was JUST about collecting hours for billing. If I did then shame on me. A timesheet should be about more than just collecting up hours worked or "Did Bill start on time?" Sure it gets those things and uses them for things like billing and also for examining WHY Bill did not s tart on time. But that is OK because seeing (in the post mortem) that Bill did not start on time is a good thing. Did he not start on time because he did not have what he needed? Maybe there was a flaw in the project that we can notice because we were able to look at things like Start Variance and see that Bill was delayed. Was he late in starting because he sucks as a resource? Maybe he needs to be trained. :-) My point is that Timesheets are about WAY, WAY, WAY more than just collecting the hours spent doing something. They are about a method of communicating in a very structured way about some very precise info: When did you start, how much did you do and (here is the big one for me) how much do you have left to do? I think this is the key for CCPM as Jack mentions it in his article. But it is important for CPM too! :-) All PMs need to have a solid, updated estimate of how much longer. Timesheets give you that too. In PWA it is called the Remaining Work field. I tell my customers to make sure to talk about the importance of that field with their resources when talking about the timesheet.

The other reason why information about the pure "How much work has been done so far" is NOT irrelevant is that the PM's job is not just about schedule. It is also about Cost. If all the PM gets is how much is left they will be able to do well on the schedule part but they will be blind to the cost trend of the project. Getting good information about how much work has already been done AND how much is estimated to be remaining is the only way for the PM to know how much they have already spent and how much they have left to spend. This would need to be compared to their budget in order to figure out if they will need more money or if they will need to cut features.

So I agree with Jack completely about the need for "how much longer" but I have to differ on the importance of a good timesheet in getting that info and on the overall benefits of a timesheet.

By the way if you have not been to Jack's Blog you should check it out. Very good stuff! Well except for this thing about timesheets. ;-)

The Downside to being at the Front of the Pack...

...the rest of the pack snipping and biting at your heals. :-)

As with any competitive situation in business your competitors are rarely accurate when they describe your functionality to potential customers. I have heard tons of claims over the past year about Project Server that range from the honest mistake to the sadly misinformed to the outright lie.

Honest Mistake:
Project Server 2003 REQUIRES Windows Server 2003.
I can see where people get this one. Windows Sharepoint Services must run on a Windows Server 2003 machine. So if you will be using Project Server 2003 with WSS then you do need to have a machine running Windows Server 2003. But even in this case the machine where Project Server 2003 is running can still be Windows Server 2000.

Sadly Misinformed:
Project Server 2003's licensing is cheaper but it has "hidden" costs of SQL CALs that make it more expensive.
Im not 100% sure if this is people just not knowing or trying to be tricky. Sure Project Server requires you to own SQL CALs. But so will 75% of the other PM solutions out there and 20% of the rest will require Oracle licenses (the rest run on MySQL or some other open source db or another). The database has to be served by something!

Outright Lie:
Project Server does not have a web services backend to allow for customization.
OK in fairness this MIGHT be just a function of being misinformed. But someone in the PM software business would have to have had their head firming planted in the sand to have missed the FACT that Project Server has this thing called the PDS (Project Data Service) that is a SOAP/XML web services API. Sure it has not exactly been advertised on the Super Bowl but you would have had to try hard to miss it if you were researching new features of Project Server 2002 or 2003.

The Moral:
If you are evaluating Project Server or are just starting to look around at PM software do your own homework. If you want to know about Primavera's solution DO NOT take MY word for it. If you want to know about Project Server do not take the word of a SystemCorp sales rep. My opinion is certainly valid when talking about what Project Server can and cannot do. But my opinion of PlanView’s product is not so reliable. :-)

Do you own research. There is nearly 2000 pages worth of deployment guides, installation instructions, administrator guidance, training materials and Software Development Kit documents up on the Microsoft website about Project Server 2003. Now Im not suggesting that anyone go read it all. But I am saying that if you want information about Project Server there is no shortage. Nobody can accuse the Project product team of not sharing.