Victus pro Scientia Opus -- Food for the Knowledge Worker

Lync Pro Tip: "An Error Occurred During the Lync Meeting" with External Users

If you have ever encountered this error, you may find this post helpful. It frequently occurs when one tries to join an external meeting, and one's Lync (server) does not permit access by the external party who sent you the meeting request, or vice-versa. 

By default, if you have Lync installed locally, clicking on the "Join Online Meeting" hyperlink will try to initiate the meeting using your Lync client.  If your Lync administrator has enabled external access via federation or other means, this error will occur.

Fortunately, a simple workaround exists:

1.  Right-click the link in the original invitation, and "Copy Hyperlink"

2.  Paste the URL into a new browser tab

3.  Append the suffix "?SL=1" to the URL

4.  Join your meeting via the Lync Web Client

The "?SL=1" switch in the URL forces the meeting/session to use the web client, rather than the local client.

There are, or course, some limitations to using the Web Client vs the local client, but if your local client cannot access the meeting, this is a simple, quick workaround you can try so that you can participate in Lync meetings with external parties.  You can also use this tip to help external parties to connect to Lync meetings that you set up, and it's remarkable how much more productive we can be when the first ten minutes of a meeting aren't occupied by "Can you see my screen? etc.)

Leaving the Premises

I am writing this post based upon on the premise that the English language, my Mother tongue, is being harmed on a daily basis in the name of cloud computing.  I am not writing it on the premises of my employer (whose opinions are not reflected here), because I am on a train, writing this on a mobile device.

Those of you who know me are probably saying, "Oh great, another screed from Mike about some trivial point of irrelevant detail that no one cares about, because he's trying to sound smarter than everyone else."  I love you, too.

I also know that I run the risk among grammar geeks of starting a whole "prescriptivist vs descriptivist" war, but that's not usually a target audience for this blog, so, whatevs. :)

I will accept your labels of "pedant," "know-it-all," and "nitpicker" if you need to attach them to me, but my motivation runs a bit deeper.  I was raised by teachers, and their standards for how we wrote and spoke as a family are a part of how I was formed. I suppose that part of my passion comes from just being who I am, some from how I was raised and educated, and some from an explicit desire to honor my parents.

But I digress.  This is the thing:

"Premises" (plural) are a location, a physical place or property.  When we say that Mike has "left the premises" we are saying that Mike is no longer in the building or on the property.

A "premise" (singular) is an idea or concept upon which other ideas or concepts are based.  For example, the value of SharePoint is based upon the premise that collaboration is a worthwhile and valuable thing for a particular venture.  If this premise is false (e.g., the venture in question comprises only a single person), then SharePoint will not be valuable.

The more comprehensive and definitive Merriam-Webster definition is here, for your reference.

In the world of cloud computing, I see this all the time:  systems maintained in organizations' own facilities frequently referred to as "on premise," from organizations as substantial as Microsoft, Oracle, SalesForce, and many others. I wish they would stop.

I implore copywriters and people everywhere who care about both technology and language to understand this difference, to fight the laziness and lack of rigor implied by this mistake, and to use the right word.  Words still matter.  Please choose them thoughtfully.

If you can't remember which is correct, the ambiguous "on prem" should cover you.

Thank you for reading.

[photo credit:  me, at the City Square, Charlestown premises formerly housing Olives restaurant, reported by the Boston Globe to soon be the home of a new Legal "C" bar.  Kudos for use of premises, brickbats for lack of agreement between subject and verb ("premises is...").  One windmill at a time...]

We're Just Not That Into You: Sending the Right Message Over the Life of a Client Relationship

Last week, Sam Ford published a great article in Harvard Business Review blogs.  It could have been a fairly garden-variety rant about a bad customer service experience with the home improvement retailer Lowe's, but the author translated it beautifully into an analysis of four reasons why the experience went wrong.

When I discussed it with my friend and local "co-opetitor" Sadie Van Buren, we saw how applicable Ford’s points are not only to retail but to the services industry, and quickly moved to translating the author's analysis into four points of prescriptive guidance:

