Welcome to MSDN Blogs Sign in | Join | Help

As some of you may know, I have moved onto a new position within Microsoft (over in the Mobile Devices group). I have had a great 6 years working on Project and am excited to see P12 on its way to being delivered to market.

Go to:


for the latest on P12. Just to point out the depth re the "bench" on the Project team, my replacement (Keshav) has worked on Project for nearly 10 years. P12 and beyond are in great hands with Keshav.

I will continue to post on this blog but Lidiane's new blog will be your best choice for news on P12. Thanks to everyone who has read this blog ... and to those customers and partners who have supported me and the Project team over the last few years.


I thought that this was a funny story about the Project Conference.

During Tuesday's keynote by our GM, Mike showed off multi-level undo in Project. Our VP was sitting in the audience and heard the person next to him gasp and say "Oh My God ..." The audience burst into applause after seeing Mike undo a bunch of actions. 

We had demoed this same feature for some of our Office colleagues about a year ago. Mike overheard someone in the crowd say something like "what's next? support for bold characters." There were some who had doubts whether we should stick it out and keep making a big investment in this feature when perhaps few people would really appreciate it.

Rolling back the clock to 2002, we held several advisory councils where attendees made Project support for multi-level undo a top request.

MLU (multi-level undo) has been a massive amount of work (between 2 - 3 developers for a couple of years). The complexity of being able to roll back results made by the scheduling engine is huge and not especially obvious.

It is really satisfying to get confirmation that some of the big bets made for P12 are appreciated by you, the "connoisseurs" of project management tools.

After a couple of weeks of rest, I wanted to give my impressions of the Project Conference and P12. It was great to see the big crowd and interest in Project. You could get a real sense for the number of attendees in the keynotes (over 1500) ... but otherwise the layout of the facility made it tough to feel the buzz of a big set of people. While I loved being in Seattle for the evening events, I missed the layout of the Microsoft Briefing Center during the sessions. Thanks to everyone who attended the conference. It is a big commitment in time and money. I hope that we (product group) gave you what you needed and wanted wrt technical content on P12.

On to P12 ... I am now able to talk about a few features that were kept under wraps before the Project Conference. I am going to start with features that may have been too subtle (or our presentation too fast) for folks to fully grok their potential.

1. Operations Activities: This feature is an umbrella term for the ability to create web-based task lists that support dependencies, scheduling, assignments, timesheeting, reporting, etc. We view this feature being used primarily to capture work that does not need or is difficult to manage like a project. You are provided with a very simple web-based UI in Project Web Access that lets you create the task list. In the Project Server back-end, operations activities are simply projects with a unique type. Operations activities can be upgraded so they can be edited using Project Professional.

2. Resource Plans: This feature allows you to define PLANNED work independent of tasks in a project plan. Once you have created a project or operations actitivies (even with zero tasks), you can then use Project Web Access to define how much effort will be spent by resources for how long on the project. You can express effort in hours per day, days per week, and full-time equivalents (similar to units in Project). Resource plans result in the creation of summary resource assignments. This allows the effort defined in the resource plan to show up exactly the same as effort defined through task assignments in a project plan.

These two features open up a number of new scenarios for the Project EPM Solution.

Maintenance and Operations Work

The first is the ability to now easily track maintenance work with Project EPM. Maintenance work is a "routine" activity where it is difficult to exactly predict when it might occur. An example might be applying security patches to your web server. With P12, you can create a zero task operational activity using Project Web Access. Typically you would set the start and end of the operational activity to map to your calendar or fiscal year. Next you create resource plans for the individuals (or team, I will get to that feature next post) that last all year and define the effort as maybe .1 FTE. You have now captured that these individuals will be spending 10% of their available time during the year on patching your web servers. At this point, you will have visibility into ALL the planned work coming from operational activities AND projects. So you get a complete picture of where your resources are planned to be utilized.

How about tracking actual time spent on operational activities? With the new time tracking feature in P12, team members can simply add a row on their timesheet for the operational activity and enter time spent on the activity. You can do this at the project level with no actual assignments on the project. This gets pushed through the reporting system. Now, you can take a look at actual effort spent on the operational activity (coming from timesheets) against the planned effort (coming from resource plans).

