Adding Yammer to Project 2013 Workspaces

Yammer is the greatest thing since sliced bread, automatic toll passes, and half price fajita night – or so I’ve been told.  For those of you not familiar with Yammer, it’s Microsoft’s solution for social networking and collaboration.  I am sure folks in Redmond may cringe when I write this, but imagine Yammer as a combination of Facebook and Twitter, but where the information and who can see the information is controlled by the organization.  This gives us all of the free wheeling knowledge management of social networking tools, but none (well, less) of the risk that this information walks out the door when I’m not paying attention.

What gets a bit confusing is that there’s a fair bit of overlap between Yammer (a recent acquisition) and the out of the box SharePoint social functionality.  That overlap hasn’t quite been rationalized as of yet, and is the topic of much speculation.  For now, note that there is a quarterly refresh of the roadmap for Yammer and SharePoint (link to the last one), and if you’re reading this post more than a couple months after it was made, it’s probably out of date due to the continuing convergence of the two investments.

This post isn’t intended to cover the differences between the two, as that topic has been extensively covered in other blog posts.  Instead, this post has me putting on my project and program manager hat and reviewing a couple of use cases in which Yammer could make my life a lot easier.

One particular use case is that I can extend my Yammer network to include team members that are outside of my corporate network and who don’t have access to the SharePoint site.  This provides an easy collaboration platform to augment the SharePoint site and Project Server.  Additionally, Yammer has a much larger presence in the mobile world, which means I can now participate in the project discussion easily from my mobile device.

This leads to one of the key elements in Project Server that, in my opinion, has been lacking for the last couple versions.  Specifically, Project Server has long had a gap in capturing the project narrative, the human story behind the status reports and the projects.  Yammer seems to be a great method of capturing and surfacing the narrative – and supporting the kind of asynchronous collaboration common to distributed project teams today.  This also augments the onboarding process as team members may join the team and quickly get caught up on the major discussions.  Think about how you can augment your requirements clarification discussions with specific hashtags for the requirement.

Adding Yammer to the Workspace

Adding Yammer to a workspace in 2013 is pretty simple.  Basically, go to the site, add an App, and select the Yammer app from the SharePoint store.

It would, of course, be nice to have the Yammer app as part of my site template so it would be provisioned automatically whenever I create a new project.  Unfortunately, it looks like we’re not quite there yet in terms of the roadmap, as when I tried to create a site template containing the Yammer app I got the following results:

The main issue I see there is that I don’t believe it’s possible to programmatically provision a Yammer group for each Project site that is created.  I’m not sure it’s possible at this juncture – but am relatively certain it’s in the roadmap.  On the other hand, I’m not sure it would always be desirable to automatically provision a Yammer group for each site, as there may be some thought required on how to architect the Yammer network.

As I’ll talk about a bit below, we would need to make the decision as to whether the group should be part of the internal corporate network, an externally accessible network – or even if we want to incorporate the project specific discussion into a larger group, for example, to support a program management model.

Configuring the Yammer App

After creating the new site and adding the Yammer App, you’ll be required to log in to Yammer and configure the Webpart.

Logging in to Yammer with an existing account, I get the option to configure the Webpart.

You’ll see that the Yammer app has three options when it’s first added to a page:

1. Connect to an existing Group.
2. Connect to the Home Feed
3. Connect to a comment feed on this specific site (i.e. a Group created for this site URL)

Internal Discussions

I’d submit that the most common configuration would be to simply create a Yammer group mapped to the site URL.  In the case below, I create the Yammer group as a comment feed.

…and within seconds have a discussion group created to support my Project.  Note how this defaults to my internal organizational network, Project North America.

Logging into Yammer.com directly, I can see a new group has been created for the site URL.

The project team members may now collaborate and have conversations within Yammer, and I can see (and eventually search) the results within the SharePoint team site.  Users can also post documents to Yammer, which don’t get fed over to the SharePoint site, which presumably is also an issue on the ongoing roadmap for integration between the two products.

The value of Yammer in this case is to 1) provide a useful collaboration platform and 2) to provide a central hub for team members involved in multiple projects and/or groups to collaborate – and then send the information back to the Project Site.

External Discussions

What if I want to include external collaborators?  In this case, I go into my Yammer administrative interface and create a new network.  Below, see that I have created a network to support Project North America Collaboration.

Once the network has been created, I can create groups within it and send invitations to anyone with an e-mail address.  They would then receive an invitation to create a Yammer account (if they don’t already have one) and Bob’s your uncle, they’re collaborating on your project.  The trick here is to create the group in an external network within Yammer – and then go configure the Yammer app on the project site.

