Road Trip

Road trips come in three varieties: You need to get from point A to point B, you want to discover something or you want to show somebody something. I’ve been on way too many of the first type, including two where points A and B were 3,000 miles apart; those trips are not always fun. Trips of the second type are almost always interesting, but the third kind of trips are the ones that are fun. When it comes to SharePoint, it’s the same story.

We have been on the first type of road trip for the past few months. We have built out a complex document handling project, aided by content types, workflows and bits of metadata. In addition, we spent time wiring up a bunch of Data View Web Parts and detail views of this content to elicit some management information about the process and present it on a dashboard. Those were the major goals of the project, comprising points A, B and several others in the alphabet. We are just about to call the project done. Handing the management dashboard over to the department VP was a rewarding moment, but late last week we took this project on its own little trip.

As we were completing the management dashboard for this process, I asked the VP Engineering if he would mind if I showed it to others in the company as an example. He offered something better – an opportunity to present the dashboard to the entire company at a roundtable style meeting the engineering department holds. This was a fantastic opportunity to market SharePoint within our company for several reasons:

Real Solution – In the past, we have tried to get people excited about SharePoint by showing example solutions designed to highlight a specific feature. Unfortunately, in those cases, we are always asking the audience to work too hard. We are asking them to understand what we are doing, and imagine how they might map the demonstrated capability to their department. We, SharePoint practitioners, do this all the time, but that’s because this is our job, and we already understand SharePoint. It’s hard for people to juggle an unknown and an imaginary scenario at the same time.

Not an IT Solution – The next worst thing after a hypothetical solution is an IT solution. I have demonstrated libraries, processes, lists and workflows around IT Asset Control, communication with IT vendors and even the way I handle the AIIM New England Chapter minutes. These were all real working examples, but they were all in support of a world my audience still had to imagine. Everyone in our company knows what an engineering inspection is. Everyone has seen at least one inspection report and everyone knows how important the inspection activity is to our operation. When we demonstrated the SharePoint solution, they only had to understand the part that SharePoint was adding to the process.

In taking advantage of this opportunity, we were careful not to mess it up by making it an “IT Thing”. My coworker, the woman who built the solution, was careful to express everything from an engineering point of view. She talked about how the engineers work, and how the Vice President uses the dashboard. She pointed out the benefit they derive from the project. She didn’t use the words ‘workflow’, ‘metadata’ or ‘content type’. OK, she may have used ‘content type’ when answering a question, but the point is, she kept her demonstration in business terms. When we were describing the dashboard, we emphasized how the information being displayed was gleaned from the document library. I may have used the word ‘metadata’ at that point, but I tried to avoid saying it twice. We tried to put distance between SharePoint and the fat-client / database server applications our fellow employees are used to. Yes, I know SharePoint is or at least resides in a database, I even mentioned that to my coworker and we both agreed “let’s not go there.”

Even though the process is largely similar or at least analogous to a database system, there is a beneficial distinction between reporting from SharePoint metadata and reporting transactions. Reporting from SharePoint appears to be a bonus; we aren’t adding metadata as a transactional element so we can report on it. We add the metadata so we can find our reports, so we can organize our reports and so we can manage the process. By manipulating the metadata behind the scenes of a management dashboard, we get additional benefit. You can split hairs and point out that our dashboard is basically the same as a monthly premium report. You may even be right, but as I said at the outset, this was a marketing exercise.

Reflection

CT River from North End Bridge

Whenever I give a presentation, I like to think that I have a huge advantage over Microsoft employees and SharePoint consultants. In the first case, I can freely talk about the things SharePoint doesn’t do well, and the things I know it could do better. In the second case, I can talk about the things I don’t do well – I don’t have to try to impress you with my prowess so that you might hire me. I do sometimes worry that if my boss actually reads this blog, he might wonder “why the heck did I leave this bozo in charge,” but I recall that he was the first to identify the therapeutic effect of blogging, so he won’t hold it against me when I air the laundry.