This all gets done using a web browser, without Project Professional, and without a SINGLE task in the project plan. The user interface is so simple that no-one should be able to legitmately complain that the UI or process is too complex for them to report planned and actual effort. AND all this functionality is exposed through the Project Server Interface, so you could write your own UI (or synch to your own existing systems) to capture resource plan, operational tasks, and timesheets.

These two features really do enable any organization at virtually any level of project management maturity to begin collecting information on what work is planned, which resources are allocated to that work, and how actuals compare to plans. This opens up a level of visibility and control that was very hard to get in prior versions of Project. And unlike competitive projects, operations work completely fits into Project Server reporting PLUS it is easily upgraded so you can start using Project when operations work require more project management.

Rolling Wave Planning

Who has ever done the following? You are asked to build out a project plan. You know the detailed tasks for the first 30% of the project but the rest of the project is only understood at a high level. But folks want to know the planned resourcing levels for the entire project. So you end up creating a "dummy" sub-task under the summary tasks in the future and assigning resources to them. Later, you create a real WBS under the summary tasks and divide the work formally on the sub-task onto the real tasks. This is a real pain.

In P12, you can represent a project and its potential resource needs from day one w/o any knowledge of how you will get the project done (i.e., a WBS). You create an operational activity with no tasks, just a start and finish date. Then you create resource plans. At this point, you can go through a project review/selection process. As you add details to the plan, you upgrade the operational activity to Project professional and adjust the resource plans so they are only used for the latter parts of the project where you do not yet know the tasks.

This really does give you the best of both worlds. You can quickly capture high-level resource demand while also being able to switch to detailed tasks. Instead of needing to edit all those dummy tasks, you manage one resource plan per resource on the project.

These P12 features are going to enable folks to capture project ideas and resource demand far earlier and easier than ever before. Again, you get the same great reporting features in Project Server from operational activities and projects. Plus operational activities are easily upgraded to projects when you are ready to build out a detailed project plan.


IMO, these two features alone completely change the range of customers who could benefit from Project EPM. With P12, you have the ability to capture all the work going on in your organization ... and can do so with very low complexity = web-based (no deployment issues) and simple UI (very limited training required). Once you have all of your resource demands understood, the quality of your project and resourcing decision-making is going to improve significantly. When you add these new capabilities with the new portfolio management technology that we have acquired from UMT, you really have a big leap forward in the value of Project EPM for making decisions at the CxO level.




The Grand Ballroom at the Westin was PACKED for Mike's keynote this morning at The Project Conference. I am not sure how we are going to fit more people for SteveB's keynote on Thursday.

Mike showed off the work in Project Pro on the local (aka active) cache with a couple of Pro over WAN demos. Project 12 is fast over WANs ... even with 100+ sec latency and large projects. Multi-level Undo in Project drew the biggest applause. Mike's session and Keshav's P12 overview had so much content that I think folks were overwhelmed with information.

I talked to a bunch of folks about the new server-side scheduling engine. Folks seemed really interested in how they could use this feature to capture operations and maintenance work going on in their organization.

All in all, it was a great start to The Project Conference. Tommorow is "drill-down" day. We have a ton of sessions that go deep into P12 and Project Server.

My picks:

PO230: Managing Programs = P12 has made some huge improvements in this area.

DC210: Configuring Project Server = Set-up and install have changed significantly and for the better. This session will definitely raise the odds that you will get Project Server installed and working.

D310: Events & Workflow = This is quite possibly one of the BIGGEST improvements in P12. The addition of eventing and a built-in workflow engine really expands the types of solutions that can be built on Project Server. IMO, no other solution on the market will provide the flexibility and development tool support for custom biz process (in the project mgmt market) as Project 12.

PMP310: EPM Reporting = Project Server 12 is a much more performant, richer, and easier to integrate reporting platform. For many customers, reports and improved visibility are the reason driving EPM deployments. P12 enables better reports to be generated with far less effort.