This feature proves to be a bit more interesting to me as it enables a number of useful scenarios:

1. I have a project with both internal and external stakeholders.  Rather than go through the efforts of getting access for my external stakeholders or creating an extranet site outside of my corporate firewall, I can use my project site for internal communication, and then provision a Yammer group to support external communication.  I place carefully controlled documents on the Yammer site, such as policies, procedures, and content that would not be considered sensitive.
2. I am supporting a joint venture project where we have multiple project sites, each one within the specific joint venture partner companies.  Yammer then provides the central collaboration to knit these sites together.

Other Models

A couple other models that may be enabled:

1. Use Yammer to support program management.  While each project will have a Yammer thread, I can review all of those in a consolidated perspective from the program management office.
2. Use Yammer to support application management and integration functions.  Many organizations struggle with Release Management, and with the interactions between multiple releases.  With Yammer, I could tag threads by application or environment, and informally use this to track activities that could impact system availability.  Or imagine that I have an application specific discussion group for SAP, and surface that on the project page so that users are aware of upcoming application changes.
3. In an oilfield management example, I could capture the equivalent of the daily operations call and making it available for team members to refer to.

Hybrid Models

In the interest of being thorough, I figured I’d test out the possibility of adding two discussions to a Project site: one for internal discussions and one for external discussions.

Turns out this is indeed possible.  I’m not sure anyone would end up doing this, as it would seem to me that I would forget which discussion group I’m on and just post wherever I have my cursor.  Still, a good thing to know.  And again, once I start having multiple threads on a single page, I can use this to capture the daily signal traffic that I need to know to do my job, but that I don’t necessarily need to pay close attention to all of the time.

Not sure what my conclusion is other than that you can definitely see the value right now, and you can definitely see the potential for value to be greatly increased through a tighter integration with SharePoint and Project Server.  Stay tuned for most postings in this vein in coming quarters to periodically reassess specific project management use cases in the integration road map.

IT Portfolio Optimization Leads to….the Cloud?

I’ve spent some blogging cycles this week talking about the evolution of IT portfolio selection processes – specifically that there is a natural maturity curve from what I am calling a tightly coupled model of fragmented IT delivery and a decoupled model of consolidated IT delivery.  I’ve also pointed out that there’s almost a chicken-egg relationship between IT portfolio optimization and the IT funding model.

Illustrating the Coupled Model

Let’s take a look, shall we?  To illustrate this point, let’s say that our software vendor, in this case Microsoft, follows a tightly coupled funding model.  In this model, the customer may have a need, say, to manage agile projects in Microsoft Project Professional.  The customer goes to his Microsoft account representative and says, “Can you create an agile function, specifically tailored to our requirements?”

The Microsoft account representative goes back to Redmond and chats with the Product Team.  She goes back to our customer and with pinky firmly planted next to her lips does her best Dr. Evil impression by telling the customer that this can be done, “for 1 million dollars!” Chortle, chortle.

Now, our customer is no dummy.  He knows that while he needs this agile functionality, he doesn’t “need need” it.  He can wait.  He knows some other customer will step up and pay to develop the functionality he needs, and until then he’ll just make do.  In fact, he’s read books on Game Theory, and knows that if he just waits long enough, he can reap the benefits of someone else’s investment.  In the meantime, maybe he goes and buys something off the shelf that sort of meets his needs and doesn’t need to hit the IT radar.

What’s the moral of this story? 

• New features won’t get implemented until long after they’re actually desired. 
• Business units play games to try to push the costs off on other units. 
• The net result is that IT is playing catch up to the business.

…And the Alternative

What about the alternative?  In this case, and this is purely hypothetical, Microsoft has a large customer base for the product and bills by the user, say in some sort of arcane licensing scheme that only the high priests of the Temple of LAR understand.  Microsoft can relatively accurately predict licensing revenue for the next year, and strategically decide to set aside a percentage of that revenue for further investments in the product.  That sets the stage for the investment portfolio.

Our customer again needs agile functionality, and again approaches the Microsoft account rep.  This time, when she goes back to Redmond, the team agrees to throw the request into the feature backlog.  When the annual planning cycle rolls around, they perform a survey of their top clients and prioritize the feature according to the results.  The priority dictates where the feature falls in terms of absorbing a portion of the available investment portfolio.  Assuming the feature is ranked high enough, the team develops it, and makes it available through the SA ritual practiced by the priests of LAR.