The one consistent truth in systems development, ECM solution development or just about any development process that involves people is that things go off the rails from time to time. I have been building solutions that change the way people work for 35 years, and I have seen just about every reason why solutions fail, from sabotage to resistance at a level that would confound the Borg Queen. I’ve seen solutions that are as good as the technology would permit, as good as the budget would permit, and/or as good as the deadline would permit, but were still not good enough. I have also seen solutions fail because the infrastructure they were built upon evolved in a different direction. None of this is happening today in our case, because our system isn’t failing, and my experience tells me that it isn’t about to fail. Our system is just waiting to be “the way we do things.” Right now, we are still fighting the memory of “the way we’ve always done things” and that is one tough battle. You may have noticed that I haven’t described what went wrong to inspire this blog entry – it doesn’t matter. In fact, if I tell you the questions we were asking as this week ended, I’m sure you will recognize them:

• What is so hard about this?
• Why didn’t they tell us they were having this issue?
• What made them think that (the workaround) would help?

Then we asked the most important question of all – why aren’t they learning how to work with this process?

When we build information management systems, we like to think that we are improving a business process. That’s a comfortable way of looking at development because it creates an abstraction layer between us and the people involved. Considering the business process allows us to ignore history; we don’t care why they “used to do it this way”, we just assume it was because they didn’t have our solution. We aggravate this situation by assuming that everyone wants every process to be as efficient as it can be. We know better. In reality, we are trying to change the behavior of a group of people, and in general, people don’t like change. When things start to go wrong though, we tend to skip past the abstraction layer and zoom in on the people involved. One of the common complaints that I hear about people, when I talk to others in this industry, is the so-called generation effect on technology adoption. People will talk about how much more willing younger people are to embrace new technology than the old guard employees they are being trained to replace. While there certainly are generational differences when it comes to affinity for technology, we also have to consider that new (younger) employees are learning the process and our solution at the same time. In the absence of a historic regimen, any solution that gets the job done has a certain appeal.

As we consider our final question, we have to consider the answers our users aren’t giving us. Nobody is going to just come right out and say “I don’t want my job to change,” but they don’t want their job to change. We can take the Borg Queen’s approach, and remind them that resistance is futile and that our solution is here to stay, or we can step back and look at the new solution from their point of view. How did the system we just build impact this person’s job? We tend to focus on the things we made easier, but did we make anything more difficult? Resistance is futile; in time, people will adapt their behavior to accommodate the requirements of the new process, but what if we missed something? What if that new process could actually be a little bit better? When we see people pushing back, instead of embracing our solutions, we need to try and discover the underlying reason – maybe it’s something we can fix.

Still SharePoint

It’s that time of year, the week where our Annual Report goes through a few quick iterations before being released to the printer. This process starts out in SharePoint, but it ends in a flurry of paper and red ink. A friend of mine walked past my office while I was in mid shuffle and said “forget SharePoint, you are now the collaboration engine” – sadly, he was right. How did a process that was born digital in SharePoint go off the rails? Simple – by request.

Preparing this report is truly a collaborative exercise; it starts with a vision, which is turned into a series of writing assignments that generate the precursor to the first draft. During this phase, the content is in SharePoint, under version control, but most of it was sent to me as an attachment to an email. I used to try and force people to use SharePoint, but lately, I don’t care. As I’ve written here before, we use Harmon.ie, and frankly, an email attachment is as good as a document created in SharePoint because I can simply drag the attachment into the library. In this case, the library is on our Internet-facing server, so the designer can have access to the files, but Harmon.ie spans farms with ease.

My job at this point is to make all of the documents that I’ve received sound as though they were written by one person. Since I prefer to do some of that work offline, away from the office, I have this library synchronized in SharePoint Workspace. As the bits and pieces of text reach first draft status, I start releasing them to the designer. In addition to the text content, we use SharePoint to provide graphics, financial exhibits and supporting material to the designer as well. He downloads everything from SharePoint to begin working his magic. This step ends when he has a PDF of the first draft for us. Although the designer and his assistant are comfortable with SharePoint, the draft PDF arrives via email – again, I don’t care – Harmon.ie lets me keep everything in the library.