Tuesday is an overview day. We wanted to help folks get a high-level understanding of the scope of improvements in P12. It is a massive release.

Here are a few recommendations re sessions at Tuesday's Project Conference:

- Mike Anguilo KeyNote (8:15, Grand Ballroom): Mike will do a whirlwind tour of P12 plus possibly have a few interesting announcements. Yea, it's early but with nearly 30 days of continuous rain in Seattle you stop really paying attention to whether its morning or evening.

- Project Server Architecture (11:15, Grand Ballroom): Patrick does a good job of giving you an easy to digest overview of all the great new features in Project Server 12. If you are interested in Project EPM, this is a cannot miss session.

- PSI Overview (2, Cascade): Ameya and Phil will give you the details on Project Server's new programmability story. While I think P12 has great features in every direction, I believe that perhaps the biggest story is around the programmability provided in Project Server 12.

- Timesheet Overview (3:30, Grand Ballroom): David will provide you an overview of the "new for P12" time tracking solution. You gave us ... feedback on time tracking in Project 2003. Attend this session and let me know if you think that we heard you.


We are just a bit more than 12 hours away from the start of the Project Conference. This is definitely the coming out party for Project 12 ... though this year's conference also includes some great Project 2003 sessions and a number of sessions focused on best practices in project management (no "tools" focus). I saw some of Mike Anguilo's keynote demo and it looks great. It is amazing to see how far the product has come since the P12 Airlift back in September.

From an "in the trenches" perspective, we have spent the past 3+ months focused on finding and fixing bugs. While you can never completely shut the door on adding new features, we have largely held the line on adding scope and put our horsepower behind increasing and improving stability.

After spending the past 2 - 3 weeks working on demos with Project Professional, I like what I see. Stability is good in virtually all areas ... though we have lots of room for improvement. While we are not publicly sharing our RTM dates, it is safe to say that we have several months ahead of us dedicated to improving stability and performance. P12 will have the longest stabilization period of any recent Project release.

Our first Project Technical Briefing (in 2002 I think) had about 200 attendees. We are expecting close to 1500 attendees at this year's conference. It is great to see the interest and excitement in Project grow. I hope to see or run into you over the next few days. For those of you not attending, I will be posting to the blog over the next few days.


Beta 1 kept us quite busy last week so it ended up being a slow blog week. With the weather back to normal in Seattle (cloudy, wet, cool) and Beta 1 almost ready, I have a bit of time to talk about one of the biggest changes in P12 = the Project Cache.

A short detour into history: Project introduced the ability to save to database way back in Project 98. Project used ODBC to handle read/write to db. Lots of folks leveraged this functionality to build EPM solutions. In 2000, we opted to leverage this functionality to build the Project 2002 EPM solution. Project Professional called a set of web services on Project Server to authenticate the user and create a connection (and a set of SQL views) between Project Pro and SQL Server. Once this connection was established, Project Pro 2002 communicated with SQL Server in largely the same way that Project 98 communicated to SQL Server.

This design works fine in a LAN where latency is minimal (generally in the 5 - 10ms range), pipes are big (10Mb and up) and connections are reliable. In WAN scenarios, conditions change. Latency can be indeterminate; for example, if you are using a VPN across the Internet. Even on leased lines, WAN latency is often above 50ms. Pipes range from small to OK (256K - 5Mb). Connections can be sketchy. As many of you know, customers have typically deploying Windows Terminal Services to support Project Pro users who need to connect to Project Server over a WAN.

With P12, we wanted to enable project managers to have a great rich client experience from any location. This required us to rethink how Project Pro interacted with Project Server. We assumed the following: (1) network connections drop and the I/O between Pro and Server needed to be resilient to drops in connections, (2) WAN pipes have lots of latency and limited bandwidth so I/O needed to be as efficient as possible, and (3) users should be able to largely ignore the state of their network connection = things should just work w/o user intervention.

Project 12 introduces a new client-side cache and caching service. Project Pro interacts directly with the local cache for opens and saves. The caching service then handles moving the changes between the client and Project Server. Project Pro 12 never communicates directly with SQL Server. The caching service interacts with the Project Server using SOAP calls made to the Project Server Interface (PSI) web service = calls are made only through port 80. The PSI then serializes the data to SQL Server.

