See Announcing Visual Studio 2010 Service Pack 1 Beta

Some folks have asked about the pwaribbon.xml file and modifying the ribbon in

Thanks to Donald for his forum posting and Marius for his swift response highlighting the resolution to this one.

There is an excellent article on the Web-based capabilities of Project 2010 at https://www.microsoft.com/project/en/us/project-server-2010-editions.aspx which does a schedule management comparison of Project Web App (PWA) 2010 compared to Project Professional 2010.

Interesting question came in today via the blog on my previous customization topic at https://blogs.msdn.com/b/brismith/archive/2010/03/15/customizing-the-project-site-in-project-server-2010.aspx and thought it worth a broader response, as it wasn’t something I had really thought about…

I was doing some investigations this week on the Resource Plans Web Service and want to share this as it probably gives more information than we have in the SDK currently – or at least pulls it together.

As the cloud environment moves from its conceptual state to a real living breathing reality, it brings with it a deep dependency to an area of IT that I predict will become central to how effectively the capability of the cloud is utilized. This same dependency underpins datacenter growth and change as well. That area is information management.

Don’t miss tomorrow morning’s TechNet Webcast: Managing the Project Life Cycle with Demand Management ! Here’s some details : Language(s): English. Product(s): Microsoft Office Project,Microsoft Project 2010. Audience(s): IT Decision Maker,IT Generalist. Duration: 60 Minutes Start Date: Wednesday, March 31, 2010 8:00 AM Pacific Time (US & Canada) Event Overview Demand Management, a new feature in Microsoft Project Server 2010, captures work proposals in one place and takes them through a multi-stage governance process using a SharePoint workflow model. In this presentation, we provide an overview of Demand Management and its importance in managing project life cycles, and we explain how to configure Demand Management and the required components. Presenter: Rolly Perreaux, Senior EPM Consultant / Instructor, PMO Logistics Inc. Rolly Perreaux is a senior enterprise project management (EPM) consultant and instructor for PMO Logistics Inc., a company that specializes in EPM consulting services and training. Rolly has more than 25 years business experience and holds various designations from the Project Management Institute (PMP), Microsoft, Compaq, IBM, CheckPoint, and CompTIA, and he has just been awarded a Microsoft Most Valuable Professional (MVP) for Microsoft Project. Rolly’s detailed dossier can be viewed at www.pmologistics.com/bio/rollyperreaux.htm , and he frequently blogs at https://rperreaux.spaces.live.com . View other sessions from Microsoft Project: Align People, Work, and Priorities If you have questions or feedback, contact us .