This latter example is what I am calling a decoupled model.  Features are developed and prioritized within the constraints of an investment portfolio, and not individually as requested by the business. 

Here’re a couple characteristics of a decoupled IT portfolio selection model:

• Projects are bundled into logical programs that leverage economies of scale to deliver capabilities across multiple business units.
• The program bundling supports consolidated investment in the platforms upon which processes are enabled.
• IT is proactively identifying what the business will need in the future, and incorporating that in all ongoing service design activities

To the Cloud

…which means that to accommodate this economy of scale, we need to find a more mature IT funding model.  Slicing and dicing our portfolio at the project level and funding at that level from our business units doesn’t enable us to get the consolidated benefits that a decoupled portfolio can deliver. 

Perhaps a user based revenue model doesn’t apply as many users end up not using the solution, or end up using the solution less than more advanced power users.  In this world, to make things more equitable, we may need to find a different funding model, something like transactional costing.   In transactional costing, the cost of developing and delivering the service is recovered using metering.  The respective business units pay per use, and in return get a solid service and don’t have to worry about more complex cost models.

Sound familiar?  The logical conclusion of that decoupled model is the cloud based model.  IT portfolio optimization maturity inevitably leads to the cloud or at least a cloud-like decoupled service model.

WordPress E-mail Alerts Down

Just an FYI that if you’re reading this post, you’re probably not reading it by e-mail.  It looks like the WordPress e-mail subscription functionality is taking a personal day.

In the meantime, hopefully this saves someone from spending time checking their spam folders.

I could post the link to the WordPress forum discussing the issue, but let’s face it, it wouldn’t matter.  You’ll know it’s back up and working when you start getting e-mails alerting you to new posts.  In the meantime, I would encourage you to think about how today’s world is too reliant on e-mail – unless, of course, you’re not actually reading this, because, well, you rely on e-mail for your blog reading.

Strategically Decoupling Your Second Tier Portfolio (Part 2)

In yesterday’s post, I introduced the concept of a tier 2 portfolio, and how the concept of strategic coupling works in a tiered portfolio.  This post continues that discussion with an overview of a decoupled portfolio.

A decoupled portfolio means that IT understands where the business is going, and instead of reacting to that, makes plans hand in hand with the business to achieve those goals.  In a decoupled portfolio, the IT organization identifies a series of strategic drivers that guide investment programs to support the business.  These investment programs, in turn, provide the governance framework to a series of projects that better position IT to deliver effective, efficient services to the business.

Some characteristics of a decoupled portfolio are that:

• IT is proactively identifying what the business will need, and preparing those capabilities in advance.
• These proactive efforts end up being bundled into programs, where each program is designed to enhance specific capabilities.
• As a secondary benefit of bundling efforts into programs, IT is better positioned to invest in options assessment, i.e. to invest in alternatives analysis to determine the optimal approach to developing a specific capability.  The budget for such efforts may be attached to the program as opposed to waiting for business funding.
• There is significant investment in shared platforms to support business projects.  Coordinated investment replaces piecemeal investment in shared platforms.

The Role of Programs in Decoupled Environments

In the absence of a defining business program structure, a decoupled portfolio naturally lends itself to the bundling of projects into logical programs defined by IT.  These programs, in turn, provide a structure to the IT portfolio that enables it to both define funding priorities, and to approve these priorities within the program – thus providing a more agile governance structure.

The challenge inherent in this rebundling of IT project work is that it necessitates a reassessment of the traditional IT funding model.  In a tightly coupled IT environment, each project is owned by a business unit, and hence funding is easy to determine.  In a decoupled portfolio, more investments tend to be made in an entire platform – that is then leveraged by multiple business units to achieve economies of scale.

Thus, as IT organizations move to this decoupled model, a new funding model is necessary – either splitting the costs equally across business units, or more logically, moving to a transaction based costing model.  This is the inevitable result of moving away from a coupled IT portfolio.

Yes, but……

Of course the issue with any framework is that it is overly simplistic.  I’d no sooner finished writing this post when I started poking holes in it.  For example, if tier 1 portfolios are defined in terms of what makes us a profit, and tier 2 portfolios support the people that provide the tier 1 services, then where does new product development (NPD) fit in?  In alignment with the proposed framework, NPD is another tier 2 portfolio that is designed to generate the grist that goes into the tier 1 portfolio and makes a profit.