The caching service works based on differences and is asynchronous. When a project manager makes a change to a project and closes Project Pro, the project is saved to the local file system and a set of messages are created for the caching service based on the differences made to the project. These messages are then sent to Project Server. The project manager does not need to wait for the messages to be sent before moving onto other work. The caching service works in the background.

The caching service works closely with the Project Server queue. A project save may result in several messages being sent to Project Server. A "valid" project save requires all of these correlated messages/jobs to be successfully processed. The Project Server queue tracks the processing of the correlated jobs. Once all of the jobs in the same correlation are successfully processed, Project Server communicates with the client which allows the caching service to release the messages. By transacting the cache messages and saving projects 1st to a local cache, Project Pro I/O is highly resilient to low quality network connections.

These services also work with centralized data. For example, changes to custom field look-up tables or enterprise resources are moved from the server to the client in the background. Users can now boot Project Pro and connect to Project Server and get started working immediately. Updates are sent to the client in the background.

The user experience is simple, especially once you have opened projects once. Users interact with their local cache for opens and saves. Their cache is refreshed from the server whenever they are able to connect to Project Server. Projects save quicky to the local cache and project managers can control when to push the updates to Project Server. Project is only locked while it saves a project to the local file system.

The IT Professional experience is equally simple. Terminal Services are no longer needed to support remote Pro users. Pro I/O is transacted and highly reliable (= no lost plans based on someone accidentally closing their laptop in the middle of a save).

In our early performance testing, Project Pro 12 I/O is significantly faster than Project 2003 EVEN when Pro is opening a project for the 1st time. Perceived performance is then as fast as saving to the local file system.

We think that the Project Cache (final naming is TBD) changes the rules of the game. It allows users to have a rich client user experience + the "mobility" advantages of saving to a local file system (try that with a thin client!) with the relatively light network footprint of a web application. Customers no longer need to choose between a great user experience and a low network footprint. You can have both with P12.

We are hard at work finishing up Beta 1. Beta 1 is a closed, by invitation only "technical" beta. I am feeling reasonably good about the Beta. I would like to take another 4+ weeks to fix bugs. But it is important to get feedback on the feature set as it stands.

In any case, my post rate has slowed down as we do daily "triage" of bugs for Beta 1 and wrap up our planning for Beta 2. I apologize if the content has been a bit stale. I have a couple of ideas for posts including more info on the "Active Cache" (final naming is TBD) feature for Project Pro I/O and how to use webparts with Project Server.

I have been receiving a few questions from folks re product evaluations and support questions. Where I can quickly fire off an answer to your question, I will respond. For longer, more complex questions, I will unfortunately not be able to help out much ... there are just not enough hours in the day (as I wrap up another 14 hour work day!). MVPs in the Proj community and Product Support are great sources of info for the current versions of Proj. For those of you in the Project 12 Beta program, BetaPlace is also a good source of info.

With Project Server 12, we really wanted to expand the range of our reporting functionality. A key strength of the Project EPM Solution is the ability to define key fields for projects, resources, tasks, or assignments and then enforce use of those fields in the Project desktop client. These fields are then used to create reports across projects and resources.

In Project 2002 and 2003, we made use of an enterprise version of the Global.MPT file to define the custom fields to be used in an organization. This inherited the limitations of the Project client wrt custom fields. So you ended up with only M text fields, N date fields, O outline code fields. Needless to say, every customer or partner event would include a request from folks to add more custom fields.

For Project 12, we redesigned enterprise custom fields as a server-side feature. You can now define enterprise custom fields using PWA or via the PSI. We support effectively unlimited enterprise custom fields for all of our field types. This support extends to the Project Pro client.

Per the prior post on server-side scheduling, updates to a project plan are now done on the SERVER. This includes recalcing the values of custom fields, including formula fields and graphical indicators.

So the enterprise global is now really only used for UI customization features like views, filters, etc. We think that the overall story for custom fields in P12 is a big win and will provide considerably more flexibility to customers. 