Greetings everyone, and happy-almost-spring. Lately I’ve been focusing on understanding the costs (in all its forms) of delivering and managing Tier 1 applications. For the sake of discussion, let’s define a “Tier 1” app in terms of reliability or “quality of service”. In a previous post , I discussed four tiers of criticality for enterprise applications. While you may disagree with some of the names, there should be little argument that there are classes of applications that are truly critical to the success or failure of a business; the so-called “mission critical” application. These apps are also referred more generically to be called “Tier 1 applications”. These applications hold a special level of importance in the corporate enterprise because their failure (measured in terms of reduced service quality or complete outages) would have a profound effect on the business including any or all of the following: Widespread business stoppage with significant revenue impact Risk to human health/environment Public, wide-spread damage to organization’s reputation Company-wide productivity is compromised Examples of these types of applications are eCommerce (amazon.com, ebay, etc.), 911 response systems, stock and commodity trading systems, and airline reservation systems (some would also put CRM and corporate email into this group too). ( Note : while some have referred to Tier 1 apps with examples such as Exchange, SharePoint, SQL, Oracle, DB2, etc., I claim they are missing the point. With the possible exception of SharePoint, these other examples support the application and need to be treated as part of the overall solution, not as the solution itself.) It’s obvious that these applications are important to the business for the reasons listed above as well as others. They represent a significant importance to the business when they run well and a huge impact to the business when they don’t. Tier 1 Apps Put Quality and GRC Ahead of Cost What I find interesting, however, is that these apps hold a special place in the minds (and the wallets) of business and IT leaders. Despite the IT maturity of an organization, companies will “invest” whatever it takes to keep these applications up and running with the highest levels of quality expected of their customers. Even for organizations that do not have a culture of IT maturity improvement, Tier 1 apps will always enjoy financial and human resource availability to ensure those apps remain highly available. While the driver for most applications in the organization (60%-80%) is cost (delivery and ongoing maintenance), Quality of Service (QoS) and Governance, Risk Management, and Compliance are foremost. The implications of this can be profound, particularly for companies that do not have a practice of IT maturity improvement. Highly mature organizations imbue the practices of service delivery with high quality, high compliance, and low risk across the entire portfolio of their service catalog, without incurring the huge costs of maintenance. Less mature organizations, on the other hand, will tend to be reactive in nature and waste resources to ensure these Tier 1 applications remain healthy. The costs incurred can come from many sources such as expensive consulting resources, inefficient, time-consuming processes, and an over-reliance on expensive technologies. In short, these organizations will throw whatever is necessary at a Tier 1 app to keep it up and running to meet any explicit or implicit quality and compliance bars exist. What to Do? Learn The Lessons from Tier 1 App Delivery and Management Regardless of how you define it, every business of any appreciable size has Tier 1 applications. Unfortunately, many IT organizations do not have a very high level of IT maturity and yet, these Tier 1 apps demand it. As a result of this gap, significant wasteful costs are incurred to keep them up and running. Where there are pockets of good, mature IT practices, they probably exist within the realm of Tier 1 service delivery. Unfortunately, what also exists is REALLY bad process too, all in service of maintaining high quality of service. In my role as an enterprise consultant for many years I’ve seen countless “all hands on deck” events when a Tier 1 app went down. There was a mad scramble to restore service, all the while work on other important IT functions was put aside. For that reason, IT organizations should look at the mature practices and policies they do have have (many of which will be implied) for their Tier 1 apps and see how to apply them across their IT service portfolio, but not simply because it’s “good practice.” The organization needs to also take a hard look at recent emergency situations as much to understand what cost is being incurred to restore service as to understand how to minimize their occurrences. By using the lessons learned from their Tier 1 app efforts (both the good and bad), IT organizations will reduce their overall delivery and operating costs by becoming more efficient in the deliver of IT services through such activities as: Rationalizing the costs of high availability Reducing the reliance on expensive consulting and support resources Becoming smarter and more targeted about information security Designing apps with the right level of service (how many “9s” are needed?) Resolving incidents more quickly with appropriate service monitoring Conclusion The overall message is simple and taken from an old adage: an ounce of prevention is worth a pound of cure. IT organizations and the businesses they support will lower their overall delivery and operations costs when they look to the best practices learned from the delivery and maintenance of their Tier 1 apps and apply them generally across their organization. All the Best, Erik Svenson, Application Platform Lead, War on Cost Team

I recently completed a study of over 500 US-based customers in which I wanted to understand: what types of applications are being delivered and managed generally, how much does it cost to deliver and manage those applications how are web services being used how well are cloud computing solutions being adopted In my first post about what I learned from this investigation, I wanted to first share my thoughts about the concept of “application criticality”. We’ve all heard the term “line of business application”. While there are many specific definitions of what an LOB app is, a generally accepted definition is: An application that is vital to running a business This extremely vague term, while generally descriptive, doesn’t get down to the level of specificity needed to understand how one LOB app compares to another in importance, scope, or complexity. In order to better understand the population of applications being delivered and managed, I needed to get to a lower level of granularity. Our team therefore defined the concept of Application Criticality to better distinguish line of business apps from each other in terms of their importance to the business as well as their relative scope of influence on the business. Below are the 4 levels of criticality and their definitions. The descriptions of these levels of criticality are defined in terms of the impact on the business if these applications become unavailable. While there may be other ways to define these classes of criticality, we find it useful to refer to them in terms that line of business owners typically care about. Criticality Level Failures of applications in this class can result in: Mission Critical