From this point forward, the process remains outside of SharePoint for everybody but me. I print the PDF, duplexed and stapled so it looks like the report, and I distribute it to all the authors and reviewers. This step needs to be performed in analog form, for one key reason – context. Seeing the portions I wrote, sitting next to the stuff someone else wrote is important. These bits of text need to reinforce each other, they need to not duplicate each other and they need to avoid using the same word over and over. This is also when the fun starts. You might think people would tend to stick to their areas of expertise, but since there are two ways to get your text and my text to sound alike – I will probably opt for changing what you wrote.

All of these changes are compared and weighed against each other to help us achieve our collective voice. That involves further revolutions of the collaboration engine in the form of sitting with each author and discussing the changes they or others have made. When finished, I make those changes in Word, with Track Changes enabled, and I email the Word document to the designer. Wait a minute. I, the SharePoint guy, email the document… Yes, that’s how the designer wants to receive changes. They want them in Word, highlighted by Track Changes and they want them in an email. At this point, I am part of their process, a process I am paying for, and it isn’t my place to dictate, or request changes to that process. The changes are still in SharePoint (you were wondering where I got the title) along with version comments to explain them. Whether I opened the document on the server or in my Workspace, they end up in the library. When I sent the email, I opened the Harmon.ie Sidebar and dragged the Word document into my email.

Sometimes SharePoint has center stage and the spotlight; sometimes, SharePoint is a tool of the stage crew. I have learned that while SharePoint might always be the location for important documents, it shouldn’t always be the conduit. We have other tools, better tools, that support collaboration; and we have to recognize that collaboration is a human endeavor. My goal was to capture the process, (the versions, the changes and the reasons) not just the end result. SharePoint Workspace and Harmon.ie helped me to do that. Those two products helped me let our people work the way they want to work and let me accommodate the way our designer wants to work. At the end of the week, we had an excellent product, everybody was happy, and everything was in SharePoint.

Saying No

What do your users have in common with your children and your pets? Sometimes, they have to be told “no” in an effort to help them learn to be more self-sufficient. OK, if your pets include cats, telling them “no” and expecting them to learn is a fool's errand, but I think you understand my point. In addition to the need to be told no, users, children and (some) pets have ways of making it difficult for us to say that word. There are lots of reasons we don’t want to say no, but the big three are:

1. We want to be liked.
2. We genuinely want to do what they ask, or let them do what makes them happy.
3. It’s often easier to do something for them than it is to teach them how to do that thing for themselves.

If you were to ask the users in our company, they would probably tell you that my approach to technical support would indicate that I don’t care about being liked. That’s not entirely true, being liked is nice, but I get paid for being effective. In order for IT to be effective, we have to strike a balance between providing technical support and helping people grow in their understanding, adoption and their own effective use of the technology we provide. This has always been the case; there has always been a fine line between support and coddling on the one hand and encouragement and indifference on the other; walking those lines has never been easy. SharePoint, at least our SharePoint installation makes walking those lines even harder, because the lines are moving. Maybe that’s the whole point of the SharePoint Maturity Model, but I’ll leave that discussion for others. The simple observation is that the further we extend SharePoint beyond the ability of our users to understand it, the more it becomes an IT product.

In trying halt the progression described in the last sentence, I can honestly say that I’m not prone to coddling my users. I might not actually say “no” to people asking for help, but I am becoming a fan of saying: “…here, let me show you how to do that.” The distinction is a finer line than you might imagine. Someone who simply wants a problem to be solved considers that approach to be the equivalent of my saying “no.” But even if we (IT) did everything for them, our SharePoint implementation would ultimately fail. SharePoint growth is fed by the dual inputs of response and insinuation. Most of the progress we have made to this point has been the later; people have asked for help, and we have declared that “that would be a good use of SharePoint.” Far less progress has come in response to people asking if we could change, extend or create a new SharePoint solution. That we do get some of those requests is heartening, but we have to work to keep them in the mix. As our SharePoint solutions become more complex, more aggressive, more dynamic and more useful, people have to understand more about what is going on behind the scenes.