As we begin each product cycle, we take a look at customer feedback from users of the prior version + folks in our Beta program. With Project 2002 and 2003, customers were fairly unanimous in wanting to eliminate the "round-tripping" of actuals through Project Professional.

In Project 2002 and 2003, project managers can publish assignments from Project Pro to Project Server. Team members used Project Web Access (PWA) to then provide updates on the status of those assignments (via % complete, remaining work , or hours per day). Project managers then need to log into PWA to see the submitted updates and then open Project Pro, send the updates from Project Server to Project Pro via an XML document, reschedule the project using Project Pro, and then save the updated schedule from Project Pro back to Project Server.

The core issue driving the need to round-trip was the need to reschedule the project plan based on the actuals submitted by the team members. Since only Project had a scheduling engine, actuals needed to be moved from the server down to the client, rescheduled on the client, and then saved back to the server (so reports were up to date). To eliminate round-trips, we needed to build a server-side scheduling engine.

Sounds simple enough. CPM schedulers are easy enough to implement. However, we had a few challenges: (1) we needed to handle high peak loads w/o bringing the server to its knees = 100s of project managers trying to update their project plans at the same time, (2) we needed to recalc custom and formula fields ... not just task start and finish dates, and (3) we needed to recalc and update resource availability based on changes to the project schedule. Netnet, we needed to build a server-friendly version of our scheduling engine that could also handle much more than just task start/finish dates.

Project Server 12 includes a set of new scheduling and calc technologies. These technologies are exposed via a set of PSI (Project Server Interface) methods. These methods allow you to create, read, update, delete, and reschedule projects + tasks and assignments within the project. Server side scheduling takes advantage of the Project Server Queue. This allows Project Server to accept large #s of concurrent scheduling requests and supports processing the requests based on CPU availability (and priority of the queue job).

From a project manager's perspective, they can now view submitted updates, preview the impact of the changes on the project plan, and then update the plan ... all using a web browser and Project Web Access.

We have built a number of additional PWA features that take advantage of the new server side scheduling in Project Server 12. I will talk about the new features later this year (after Beta 1) and you will see server side scheduling and some related, cool new features at The Project Conference in January (Seattle, USA) and February (Munich, GER).

Adding server side scheduling to Project Server was A LOT of work. We think that it will significantly improve the usability and performance of Project 12. Once partners get their hands on a beta of Project Server 12, we will begin to see entirely new types of project and resource management apps developed on this technology.


When we began P12, we started with thinking how we could improve performance and scalability, move Project Server extensibility to a "standard" Microsoft toolset, and take some of the complexity out of configuring Project Server farms. After about 6 months of planning work, the Proj team was reorganized into a larger Office team with WSS (Windows SharePoint Services), SharePoint Portal Server, and CMS (Content Management Server). The new organization gave us a chance to look at how we could share development resources and deliver a consistent IT professional experience across the Office servers. While I think P12 has a ton of cool, new functionality, I suspect that the shared components across the Office servers will have one of the biggest impacts on readers of this blog.

So, what do I mean by "shared components":

1. First, Project Web Access is now built on WSS. Specifically, PWA is a site collection on a WSS virtual server. This means that WSS MUST be installed on every Project Server. From an extensibility perspective, this means that PWA is made up of bunch of webparts that can be mixed and matched with webparts from WSS, SPS, and other Office servers. We are looking hard at supporting cross-part communication. Aside from the usability gains (customizing the PWA UI is no different than customizing WSS or SPS), extending the PWA UI will be much more like working WSS or SPS.

2. Project Server and the other Office servers leverage shared setup and configuration management. This allows you to define UI servers and application servers in a server farm, with load-balancing within each tier. You can use a single web-based console to manage the entire farm and selectively turn features on for any server within the farm. This simplifies managing a Project Server farm AND really simplifies managing a farm with (for example) SharePoint Portal Server and Project Server.

Note: This does NOT mean that core project data is stored in the WSS content database. Project Server 12 has a very rich set of application services which interact with our own db.