The entire tier 1 and tier 2 thing may be a bit of a hazy line at some times.  For example, what if I have an IT consulting shop that shares resources between internal and externally facing projects?  Are those projects all one portfolio?  Do I have two portfolios?

I’ll defer to later posts for clarifying that question.

Strategically Decoupling Your Second Tier Portfolio (Part 1)

Frameworks can be very useful things.  They allow folks like myself and my colleagues to walk into almost any organization and quickly size them up in terms of maturity, capabilities, and well, let’s face it, consulting opportunities.  The risk of course is that we size up the organization incorrectly – or worse yet, we don’t bother to size up the organization and apply some sort of standard best practice drawn straight from the latest consulting memeplex.  (That never happens.)

Many times, we don’t even realize that we’re applying a classification scheme – until we take a step back and realize that we’re taking a totally different approach to the current organization than we did to the last organization.  When those sorts of epiphanies happen, I like to sit back and identify intellectually why I adapted the approach and see if I can turn that into a theoretical framework.  This post is the result of such an exercise.

Portfolio Types

I tend to cross operational domains about once a year, typically bouncing back and forth between pipeline construction and IT portfolio management.  Needless to say, these two domains seem to operate in entirely different worlds – with different priorities, operating goals, and differing concepts of velocity.  When was the last time you heard an IT shop talk about dropping a developer into the project via helicopter to ensure you make your deadlines?

When you talk to pipeliners about missions and portfolio optimization, you tend to get a blank stare.  That’s usually because project decisions are often made by the Marketing folks.  They work with customers to identify whether or not a new pipeline would be profitable, conduct feasibility studies, and then after all of that, they issue the marching orders to go build the pipeline.

IT tends to struggle with its fundamental mission, often not able to articulate why, in fact, a project has been selected.  That doesn’t mean though that all of IT operates significantly different than a pipeline company.  For example, try going to an IT consulting shop one day and asking them how they select the projects they do.  You’ll probably get the same answer as the pipeline company above: The salesperson made the sale.  Delivery did a feasibility estimate.  The consulting shop has chartered the project and expects to make a profit on it.

Tiered Portfolios

The difference in IT (support) having a tougher time articulating why it selects projects vs. IT (consulting) stems to one extent from the fact that IT is typically regarded as a cost center.  In other terms, if I go back to my ITIL training days, the two portfolios represent different service tiers within an organization:

A tier 1 organization is responsible for providing services directly to the organization’s customers, the people who pay money to the organization for the services it provides.  Tier 2 organizations provide services to the tier 1 group, i.e. tier 2 provides the tools to enable tier 1 to generate value for the customers.

I submit that a tier 1 portfolio, being directly responsible for the provision of profitable services to the external customers of the organization, has a much easier time of defining strategy.  Essentially that’s whatever’s profitable and fits within the long term goals of the firm.

It’s the tier 2 portfolios that are a bit more challenged.  The tier 2 portfolios are charged with supporting the mission of the organization, i.e. facilitating the job of the tier 1 service provider.  Hence, tier 2 portfolio optimization tends to suffer when the organizational strategy is poorly articulated.  When you look at a traditional project portfolio selection process such as AHP, you’ll see that it almost invariably is targeting the tier 2 portfolios.  You almost never see portfolio selection guidance applied to tier 1 portfolios.

To Couple or Not to Couple…?

Now we have the concept of a tiered portfolio defined, let’s take a look at another concept: the coupled portfolio vs. the decoupled portfolio.  Many IT portfolios are tightly coupled with the business (tier 1) portfolio.   This means that IT projects are chartered to directly support a business project.  If the business plans Project A as part of the annual planning, IT plans an IT Project A.  If business plans Project B, IT plans an IT Project B.

I’m almost certainly oversimplifying here, but the idea is that IT has a poorly defined strategy, and is simply following the tier 1 lead.  That’s not necessarily a bad thing, but it does have a couple of implications:

1. IT is always reacting to the business needs and not proactively driving to meet forecasted needs.
2. IT tends to not be able to invest in options analysis, i.e. it’s more difficult to set aside money to identify alternatives to achieve a specific goal, as the business is often not interested in investing in these optimization exercises.
3. IT programs are poorly defined and often fragmented.  There is often only a transitory acknowledgement that projects belong to programs, and those programs are the ones defined by the business.
4. There is minimal investment in shared platforms to support business projects.  Coordinated investment is replaced with piecemeal investment where the shared platform is only upgraded when the business is willing to attach the funding to a specific project.

That’s what a coupled portfolio looks like.  In my next post, I’ll talk about the implications of a decoupled portfolio.