They're gone? Yes, it's true. They've been removed in the 2007 release from all alerts and reminders.
Why? We had several reports where providing this link to the end user to navigate to PWA was creating problems. The base issue was which url is correct for a given user?
For example, you have a system with both intranet/extranet access or are using a mixed authentication methods (windows, forms, etc.). For each access or authentication method, you would use different urls for access.
Add the additional example of one user forwarding an alert to another user, who uses a different url for access. As you can see, the potential for a messy situation was high.
So, we removed putting the URL by default for those customers who had these situations.
For customers who do not have a mixed environment, you have a painless way to put the PWA url back on the bottom of the alerts.
To add the link to the bottom of the alert, as Project Server administrator, navigate to Settings, Alerts and Reminders. You will see the screen below. A link to PWA can be added within the email footer. When the alert is mailed, it will be treated as a hyperlink.
Deliverables is a new feature that shipped in Project Professional 2007. Deliverables provides the ability to publish key dates to a SharePoint site and for others to consume these keys dates within their project plan. This feature helps you to manage cross project dependencies. A project manager can define deliverables within their project plan using Project Professional and have the dates automatically published to a Deliverable SharePoint list within the Project’s workspace. This allows other project manager to take dependencies on the published deliverables within their own Project Plans. When there is a change with a deliverable, such as a change in the finish date, all the project managers who have taken a dependency on the deliverable get informed of the change with the deliverable when they open their project plan. Deliverables provide a way to loosely tie projects together.
This diagram illustrates deliverables at a high level:
When a project manager creates a deliverable or a dependency on a deliverable they have the option to link it to a task. When a deliverable or dependency is linked to a task, it shows an icon beside the task name and displays bars on the Gantt chart. It is important to note that the dates of the task are not tightly coupled with the dates of the deliverable. This is to allow the project manager to work with his/her schedule without altering the dates of the deliverable. It is by design that the project manager needs to explicitly update the deliverable dates. The below screen shot is a project plan with deliverables and dependencies:
So know that you have an idea what Deliverables are, let’s work through an example. The example that I like to use is the release schedule of large software development project, such as Microsoft Office, which has several beta releases before the actual shipment of the product. The overall schedule is managed in a single project plan, but there are many teams, such as Project, Excel, etc, that adheres to the overall schedule, but requires their own detailed schedule that is specific to them. An Office schedule that is just an example that I made up and has no meaning what so ever, may look like this:
Product teams are very interested in the Beta 1, Beta 2 and RTM dates and they want to be able to easily keep track of these dates. In order for this to happen, the project manager for the Office schedule must create deliverables for these tasks. Before the PM creates deliverables, they are going have to publish the project to Project Server and create a workspace for the project. To do this:
Once the project is published and the workspace is created for the project, the PM ready to create deliverables. To create a deliverable the PM will have to follow these steps:
The PM for the Office schedule would repeat these steps for each deliverable they want to create. Once they have completed creating the deliverables for Beta 2 and RTM the schedule should look like this:
As you can see from the schedule, there are red bars on the Gantt chart that represent each deliverable. There are also informational icons beside each task indicating that there is a deliverable linked to the task. Now that the PM has created these deliverables, other PMs can view these deliverables from the workspace for the project:
Since the deliverables are published to a SharePoint list, there are many built in benefits. Users can easily setup alerts, create RSS feeds, add additional columns, etc. It is important to note that if you change a deliverable from the SharePoint List, it will give the PM the option to sync the change next time they open their project in Project Professional.
PMs can also now consume these deliverables as dependences from within their own project plans. Going back to our example, the Excel team will want to take dependencies on the Beta 1, Beta 2 and RTM deliverables from the Office schedule. This time I am only going to create a very simple project plan with three tasks that represent the Excel team’s project plan. To create a dependency on a deliverable, the PM does not have to publish the project or create a workspace. They only have to do the following steps:
Now a dependency has been created that has been linked to Task A and is dependent on the Beta 1 deliverable from the Office Schedule. These steps will have to be performed for each deliverable, which in this example is Beta 1, Beta 2 and RTM. If you have a large number of deliverables to create from already existing tasks, I suggest you read my programmability post on deliverables: http://blogs.msdn.com/project_programmability/archive/2007/02/19/working-with-deliverables.aspx
You will notice that the dependency dates and the task dates are not aligned. The dependency dates are also loosely coupled with the task dates. This is shown in the below image of the Excel project where the yellow Gantt bars show the dependency dates are much further out then the task dates shown by the blue Gantt bar:Now that we have two projects, one with published deliverables and the other with dependencies on the published deliverables, let’s work through an example where one of the deliverables change. Within the Office schedule there is a deliverable, Beta 1, which has a finish date of March 20th 2007. To change the finish date to March 30th 2007:
Now go to the Excel team Project to see how this change has affected the dependency:
Note that the dependency date is now 3/30/2007 and is back in sync with the Beta 1 deliverable.
Hopefully that gives you an idea on how deliverables feature works. This feature truly provides a flexible way to loosely couple projects together that are not affected by the scheduling engine. I have only given a short overview on how to get started with deliverables. Once you start to play around with them, I am sure you will find great uses for the feature.
Previously, you received an OPML file to help you read all of the great content being created by our community. Probably, soon after, you wished you had a way to search for posts related to a specific topic.
Now you can. With the help of our Live.com's search macro functionality, I created the following custom search engine.
It will search across all of the Project Community web sites for a given topic. To learn more about search macros, visit http://search.live.com/macros
Hi, It has been a long time since my last post. Sorry for the long delay and I will try to fix this with more frequent post in the future. OK so let’s get to the topic of the day: “Resource Plans, what are they and how should you use them”.
Resource Plans were developed in response to a number of customer requests for a way to estimate corporate resource capacity when some projects are in full execution and others are still in the proposal or planning phase. Therefore, we focused on the part of a project lifecycle where the project is still just an idea or opportunity but not yet established as a project. Yes, resource plans can be used during the execution phase as well but let’s first talk about the pre-project phase.
To “create” a resource plan, all you need to do is add a resource to the list after clicking on the Resource Plan button on any Project page.
Above is a sample resource plan. These resources are linked to a project via the plan but no assignments are made within the project. Simple to create and easy to use or at least I hope you see it that way. As you can see, we are using weekly granularity of assignments in the sample. The granularity can be set from days to years depending upon your own preferences. This enables the resource manager to plan how a resource would be used if the project gets the approval to begin work. This plan uses work resources but any resource type can be assigned. With this resource plan I am demonstrating is how you can mix named resources with generic resources on the same plan.
How does this integrate with Project Professional? Well, simply stated it doesn’t. As I said earlier, these assignments are not within the project or better said they are outside of the project. The only association is through the resource plan itself. Let me guess, you want integrate the planned assignments here with other firm assignments for these same resource on other projects. Well good, capacity planning would be nothing without integration to overall resource availability. But before I dive into this topic, I think we need to see the resource plan settings pane.
All clear? I didn’t think so but without the image it may be too hard to grasp the options representing resource availability on the plan. In the feature we call this utilization calculation but don’t let that confuse you, utilization is just the consumption of availability… right? So what options do we allow? To begin with we default to using the resource plan assignments as if they were real project assignments. This means that the hours booked to the resource plan will deduct from the availability of the resource. The second option is to use the assignments made within the project and to ignore the plan assignments, which is like turning off the resource plan assignments. And the final option is to pull the assignment data from project task assignments up through a certain date after which we will pull the resource plan assignment data.
These options align with three use cases:
1. The resource plan greatly simplifies the assigning of resources and no task level assignments are needed. (frequent customer request)
2.Resource plans are used to estimate resource usage but not to actually commit resource usage; that is left to project task assignments.
3. So in the beginning, the resource plan will account for 100% of the resource commitments on the project. Then when Phase 1 begins and task level assignments are made, and then resource availability will be consumed by the project tasks until the end date of phase 1. And the resource plan will only account for the assignments in Phase 2 and beyond. This represents a rolling project plan.
OK, the last thing to explain is the setting of Work Units. Resource plans offers a new level of resource time allocation, called the FTE. To begin with though, we use the familiar Hours, Days, etc. However; these are all directly associated to minutes which is a very accurate time element. Since one of the overriding design tenets for Resource Plans was to support early planning where estimating is the normal practice. We now offer a new way to specify resource allocations and that is FTE or Full Time Equivalents. FTE is a simplification where the resource manager specifies the amount of time an average full time employee would spend and they do not need to think about how many hours are in a month or year.
Well that’s about it for today. You are probably nearing information overload if not already fully there. Therefore, I am intentionally leaving the FTE definition out of this posting. Next time I will discuss the FTE definition as this can be a full posting in itself.
The Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System Best Practices Analyzer programmatically collects settings and values from data repositories such as MS SQL, registry, metabase and performance monitor. Once collected, a set of comprehensive ‘best practice’ rules are applied to the topology. This is a command line utility that administrators can run to get a detailed report of recommended changes that can be made to their environments to achieve greater performance, scalability and uptime. The below picture shows a snap shot of my staged server after running it:
One thing that you will notice is that it does indeed cover Project Server. There are a number of best practices that are specific to Project. For example, if there has been a failure with the cubes or if there are failed queue jobs the Best Practice Analyzer will warn you of these failures.
It is important to note that this tool is a read only. It will not make any changes to your environment. You should give it a try.
You can get a copy here:
After discussing this situation with Eric Zenz, I found out we made a change in the 2007 release that makes it easier to manage who has access to your project's team site.
In 2003, you had to be on a project's team and assigned to a task to get access to a project's team site. So, everyone wound up with a "Give Access" task on the project plan. This task, though, gave everyone on this task read/write access. To give someone read access, you had to set up these people manually. If the company had this SharePoint administration permission locked down, the PM had to ask the application administrator to add these "read only" people to the team site. Now multiply this request times 600 team sites and it can get to be quite a bit of maintenance.
In 2007, we made some improvements in this regard. Resources are automatically granted read access to the project's team site when they are added to a project's team via TeamBuilder. When a resource is assigned to a task on the plan, they automatically get contributor read/write access. This makes it easier for the Project Manager to provide wider access to the team site without having to learn WSS security administration or make life interesting for the application administrator.
In case you've noticed, which you probably have, posts have been slow as of late. As we wrapped up Office 2007 work back at the end of October, we've been working hard on the Project 14 planning and rolling out a new service internally.
So, why does this matter to you? These latest activities all involve us using our own product. We are our own users at the moment.
We are using our very own Project Portfolio Server 2007 to plan the Project 14 release. Portfolio Server is being used to help us determine the business drivers that are important and how important are they relative to each other. We then model which features will contribute the most to our business drivers. It's our first opportunity as a team to use the tool for real work and for us to go through the whole optimization process.
Pradeep, one of our Senior PMs, is shepherding the process. My hope is to convince him to write about it extensively in an upcoming post. Also, expect to hear more about our experiences when Project Conference rolls around. If you want to hear, leave a comment below.
The other activity is that we are rolling out a hosted instance of Project Server 2007 internally. This way, any team that wants to use Project Server doesn't have to set up their own hardware and software. The challenge is that we don't have a "corporate" way to manage efforts or project related data. So, each team wants something different. I'm sure you are familiar with this situation.
For those of you who have done this for yourselves or for others, we are going through what you normally go through. We are experiencing first hand, security model design, login and desktop configuration issues, AD Sync set up and learning about the various and sundry ways that people use Project. All of this, will provide input and impetus to improve the product further.
As interesting experiences and observations come up, I'll discuss them. We are currently on boarding our first two groups so the real fun is about to begin! Same rule applies, if you want to hear more, leave a comment.
There's so much being published on Project related blogs, its hard to keep up with it all. So, attached is an OPML file which contains the RSS feeds for the a number of Project related blogs.
This file can be imported into and read using Outlook 2007 if you follow the instructions here: http://office.microsoft.com/en-us/outlook/HA012299401033.aspx?pid=CH100622171033
If you don't have Outlook 2007, you can also use Microsoft's Live.com as a free web based RSS reader. Once you log in using your Windows Live ID, you can click Add Stuff, Advanced options, then use the Import OPML function to create the listings. Once the listings are there, you can drag them down on the page for viewing.
UPDATE: In order to see the attachments for blog posts, you have to click on the post header to get to the details page. Then, the attachment is visible at the bottom of the post. My apologies for the confusion.