Blogroll

Month: November 2013

There is a SharePoint issue that crops up occasionally in Project Server deployments where site templates suddenly stop working. The basic gist is that the template was created after a specific solution had been deployed to the farm. After retracting the solution, the template suddenly stops working, and any attempt to provision a site yields the following error:

For the search engines: The site template requires that the Feature {blahblahblah} be installed on the farm or site collection.

With some foresight, there’s an easy fix. Well, not fix per se. There is a way to prevent this from happening:

Whenever creating a new site template, ensure that the site used to create the template is retained within the environment. After retracting the solution, create a new template from the old site and associate it with all of your enterprise project types within Project Server.

…or….

Before retracting a solution, ensure that a site has been provisioned from the latest template. After retracting the solution, create a template from the site and associate it with all of your enterprise project types within Project Server.

If you’ve already seen this error, and are looking for ways to get around it….use an older pre-solution deployment template, an existing site to create a new template, or consult with smarter folks than I.

Just remember, while it’s theoretically possible to create a site template from a site associated with a project, best practice recommends that you use an unattached site to create any new template within Project Server.

At the recent PMO Symposium, I attended a couple sessions on reporting and metrics, and each session mentioned something in passing that I thought was actually quite relevant. The basic gist was that at the strategic level of the organization, only 10 or so projects really matter. Everything else is just noise.

Not only that, but people within the organization should be able to list those top ten projects – and they should know that if there is any resource contention between those 10 projects and anything not on the list, the top projects will win. If you can achieve this within your organization, you’re doing well in terms of communicating your values.

From an executive dashboard perspective, incorporate a mechanism to flag those projects, and provide a high level overview of how they’re doing. As for all of the other projects within the organization…..aggregate them up to a more meaningful entity: service, asset, program, or strategic theme.

Well, another PMO Symposium has come and gone, this one being the third one that I have attended (the fact that I missed last year’s notwithstanding). As usual, there were a series of great conversations….the kind of conversations that happen when you put 500 PMO directors into the same room and bombard them with topics that can assist them in lengthening their tenure or increasing their paycheck by providing enhanced value to the organization.

The thread in this symposium, as in prior conferences was the inherent assumption that PMOs naturally want to be more strategic, that in being strategic, the PMO can provide enhanced value to the organization – as opposed to focusing on the less value add activities of ensuring projects come in on time and on budget, and whether or not we have enough resources to do this. The basic concept appears to be that if we’re already doing the low level activities, it’s only a hop, skip, and a jump to truly adding value by tying it back up to higher level goals.

Of course, a cynic, which I am surely not, might point out that there’s not much more that can be said about basic PMO blocking and tackling, and hence, conference speakers are moving on to the greener pastures of strategic alignment. An optimist, on the other hand, might interpret that as a sign the domain is maturing.

In this conference, there was more content on how actually to achieve strategic alignment, which I’ll summarize roughly as follows:

Portfolio prioritization and enforcing the organization’s goals on the project selection process.

Operating as a cultural standardization agent to reinforce the culture of the organization through project delivery.

Operating as a knowledge capture agent to enhance delivery and mitigate risk.

Bubbling up portfolio data to the organization to enable better decisions.

The term I kept hearing was “translation” in the sense that the PMO has to translate the low level project work into something meaningful at all levels of the organization. This may be my own confirmation bias at work, but I heard translation, and immediately equated it with “portfolio analytics,” where we take data at the lowest level of work and surface it by attaching it to meaningful entities throughout the organization.

I liked this year that there was more of an emphasis away from the “one size fits all” approach of previous years, with PMI going out on the proverbial limb and declaring that they have identified 5 different PMO models. I’m not sure I totally agree with this breakdown of PMO types – but I don’t totally disagree, so can accept it for now:

Enterprise PMO (ePMO)

Project/Program Office

Center of Excellence

Organizational Unit

Project Support Office

The organizational unit model for the PMO aligns closely with what I’ve been seeing from Gartner with respect to the role of tools to support PMOs (an area I particularly focus on, of course), where tools have now been classified in four main types to support the divergent mission of the PMO:

IT

Professional Services

Engineering and Construction

New Product Development

At the same time, if we map that back to the proposed PMO framework, we can see that while there’s high variability in the form and function of the organizational unit PMO, at a higher level of the organization, many of the PMOs begin to follow the same function and focus more on strategic alignment. So, long story short, “Yes, Virginia, there is a one size fits all solution,” but only for PMOs at a certain level of the organization. Below that, and you’ll have to tailor the solution to the specific needs of the OU – although there are certain commonalities between OUs that perform the same function, i.e. IT.

I’ll need to spend some time in another post to see how I can map the PMO framework to Jeanne Ross, Peter Weill and David Robertson’s concept of strategic architecture to see if that adds another layer of depth in understanding the PMO taxonomy and how duties are assigned within the various PMO models.

I also particularly enjoyed Bob Kaplan’s presentation on tying PMO work back to the strategic scorecard, where he essentially talked about splitting the portfolio of projects up into two main components, Business As Usual, and Strategic Initiatives. I’m not sure I entirely agree with splitting project funding into a third category of CAPEX, OPEX, and STRATEX, but I see the legitimacy in calling strategic investments out separately from the main portfolio of BAU work. That being said, I would see STRATEX as overlapping with CAPEX in the accounting world – and that the organization would game the system to map projects to STRATEX or CAPEX just to get things approved.

I’ll be posting my more specific feedback and thoughts in upcoming posts, but while the thinking is fresh, some topics I’d like to see in future symposiums might be:

The role of Enterprise Architecture in portfolio analytics and strategic support.

How the PMO can assist the C suite in defining strategic clarity through informed decision making.

Stay tuned for blog posts and presentations around these topics in the nearish future. And if you’re not doing anything next November, come on down to Miami for PMO Symposium 2014.