3. Project Server and the other Office servers share authentication; specifically we leverage the new Whidbey (.Net Framework 2.0) authentication providers. So far, we support AD, ADFS, and SQL (forms-based) providers. This means that you can turn on forms-based auth and it will work across Project Server AND WSS. This should be good news for folks who may have deployed NDS (Novell Directory Services).

4. Project Server and the other Office servers share monitoring services. Project Server will ship with a new monitoring technology (ULS) that supports unified logging across a server farm for all the Office servers running in a farm.

These changes (as well as others in this area) have added up to quite a bit of development work. I think that the investment will pay off in the short- and long-term. We (Proj team) can concentrate on application services rather than building common platform services (like configuration management). Customers and partners are able to learn ONE set of IT Pro tools across all the Office servers.

Project 12 expands the range of, reports supported on Project Server ... and greatly simplifies the process of building reports on Project Server. Let's start with Project Server 12's database architecture. Project Server 12 has four databases: Working/Draft, Published, Reporting, and Archive. Project Pro opens/saves (through the PSI) to the Working database. Projects in this database are only visible to the project manager. The project manager can "publish" a project which copies the project's data into the Published database. Project Web Access views are driven off the Published database. A Reporting Data Service (RDS) listens to events for published projects/resource edits/calendar changes/etc. and moves data from the Published db to the Reporting db. The Reporting db is a relatively flat, denormalized db that is report-friendly. The Cube Building Service (CBS) has been changed so it now builds the Project Server OLAP cubes incrementally from the Reporting db. This nets out to much faster, responsive cube builds. Finally, the Archive db is used to support fast backup and restore of projects.

Project Server 12 includes support for SQL Server Reporting Services. You can now reference a Reporting Server and drop Reporting Services webparts into PWA. With the Reporting db, it is easy to create briefing book reports and charts against Project Server data. The Reporting db also supports fast reads of lots of data ... this in turn makes is much easier for partners and customers to build custom reports that combine Project and 3rd party system data.

The Project Server OLAP cubes are significantly enhanced with cubes created for project, resource, task, and assignment data. Cubes now include data from both Project Server and WSS = issues and risks. This really expands the range of reports supported in the Portfolio Analyzer.

Pre- and post-events are fired by both the RDS and CBS.

So, Project 12 includes:

- graphical, interactive project reports in the Project Center

- banded reports (aka briefing books) and charts using Microsoft SQL Server Reporting Services

- pivot-table and chart reports using Microsoft SQL Server Analysis Services.

- integration with reporting features coming from other Office servers.

And, yes, Project Server 12 will run on Microsoft SQL Server 2000 and 2005.

The net result is that P12 delivers way more reports out of the box and delivers a rich reporting toolbox for partners and customers to develop custom reports.

A nearly universal element of EPM (enterprise project management) deployments is the implementation of custom business processes. Each organization has their own methodology for proposing projects, asking for resources to fund or staff a project, taking dependencies, changing dates or scope, etc. P12 adds server-side events to support customers in building business processes tightly integrated into Project Server.

P12 provides Pre- and Post- event for most PSI methods. Pre events are fired before data is saved to the database. They are synchronous and allow a method to be canceled. Post events are fired after the data is saved to the database.

Event handlers (code you write) are implemented as managed code using the .Net Frameworks 2. Each event can support multiple event handlers. You can specify the order in which the event handlers are executed. Event handlers are deployed to the application/middle tier servers in a farm.

For more complex business processes, you likely will need a workflow engine. As mentioned in prior posts, Project Server 12 is built on Windows SharePoint Services (WSS). WSS will be shipping with a hosted version of the Windows Workflow Foundation, a new workflow component in Windows Server. Windows Workflow Foundation provides an orchestration engine and a framework for eventing, queues, authoring, etc. The workflow solution provided by WSS uses WSS lists and document libraries as queues. Office 12's enterprise content management (ECM) features are built on this new workflow infrastructure. The net is that you can build workflows around state changes of list items and doc libs.