A recent example surfaced as we were demonstrating the management dashboard that I wrote about here. The dashboard highlights individual items and aggregate results that are necessary for managing a process. Most of the results on display are linked to a detail view that better illustrates that aspect of the process – Reports by Engineer for example. As we were demonstrating some of these views, people started suggesting changes. Many of their suggestions just involved altering the sort or filter parameters of the view. We took the opportunity to remind them (demonstrate) that they can dynamically introduce those changes in ANY view, at ANY time. It is very important to remind people that even once a solution has been “developed”, that the results are still in SharePoint and all of SharePoint’s inherent functionality remains available to them. We (practitioners) know this, but people who are not as familiar with SharePoint as we are, may not recognize that a view is a view is a view. In addition, many of them are not adventurous enough to take the approach of saying “let me just try this…” Our history of building and delivering “systems” has conditioned people to thinking that what they get from IT is what they have to work with. This perception will change as we incorporate personalization features into our next generation desktop systems, but right now, SharePoint is leading the way toward the consumerization of IT at our company. I also recognize that they have their own job to do, and that I am asking them to extend their domain to include parts of ours. Like I said, it’s a fine line.

Welcome 2012…Reprise

As far as years go, 2011 wasn’t one of the best. Personally, I started the year in the care of a physical therapist struggling to mend a shoulder injury. Turning to business, and keeping in mind the business that we are in (insuring nuclear power facilities), 2011 brought us a little bit of everything. Topping the list were the devastating events in Japan, and as the year comes to a close, our thoughts and prayers remain with the hundreds of thousands of people affected by the earthquake and tsunami in March. Closer to home, our domestic insureds had brushes with tornados, floods, hurricanes, and earthquakes. Our offices were closed due to snow on three occasions and dark for a total of 5 days from storms Irene and Alfred. 2011 was also a year in which we seemed to make a technological bet against Microsoft. We agreed on a strategy that put an iPad in the hands of about one third of our key users and saw us solidify our support for iPhones. As I write this blog entry, I am watching my MacBook Pro receive files from my MacBook Air and those files include my XCode development environment. So, what is it that has this SharePoint guy looking forward to 2012? In a word, everything.

If you follow any of my blogs, you know that we made a lot of progress on several SharePoint projects in 2011. We are entering 2012 on a roll, and one of the first things we will do is showcase some of that success to others in our small company. In addition, when we placed our bet on Apple, we counted on Microsoft to see the light and support iOS too. On Christmas Eve, I had a conversation with a friend from his iPhone Lync client, four days later, that client was running on my iPhone too. Rumor has it that Office apps are not far behind, and that’s a good thing for me, for Apple and for Microsoft, at least according to my own informal research – the top story on this blog in 2011 was “SharePoint on My iPad!”

My optimism is bolstered by the awesome performance of my team. My Systems Admin took everything we had learned about SharePoint and the way we use this powerful tool, and built our SP2010 environment from the ground up to fit our needs like a well-made glove. The woman on our team, who has been responsible for the user experience of SharePoint, stepped forward from the confidence-infusing session we had with Marc Anderson, and crafted some awesome features for our engineers. More importantly, she helped demonstrate that SharePoint has a role in our future development. Again, my informal statistics would indicate that SharePoint as a development platform is a good thing for others as well – “Symply the Best” my post about our training session with @Sympmarc, sits nicely in the top-10 SharePoint Stories posts of all time.