Author's   Analysis of "What Went Wrong"	Our Thoughts on Prescriptive Action ("Go Do/Don't Do This") for Our Professional Services Firms
"Communications is not considered an important part of the work flow."	When working on an issue for a client, are you making sure to provide ongoing status updates?  Keep in mind - the client doesn't care that you're working on it so much as they care about when they'll have a solution. Communicate status, and communicate an estimate of when you expect to have the situation rectified.
"The infrastructure is designed from the company's perspective, rather than the   customer's."	Think through your organizational design and your client-facing processes from the point of view of the client.  How many different people or departments do they deal with over the life cycle of a project with you?  Are they getting the same message from Accounting that they get from your delivery staff? Do they know, at each step, who their contact person is?  Try to interact with your company from the point of view of the client:  call your 1-800 number, submit a web form, or Tweet at the company.  Observe and learn.
"Success is measured primarily by sales."	Hey, we understand:  nothing happens until a sale is made.    Unfortunately, it's short-sighted to have reward systems that are too leveraged around sales. This can happen because sales are easy to measure; it’s important to find ways to understand your performance on harder-to-measure aspects like quality, client satisfaction, repeat business, or even gross margin, with clawbacks for writeoffs.  These metrics will keep sellers engaged with clients longer and ensure better client outcomes.
"A sales is the climax for the company but often a milestone in an ongoing   relationship for the customer."	There was a great line in a recent political debate where one candidate hinted that the other was more interested in HAVING the job than in DOING the job. Think about how your organizational culture, reward systems, and organizational structure make it clear to all your client-facing employees that SERVING a client is as important or more important as OBTAINING a client. Do you sell projects?  What happens to the client when the project is over?  Allocating resources to a formalized closeout and introduction to a "Client Care" team gives the client a lot more comfort that you'll be there for them the next time they need you, rather than next time you have something to sell them.

In a client relationship, as in any relationship, each interaction sends a message to the other party about the degree to which we are “into” or “not into” them.  It’s easy to fall into the trap of expending time and energy pursuing the “shiny new object” at the expense of existing client relationships.  Being aware, via the prescriptions above and a healthy dose of empathy, of the messages we’re sending our clients will help us serve them better and drive long-term, healthy relationships.  In short -- continue to invest.

 

MEC-ing Towards Ecstasy