When you put the PSI together with Project Server Events and the Windows Workflow Foundation, you end up with a rich platform for building custom business processes ... and this can all be accessed easily from Visual Studio.Net. We are working hard on a few surprises for The Project Conference that will show off how you (customers and partners) can leverage this platform. The demos should be cool!

Thanks to Ameya for the content for this post ... courtesy of his presentation at the P12 Airlift.

Just as a quick reminder: I appreciate all your comments and I do read them at least once a week. Now and then, I will roll up and post answers to the PLATFORM questions. I won't respond to questions around UI or application features until at least after Beta 1. I have more than enough content on the P12 platform to keep this blog busy for several weeks!

I took a quick pass through comments on the blog this morning. Until Beta 1, I am going to focus on responding to platform/infrastructure questions and steer clear of feature questions.

Is the PSI backward compatible? Will code written against the PDS work against the PSI? How about PDS extensions?

Strictly speaking, the PSI is not backward compatible. That said, most of the PDS methods that still make sense in P12 have similar methods in the PSI. If you wrote to the PDS, your code won't change much.

When we started P12, we decided to improve Project Server's extensibility. In our minds, this meant moving to ASP.Net and fully embracing web services and .Net in our development. Project Server 12 is completely written as managed code. Our clients (Project Pro, Project Web Access) ONLY interact with Project Server through our web services = the PSI. We opted to use ADO.Net datasets in the PSI. ADO.Net supports typed datasets. In VS.Net 2005, this makes the developer experience really sweet with the PSI. You get full IntelliSense on the datasets returned by the PSI and changing a project/resource/task/assignment/custom field/etc. is as easy as changing a field in the dataset and passing it back to Project Server.

Here is the net. The PSI is a modern and very developer friendly set of services. We think that it is a big improvement over the PDS. We definitely recognize that this will create some migration pain for folks using the PDS. However, the enhanced functionality of the PSI will enable you to get rid of lines and lines of code (especially in PDS extensions) and move to a a fully supported set of PSI methods. We are behind the PSI as our long-term developer and extensibility story.

How is Project Server integrated with Windows SharePoint Services? Is the integration better than in previous versions?

In P12, Project Server is tightly integrated with WSS. The Project Web Access UI is now a WSS application. You can fully customize and extend the PWA UI using the WSS webparts features that you know and love.

Server set-up, configuration management, authentication, backup/restore, monitoring, etc. are all shared services used by WSS, Project Server, SharePoint Portal Server, and the other Office servers. This is incredibly cool as it allows you to manage these servers together as a single farm. IT activities like dropping a new server into a farm are incredibly easy using the shared infrastructure.

I came to the Proj group from the BackOffice Server team in 2000. In Office 12, we are really delivering on the vision and dream of BackOffice = provide IT pros a unified, common set of tools and services for developing and managing applications built on the Microsoft platform. See us at the January Project Conference and I promise that you will see some great demos of this infrastructure at work.



I am back up for air!

I just spent the past 7 days and about 100 hours (yes, it was an insane week) pulling together a demo for the P12 Airlift. The Airlift is an event for folks participating in our Technical Adoption Program for P12. You can consider it a warm-up for the January (February in Europe) Project Conference. We have about 200 partners and customers here in Redmond (just across from the offices of the Proj product team).

While I am exhausted from the last week, I am thrilled with P12. How come?

1. The scope of this release continues to amaze me. I filled a 30 minute demo and literally touched on MAYBE 20% of the new stuff in this product. Look at the desktop or web client or server and you see new features everywhere.

2. The features in the release continue to resonate with customers and partners. Folks agree with our priorities ... even if they still have some features that they would like us to do in P14. Hey, we need job security, too!

3. The state of builds is pretty damn good given that we are about a month out from locking down for Beta 1. Most of the features work in any build that you pick up. Where I ran into bugs in setting up my demo, folks on the team already knew about them. Do I wish things were even more stable? Sure. But given the scope of this release, we are looking good.

A few features that generated spontaneous applause in the demo: Multi-Level Undo, Recalc Change Highlighting, Server-Side Project Updates

Give me a couple of days to recover from the demo push and I will post more on the PSI (Project Server Interface) and Server Side Events.

More Posts Next page »