For the non-SharePoint fans in my world, we will be hiring a new developer in 2012, and he won’t be focused on SharePoint. His (or her) job will be to replace an aging generation of applications that run our niche business. On the other hand, he won’t be able to escape SharePoint’s reach entirely. Our users have already told us that they want the things that SharePoint does well to reside in SharePoint. So, contacts, tasks, and documents will be in SharePoint; while workflow and reporting will walk the lines between fat-client, client server and a browser powered by SharePoint.

2011 started with what seemed to be a series of sharp divisions between Apple and Microsoft, SharePoint and desktop, and documents and structured content. 2012 is starting with all of those worlds beginning to coalesce around the concepts of information and solutions. That brings me to AIIM, the organization that has been predicting, nudging, supporting and cheering this merger on for years. Rounding out the list of (my) popular blog entries is a collection of stories that are grounded in the concept of Content-Centric Applications, the term introduced to me by Jane Zupan of Nuxeo that I have embraced as the model for my future. As we start to define and build our next generation applications, structured and non-structured data will share center stage. AIIM has anticipated this development and seems well prepared to help lead the way with a new certificate program, a new conference and, at least in our corner of the world, a renewed interest in chapter events. I won’t quote Mr. Scrooge and claim to be “as giddy as a schoolgirl”, but I am looking forward to 2012 and I wish you all a Happy and Prosperous New Year.

The Problem with Metrics

“If you can’t measure it, you can’t manage it.” I don’t know who coined that phrase, but I have to tell you, I have some problems with the concept. My primary problem is that “it” often refers to a person, or at least the activity of a person and I think people should be managed more holistically. Another problem that I have is that since we are managing people, we are subject to the behavior of people who know they are being managed.

My first job after college was as a programmer/analyst for Burroughs Corporation, working in one of their manufacturing plants. System responsibilities had been hastily reassigned during the period between my accepting the position and my start date, so I found myself responsible for payroll, HR and work management systems. The product made at our plant was memory sub-systems and I was exposed very quickly to two problems with metrics. Problem one was the ease with which metrics can be manipulated. Our plant manager, aware that a key metric of his was the number of days between receiving components and shipping an assembly, simply purchased a used trailer from a trucking company. Material that arrived before we were ready to deal with it was unloaded onto our loading dock and reloaded into his trailer. When we were ready to start using the components, they were “received.” This little bit of subterfuge kept the metric that determined his bonus, nicely in the acceptable range.

Inside the plant, and much more problematic for me, was the fact that we measured every operation that was conducted by every person on the assembly floor. If five people were operating machines that stamped memory chips into circuit boards, one of the systems I was responsible for would calculate and report the cost per chip inserted. Later, I would use that value in other calculations. Unfortunately, the collection system didn’t differentiate between new assemblies and rework. So, while the guy building new circuits was feeding racks of memory chips into an automated press, the woman at the next station was unsoldering and re-soldering defective chips by hand. He might insert hundreds of chips per hour, while she struggled with five. Mine wasn’t an ethical dilemma though. The nature of the repair business meant that sometimes we would receive a part for repair that was no longer in active production. In the reporting side of my system, when I had to do the math that involved “average insertion times” the results were too small to measure and they would fail on a divide-by-zero error. Discarding these results made the woman look bad, including them crashed the system.

I am recalling those early struggles as we study the results of our newly implemented analysis of engineering inspection reports. One of the changes we have to make is to properly reflect inspections that people performed, prepared and participated in. These aren’t just three categories, or three bits of metadata, they are three distinctly different statements about someone’s role in a very important process. Not only is the distinction important, it’s important to know what is what, once these variables are calculated so the right metric is used in the right formula. For instance, the lead time on scheduling the inspection is properly attributed to the person who was in charge, so a guilt-by-association attribute should not be applied to every participant. There also has to be a distinction drawn between the person preparing the report and the person who performed the inspection. We aren’t talking anything on the scale of squirreling stuff away in a trailer, but if the relative performance of individuals is being compared, the right metric has to be used.