This week, I had fun (don't tell my bosses, but I get paid for this) facilitating a series of hands-on workshops for clients and prospects.  They are jointly sponsored by Microsoft and partners like my firm, and are designed to give attendees a hands-on experience with the latest wave of Microsoft technologies. 

They were once called the Customer Immersion Experience (this Catholic-school boy can't help but to arch an eyebrow at THAT baptism metaphor), and are now called the MEC, or Microsoft Experience Center.  There are multiple editions and versions of the MEC, but this one features the newest version of Office, Office 365.

I have attended and delivered many of these sessions, and find them useful to our clients for a variety of reasons:

1.  They are business-oriented.  The content is directed toward business users,  not developers or IT professionals.  These are people who apply technology to solve business problems, not whose job it is to manage IT.  The content is more oriented toward business productivity than platform optimization.

2.  They are experiential.  Attendees get assigned a role in a "day in the life" script that shows how Microsoft technologies are used on a day-to-day basis by knowledge workers. There is also enough slack built into the sessions' schedule to allow attendees to play, experiment, and explore scenarios that are of particular relevance to them.  In so doing, attendees learn not only about how Microsoft technologies enable them to work differently, they can also learn about the limitations of these solutions as well.

3.  They are hands-on.  Microsoft ships ten laptops (pretty kickass Lenovo Yoga touch-enabled convertible tablets)  and ten headsets for integrated voice and video communications, and we build time into the day for experimentation, learning and play with new apps, capabilities, and devices.  This also includes showing how other devices like Surface tablets and other mobile devices like iPads use the  technologies we're using.

4.  They are turnkey.  The original edition of CIE/MEC required that customers come to a Microsoft Technology Center to attend a MEC session. In generation 2, the Mobile MEC, Microsoft had to ship computers and voice endpoints along with powerful servers capable of running virtual instances of all the required server technologies:  a domain controller, Exchange, SharePoint, Lync, etc.  In the same way that computing pioneers look at ENIAC, then their smartphones, and shake their head, I do the same now that the server-side work can all be provisioned and run in Microsoft's cloud.  We can provision and manage full-featured environments (with data populated) in about 24 hours for the new Office 365 MEC, without shipping servers around.

All in all, if you're considering making an investment in Microsoft technologies or seeking better return on what you already own, the hands-on workshops and MEC scenarios are a great way to see how your knowledge workers can improve their productivity and save money via the latest Microsoft has to offer.

 

More Done Than Said

[Editor's Note: This will be the last post about baseball for a while.  I promise.  I had to get it out of my system. Thanks for indulging me.]

Those who know me know that I frequently can be found on baseball fields in the Greater Lowell, MA area, playing baseball in a men's baseball league.  It's a great release, gets us all outside in the summer sun, connects me to the game I grew up loving, and feeds my competitive juices just enough.

Recently, we held our annual end-of-season banquet where we celebrated, in muted fashion, the retirement of a friend and teammate with whom I've played for 11 of my 14
years in the league.  Because of his reticence and hatred of the limelight, a more public celebration, toast, roast, encomiums, etc. at the banquet were out of the question. 

HOWEVER, because of my process orientation, I (compulsively? Perhaps. Whatever.) I thought a lot about what I've learned from him over that time, as a sort of "lessons learned."  Here goes:

1. Know the game.  My teammate was a student of the game who had clearly received great coaching.  In addition to the natural talents he had, he understood the situation at any instant in the game, and knew the right offensive approach (e.g., take pitches to work the count when down by a few runs) or defensive play to "steal an out" in a key situation.  Larger lesson:  it's not just about technique (doing things right), but also about a broader understanding of the context (doing the right things).
2. Capitalize on your opponents' inattention.  Not infrequently, an opponent would hit one of my pitches for a double, and if he was a weaker hitter, he would be visibly happy/excited about the hit as he stood on second base. When the next hitter came to the plate, my teammate and I would frequently pick the still-celebrating player off second base.  There are many other instances of this, but most are too arcane (truly "inside baseball" stuff) or too competitively valuable going forward to share here.  Larger lesson:  Never take your eye off the ball.  Never stop competing.
3. If you don't have something useful to say, watch, listen, and keep your mouth shut.  My teammate was a man of few words, many of which were acerbic and hilarious, and he didn't have the highest tolerance for those who were unnecessarily chatty.  In fact, I'm not sure how he tolerated me and my incessant patter for as long as he did.  His quiet demeanor didn't mean he wasn't competitive and passionate about playing the game the right way, just that he led by action rather than words.  Larger lesson:  Shut up.  You might learn something.

There's an old expression, attributed to either Aesop or former Notre Dame football coach Lou Holtz, that goes:  "When all is said and done, more is said than done." 

Cheers to a friend and teammate who lived up to the opposite.

SharePoint Saturday Rhode Island Recap

I was honored to be selected to present at this weekend's (inaugural) SharePoint Saturday Rhode Island.  Organizers Jason Himmelstein, Chris McNulty, and Josh Cliff did yeoman's work in making it happen, the sponsors stepped up to fund it, and the speakers turned out and delivered a phenomenal day's worth of the best free SharePoint training.  Best of all, over 100 attendees came out, learned, and were active participants in the discussions.

Special thanks go out to the host venue, New Horizons Rhode Island, for graciously "lending" us their facility for this event, and to all of the new speakers (including my colleague John Mongell) who shared their stories, experiences, triumphs, and tribulations with us.

In the morning, I presented a session on SharePoint as a component of a more broadly integrated collaboration strategy (including voice, video, e-mail, etc.).  It was based on some ideas I hatched after reading Nancy Settle-Murphy's excellent book:  "Managing Effective Virtual Teams."  As promised, the slide deck is here:

I also promised to drop some basic templates for integrated communication/collaboration plans into my SkyDrive, and they can be found here, although they are much better when in the overall context of the book.

In the afternoon, I presented a closing session about how to go back to your boss, your project sponsor, your CFO, etc. and get funding for all the cool SharePoint projects you learned about at SharePoint Saturday.  The organizers told me to make it quick and fun, TED-talk style, and the energy was great in the room, so I hope it worked out. The deck is here:

SPSRI - how do i get this funded closing final from Mike Gilronan

and I think that this video captures the premise (not premises, more on that in a future post) of the discussion, even if it was a competitor to Microsoft who originally created it:

All in all, this was a great event with great flow of ideas from a great community.  Thanks to all who made it happen!

Five Stages of Microsoft Partnership

I spent some time with a colleague this week discussing how partners work with Microsoft, and it's a conversation I've had in many shapes and forms for almost 15 years with many Microsoft partners in partner briefings, conferences, advisory  boards, executive round tables, and other less formal venues (ie/eg, over beers).  Having built much of my career around partnering with Microsoft, I have strong opinions about this "dance" that we do, and if you know me at all, you know that I am generous about sharing such opinions. :-)

So, please find here a reasonably informed but informal, slightly tongue-in-cheek but generally based in reality, take on partnering with Microsoft:  an ersatz "maturity model," if you will.  In this case, I need to be crystal clear:  I speak for myself and myself
only on this one:  this by no means reflects the opinions (or even the experience) of any of my employers over the last 15 years.

With apologies to Elisabeth Kübler-Ross, here are the Five Stages of Microsoft Partnership:

Stage One:  Denial 
Why on God's green earth would we want to partner with Microsoft?  They need to bring us some leads, then we can talk.  It just feels like a tax, with no immediate evident return.   We can't make any headway without being asked to fill out some form containing information about my company that Microsoft should already know.  What are they bringing to us, besides a long list of acronyms?  We don't know or care about the difference between an SSP and a TSP.

Stage Two:  Despair
Wow, this program is dauntingly comprehensive, and our organization really doesn’t have our act together.  If I were Microsoft, I wouldn't be bringing opportunities to us.  We have a long way to go to meet the requirements and guidelines, and to avail ourselves of all the benefits of the partner program.  We understand the segments of Microsoft, however, and know which one(s) our business should be aimed at, and we've identified some key people in those segments with whom we need to connect.  It just feels like a long way up from here.

Stage Three:  Hopeful Performance 
We have seen the value of the program, are executing against it, if unevenly, and we have a plan to monitor and improve our execution,  The Microsoft team has started to take notice, and our organization is either managed or on a path to becoming a managed partner.  We're using software entitlements to get/stay current on our own productivity
technologies.  We have started to speak in sentences with two or three Microsoft acronyms in them without batting an eye, and understand the different licensing mechanisms (e.g., OEM vs Open vs Select vs Enterprise Agreement) that Microsoft uses in my segment, and why that matters.

Stage Four:  Soaring Execution
We and our Microsoft partner team have executed against our plan, we are considered a "go-to" partner in at least one Microsoft competency or segment.  One or more people on our team has a "purple badge" as  a Virtual Microsoft employee, and we're jointly crafting sales and marketing programs with Microsoft team members.  We're making sure we bring a nice outfit to WPC, because we expect to be on stage receiving a Partner of the Year Award, and/or sitting for a photo shoot so that Microsoft can use our image in their
stock photography.  We also know enough to prioritize our Microsoft investment in the most "partner-friendly" individuals/teams, (ATUs/STUs, individual sellers, and segments) and avoid wasting time with the others.*  We know very precisely, by late summer, when annual plans are finalized, what the incentive structures and goals are for our key points of contact at Microsoft. 

We have, un-ironically, used sentences like "Is the new TSP for SMS&P aligned with APIO and goaled on SQL Azure POCs?"

*Like everywhere else, there is a bell-curve of partner-friendliness among Microsoft team members, and we're attuned to it.  A Partner Account Manager who can help you focus on where to invest, and perhaps as importantly, where not to waste your time, is an incredibly valuable resource, all along this lifecycle, and at this stage in particular.

Stage Five:  Devolution/Plateau
We have been a Microsoft partner long enough to train new Microsoft team members in Microsoft's own structure, organizational dynamics, and programs. We continue to perform at a high level, but have rested on our laurels a bit.  We lack the vision to ascertain which changes are critical, or the agility to embrace seismic changes in
Microsoft's partner model, margin model, deployment models, etc.  We fail to adapt to where Microsoft is headed next, so we double down on what got us to Stage Four.  We get the sense that Microsoft has begun to favor more "up and comer" partners, and too many of the "best practices" we espoused with Microsoft have been adopted broadly, killing
any competitive advantage we had against other partners.

Note:  The best partners, of course, maximize their time in Stage Four, and/or create what some investment banker-types call "a liquidity event" prior to ever reaching Stage Five.

I've learned two key lessons in my time as a Microsoft partner:

1. There's money to be made as a Microsoft partner.  It's not always easy -- Microsoft is a large, complex organization even in the midst of its own reorganization, and even the friendly dragon can obliterate a whole village with one swipe of its tail.  As with most partnerships, there are two key types of assets that make it work:

a. Programmatic/systematic:  forecasts, Partner Sales Exchange, events in a box, training opportunities, conferences and other events,etc.

b. Personal:  the people who interact with Redmond, developing product and go-to-market strategy, and the people who interact with Microsoft's customers in the field, at the regional sales organization level.

The programmatic things often need to happen (check that box!), but it's the personal relationships with the right people in the organization, as with most partnerships of value, that will make or break you as a Microsoft partner.  Don't ever miss an opportunity to wisely invest in these relationships. 

2. You've got to stay attuned to, not just how Microsoft makes money now, but also what their sellers are "goaled" on each fiscal year.   In so doing, you'll learn a lot about their priorities.  While it can be costly to be too early in the market with Microsoft's products and services (see:  PerformancePoint v1, Windows Mobile until about 2009 or so, Dynamics AX in about 2005-2006, etc.), it can put you out of business to be too late.

Overall, the magnitude of the Microsoft opportunity for partners, even in challenging times, has been enormous for a long time, and Microsoft is distinguished in its attention to a robust partner "ecosystem."  I have many times likened Microsoft to a battleship:  it takes a long time to turn the ship, but once it trains its guns on a target, it tends to obliterate that target. 

If you know where you are on this continuum, and what opportunities and threats to look out for, you can create a lot of value to your clients, your community, and your investors. 

Happy Partnering!

When Your IT Project Is Doomed to Fail

There is an old saying in golf that every golf bet is won or lost on the first tee.  For those of you who are non-golfers, non-bettors, or both, the first tee is where golfers' handicaps are discussed/negotiated and where they establish the number of strokes the better players will "give" the other players to even up the match. 

The specifics of golf handicapping are somewhat beyond me (kind of like quantum physics or Microsoft software licensing, in that "necessarily complex" category), but the overall gist of it lines up with a very simple formula for project success that I learned as part of PMP training:  "Success Equals Results Minus Expectations"

We were also taught as project managers that the time to negotiate the project's constraints is at the outset.  Once you agree to the project charter in the initiation phase and the project schedule in the planning phase, it gets a lot harder to negotiate or to complain about them later, even when legitimate reasons for doing so exist.

This week's Congressional hearings about why the enrollment portals for the Affordable Care Act (aka "Obamacare") reminded me of many of these things.  Seeing and hearing IT executives wish, retrospectively and very, very publicly, for more time to test their solution prior to rollout made me sad because I knew that their chances for success
were depressingly low right from the outset. 

When time is your primary project constraint, the only other constraints you can tweak are
quality and cost, and even adding resources/cost do not necessarily reduce time (in fact, they tend to increase it -- see also Brooks' Law from the classic:  "The Mythical Man-Month"). 

I do not envy the IT consultants who tried to build the ACA sites -- that was a tough job, and I doubt they'll realize much profit now (Congressional scrutiny, I would think,
would tend to have a dampening effect on profitability).  So, what can we learn from this? 

The lesson for me is that Project Managers get their first, best, chance, prior to the first tee, to walk (or run) away when we know we can't win.  Here are some great ways to assess your chances up front by looking for project "red flags"  (I love #3, personally): 

"11 Signs Your IT Project Is Doomed" 

Baseball As Collaboration Metaphor

[Note:  This post was made possible by an idea hatched by my friend and colleague Nancy Settle-Murphy when we worked together on a recent post about the 2013 Red Sox "Road to Redemption."  NSM provided editorial insight on this post as well, and provides a ton of insight about how people and organizations work together at guidedinsights.com.]

By day, I've been (as usual) thinking about SharePoint and other collaboration technologies, and how businesses solve problems and create value by effectively using them. 

However, by night, the Boston Red Sox have been on an entertaining run through the Major League Baseball playoffs, so I've been spending time wrapping up the baseball season by watching the Sox create some magic moments in October, frequently late into the night.

With that in mind, let's explore the junction between SharePoint and baseball via metaphor:

Baseball	SharePoint	Commonality
Infielders	Lines of Business   (LOB*)	Closest to action  (home plate = where revenue is generated)
Outfielders	Information   Technology (IT)	Last line of defense but still critical, constrained (fences = budgets)
Catcher	Human Resources	Calls signals, captain of defense (positioning fielders = organizational development and training)

* -- for purposes of this blog post, LOB means "Line of Business," not "[Runners] Left on Base" as in baseball. 

The key risks for a business trying to collaborate with too many infielders (LOB), not enough outfielders (IT):   chaos/Babel, security risk (e.g., of sensitive data being shared ad hoc via unsafe collab, like personal DropBox or SkyDrive, or just e-mailed), operational risk (no service-level agreements, or SLAs, for collaboration technologies, so they may not be available when we need them).

The key risk for a business trying to collaborate with too many outfielders (IT), and no infielders (LOB):  a well-governed wasteland that is so secure and well-ordered that no one goes there.

In baseball, the fun part comes when balls that are into the gaps between the infielders and outfielders (with apologies to Crash Davis):

• the bloop,
• the gork,
• the Texas leaguer,
• the bleeder,
• the dying quail,
• the ball hit into "no man's land" that falls between the infield and the outfield. 

Depending on how it's played, it can turn into a great play:

  

an error, or just a hit that falls between the fielders ("I thought you had it") 

 

 

In SharePoint, there is a rough equivalent:  gaps between the business users of the real-world technology and the IT organization responsible for its infrastructure/technical governance.  We fill these gaps with operational governance, a set of conventions and norms that answer questions like:  Who is allowed to create new sites?  Who
decides whether we can federate or share content with external parties?   Who decides on the interface/navigation? Who decides who has access to which content? Who creates expiration dates for content? Who can set alerts?

There's no magical formula or golden ratio in business collaboration technologies akin to the "shift" that teams use against David Ortiz, but there are some prescriptions/strategies I can offer:

1. Norms/rules: a convention in baseball is that a ball hit in the air between an infielder and an outfielder belongs to the infielder until an outfielder "calls him off".  Make sure that your organization has a default, agreed-upon, norm (similar) -- e.g., site administration rights can be delegated to a manager in LOB if (a) trained (document this) and (b) pproved by LOB leadership.  IT administrates/ratifies based on (a) and (b), but LOB approves.
2. [I'll steal a concept from softball here:]  a tenth "short" fielder or "extra player" typically positioned between the infielders and outfielders, who catches those in-between hits that would otherwise land between infield and outfield. Some examples of these "short fielders" to catch the "in-betweens" are:

 

• A Business Analyst who reports to IT, works as concierge to LOB
• A separate Organizational Development lead who reports to HR or an executive/officer, to bridge gaps and perform "shuttle diplomacy" between IT & LOB.  I recently met a client with the title:  Executive Director or Organizational
  & Systems Development -- it really shows a high level of commitment to cross-functional collaboration on his employer's part.
• Corporate Facilities.  Especially in large, distributed organizations, the Facilities organizations can be highly attuned to not just *where* people work, but also *how* they work.  Organizations such as New Ways of Working http://www.newwow.net/about-us have great resources to help organizations bridge these gaps.

In summary:  To paraphrase John Cougar Mellencamp, "It's a sad, sad, sad, sad [# of sads?] feeling when you're living on those in-betweens."  Have a plan for the "in-betweens" that involves both norms (to make the easy stuff as automatic as possible) and humans (to intervene and work across the field of business) to accelerate and optimize your collaboration technologies.

Happy collaborating, and GO SOX!

Fenway Magic and Turning Around a Team

The Red Sox are inspiring people all over New England and beyond.  Consistently high performance, a team ethos we haven't seen at Fenway in years, gut-wrenching late-inning drama, and a genuine personality (see also: #fearthebeard) have made them compelling to watch, especially when one considers the well-documented depths to which they fell in 2012, and that only six months ago, a bruised city turned to them for inspiration in the wake of the tragedy on Patriot's Day.

So, how did they turn things around so quickly?  I was fortunate to be able to work with my colleague Nancy Settle-Murphy, an expert in teamwork and organizational development (truth be told, I did little more than fact-check baseball information and flesh out a few metaphors) on an article that examines this "worst to first" phenomenon in more depth.  Enjoy!