So why am I trying to commit this to memory (that is why some of us have blogs) “because it’s so easy to get this stuff wrong” and once your mistake is incorporated into a management report, nobody will ever know. I don’t know about you, but when I get a number to appear in the box on a screen prepared in SharePoint Designer, I am happy, and I feel close to being done. When I look back at that code and see “@Prepared_x0020_By” I know that it’s the right column, but when my coworker is reviewing the code where I refer to “$EngName”, she might be tempted to simply assume it’s the right variable. This is where SharePoint development has to mirror systems development. We have to document what these reports are supposed to show, and we have to document what they actually show. Then, we have to test the process, and the results.

Ta Da!

When I was a kid, I tried several times to make a product from the bowling pins my father swapped out of his bowling alley every summer. I bought a used lathe and I came up with ideas from mortar and pestle sets to small planters. Pictured to the right is a paperweight and paper clip holder. I would sell these things door-to-door, starting with a neighbor. I would always be excited and a bit nervous as I began the sales process. Sometimes, the initial feedback was negative, like when people realized that a top-heavy paperweight is an accident waiting to happen. This week, I had that same queasy feeling as we delivered our first homemade SharePoint solution.

Eight months after rolling out our workflow-driven process to manage engineering inspection reports, and three months after perfecting that process on the heels of a post-implementation review, we unveiled the management dashboard for the head of the department. This guy manages a group of engineers, so to say that he’s case-hardened is an understatement. We were optimistic, given that he had defined a few general concepts that he was interested in, but we were also a little nervous. After all, this is the first time we had built a dashboard. I have mentioned before that the hard part of introducing technology to people is getting the design right. It’s hard because you don’t know enough about their business to know how they manage it, and they don’t understand the technology well enough to know what to ask for. In an agile environment, you can work from a build-test-review-redesign cycle that keeps things flowing, but that process didn’t suit our circumstances. In this case, we needed to keep working while the customer travels and conducts business. He didn’t have a lot of time to interact with us. This time, we got a “here’s what I want” speech to be followed a few months later by a “let’s see what you’ve got for me” meeting. Fortunately, I have a resourceful team.

We took a pretty simple approach for a dashboard; low on glitz but high on useful. We worked from a web part page with four columns which gave us a pretty good canvas. The left column holds the aggregate statistics about the current activity, including the things that might be going off the rails. The right column presents the historic view of this process, including the reports we are back-filling into the library. In the center is a group of detailed activity by engineer – one column for the current year and one for the prior year. In addition to presenting the information requested, the parts we assembled illustrated the key things we wanted the VP Engineering to know we can do, including:

• We can count things based on metadata and content type.
• We can perform date math on various status milestones. As I read that, I feel cheated, since it took a lot of work to figure out some of the bits and pieces of date math.
• We can create a wide variety of views that let you quickly drill down into the details behind a particular statistic.
• We can group things by person, type, facility, date, or any other attribute you like.
• We can perform basic math and logic functions like Average, Total, And, Or, Not, etc.
• We can use fonts and colors to draw your attention to certain elements (although we didn’t spend a lot of time proving this).

Jane Zupan at Nuxeo introduced me to a phrase that I love – Content-centric Applications. I told her I was going to steal that phrase to describe this process; because this is a business application. It just happens to be gleaned from the normal processing of reports that used to be tossed onto a virtual heap called the K: Drive. This is truly the beautiful part of SharePoint, the fact that we can collect, store, manipulate and display data about a process during the normal course of a business activity, and then turn that data into information.

Drawing conclusions from the demonstration, I’d say we met our goals. I counted at least three “I like that’s” and a couple of “nice’s”, and the all-important “whoa, what the heck is going on there?” That last observation led to a request for a few changes, but the request itself indicated two important things to me: 1) The VP understood the tool we had given him, and 2) He had begun to understand what else we could do. That’s a win as far as I’m concerned. We have a little more work to do before we can put this project in the “done” column, but we aren’t throwing anything away and we aren’t far from the bulls-eye.