Not Fit For Print - Robert Bogue [MVP]

Mentions: K2 SharePoint Governance Series Interview

Robert L. Bogue — Tue, 15 Sep 2009 10:17:00 GMT

I had the pleasure of being interviewed by my buddy Chris Geier at K2 for a new series he's starting on SharePoint Governance. You can find his introduction to the series here and the download for the interview here. Check it out.

XML, XPath, and Namespaces

Robert L. Bogue — Wed, 09 Sep 2009 17:03:00 GMT

One of the problems that I had early on with XML when I started was that I couldn't figure out an easy way to handle namespaces when I was processing XML. SharePoint and other Microsoft technologies like InfoPath make extensive use of namespaces. For instance, if you right click a field in InfoPath and select Copy XPath you'll get something in your clipboard that looks like: /my:TestForm/my:Repeating/my:Message --Frankly, that's not all that complex of an XPath statement, except that it has a namespace in it. In this case we don't know what "my" refers to. That made it easier for me to transform the XPath statement into /*[local-name()='TestForm'/*[local-name()='Repeating']/*[local-name()='Message']. It's frankly not that big a deal except that it's somewhat tedious. This allows me to call XMLDocument.SelectNodes(string xPath) instead of XMLDocument.SelectNodes(string xPath, XmlNamespaceManager nsmgr) which was good because I didn't have a namespace manager and I didn't know how to create one easily. However, I ran into a new problem that my quick solution didn't allow me to get around. I wanted to add a set of new nodes to an existing document -- in that case I couldn't ignore namespaces any longer.

After a bit of gnashing of teeth I realized that I can create a XmlNameSpaceManager pretty easily by looking at the attributes of my document element (DocumentElement) node. Take a look at this code:

XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);

foreach (XmlAttribute attr in doc.DocumentElement.Attributes)

{

if (attr.Name.IndexOf("xmlns:") == 0)

{

string prefix = attr.Name.Replace("xmlns:", "");

string nsUri = attr.Value;

nsmgr.AddNamespace(prefix, nsUri);

}

In this snippet I use the document element attributes to create my namespace manager -- thus I can use the same namespace prefixes as are in use in the document itself. (Forgive me for using .Replace() rather than .Substring() - I ultimately decided it was more readable.) Taking this scenario a bit farther, with the namespace manager I can create a node of <my:Message /> with:

XmlElement ele = doc.CreateElement("my", "Message", nsmgr.LookupNamespace("my"));

This abstracts out what the namespace actually is so that I can just reference the existing prefixes. With the element created I can set its InnerText property and then use XmlNode.AppendChild() to append the new element into my document.

Since it's easy to create XmlNameSpaceManager objects now ... I might have to forget my *[local-name()='foo'] trick... although it's still useful when I'm leveraging Xml editing tools and I don't have namespace support in them.

MOSS Built In Site Column Table

Robert L. Bogue — Tue, 08 Sep 2009 14:21:00 GMT

I needed to get the site column IDs for some of the built in site columns and while there are several places on the Internet where you can find the technique for pulling them out of the URL when editing a field that was going to be a bit tedious for what I was going to do so I wrote a quick utility that would dump out the site columns to a text file. The resulting XLS file is available here.

I hope that it helps if you're looking for a specific field IDs and you don't want to URL decode them.

Moving SharePoint Development Forward – p&p SPG

Robert L. Bogue — Sat, 05 Sep 2009 09:15:00 GMT

One of the things I like best about my work is that I get to work with some great people doing fun and interesting things. I can honestly say that in our small part of the universe we manage to push the ball forward. I've had the pleasure of speaking at the SharePoint Best Practices Conference as well as other events – to try to share the things we've learned about how to develop scalable, maintainable, robust applications on the SharePoint Platform. One of the things that I have the most fun with is helping the Microsoft Patterns and Practices group put together their SharePoint Guidance. The first iteration we worked on basic collaborative applications. The second iteration (this one) we took a look at web content management scenarios and line of business integration.

Certainly I don't expect that everyone can use all of the work that was done here – however, I expect that it's more than worth your time to take a peruse through the materials. I know you'll find at least one thing that you didn't know or didn't think of before. I know that because there were tons of things that I didn't know about the platform – or hadn't considered – that I learned.

Go check out the latest version of the SharePoint Guidance from p&p

Hop to It

Robert L. Bogue — Mon, 31 Aug 2009 21:33:38 GMT

Marcy Kellar has been trying to convince SharePoint folks to jump for joy – or just because they're intoxicated. So when Andrew Connell came up to do the SharePoint Users Group of Indiana (SPIN) she convinced a few of us to have our pictures taken. Despite not having anything alcoholic to drink, I decided to be a good sport and jump.

Mentions: A Shepherd for SharePoint

Robert L. Bogue — Mon, 31 Aug 2009 21:30:00 GMT

I did an interview with Beth Schultz that appears on TechTarget. In the interview I talk about the book, governance, and a bit about my video project.

DPI is Danger

Robert L. Bogue — Fri, 21 Aug 2009 22:32:11 GMT

So twice in the space of a day I've been confronted by some dodgy information about DPI – Dots Per Inch – and about how it applies to the world. Let me first say, that I think that thinking about DPI is about the dumbest thing the desktop publishing industry has inflicted upon us. I say that because it's a useless number on its own. Let's say, for instance, that I scan something at 300 DPI. Can you tell me if it will fill a modern screen? No – you can't. You can't do that until I tell you how large the original scan was. If it was more than about 3 inches by 2.5 inches, it will fill a 1024x768 monitor.

The real answer when dealing with graphics is knowing how many pixels (individual dots) you need in order to fill the area you want to fill. DPI is the measure of the maximum resolution of the output in a given space. i.e. 300DPI means that you can fit 90,000 pixels in a 1" square (300x300 = 90,000) If I want to be able to output at full resolution I need a file with a resolution of at least the number of inches times the DPI.

The good news is that people rarely talk about DPI when talking about digital photos … until someone with a desktop publishing background steps in the room. Digital cameras are measured in megapixels (or resolution not pixels per inch.) Occasionally you'll hear folks talk about 72 DPI screen images – however, this is a misnomer on the PC since the resolution and screen size are not tightly coupled. My 15.4" Lenovo laptops 1920x1200 screen has a different number of DPI than the 26" external monitor I connect it to – but both have the same resolution.

Typically when you hear DPI, You heard about it from people talking about a setting for scanning. The interesting thing is that oversampling (scanning at a higher DPI than the output device could produce) can cause some real ugly scans – and some problems for trying to get an image to look right. If you know the resolution of the output device you should match that in order to get the best results. Having a bigger file with a higher resolution generally doesn't do much harm – but it generally doesn't do much good either.

So … PLEASE don't talk about DPI. Talk about the resolution you need.

Things Look Different On the Way Down

Robert L. Bogue — Thu, 20 Aug 2009 06:25:00 GMT

For the last few days I've been riding ATVs with my friend Paul Thomas. I've been posting a smattering of photos on Facebook. The scenery has been beautiful but the trip hasn't been just about the photos or the riding, it has been a chance for me to recharge and to reflect. During the riding I've noticed a few things that apply to my day-to-day in the grind professional world as much as they do to the riding.

Things look different on the way down. I don't mean that from the perspective of falling from grace, but rather looking at things from the top just isn't the same as looking at them on the way up. You just don't see the same things. You sometimes see more and you sometimes see less. However, fundamentally, you'll see something different. I can't tell you the number of times over the last few days that I've completely missed something going up the trail and saw it plain as day on the way back down. You come around a corner that you had your back to and have to say "Wow!"

Here's an extreme example of a different view on the way up vs. on the way down. Here's the photo on the way up:

Here's the same location from the top:

There's a dramatic difference. From the top you can't really tell what's going on down there. The building looks like it is leaning but it looks like it is leaning back not forward and ready to roll down the mountain.

I bring this up because too many people believe that it's impossible for the folks at the top to not see the problem. The problems of the organization seem so obvious for those who are there – how could anyone miss it. Well, hopefully as these photos have shown, it's not that they don't see the problem; it's just that they see the problem differently.

So what do you do about it? Communicate. Help your manager understand what you're seeing and accept that what they're seeing is very different. You may not be able to see the situation from their perspective, but hopefully you can appreciate that they do have a different perspective.

This difference in perspective isn't constrained to just management – different parts of the organization will see things from a different point of view and therefore have different concerns. Hopefully you'll be able to see that they have different perspectives too.

The Fifth and Sixth Most Common Delusions of a Corporation

Robert L. Bogue — Tue, 18 Aug 2009 09:21:00 GMT

Recently I posted The Top Four Most Common Corporate Delusions. I then got on a plane with a buddy of mine to go ATV riding in Colorado and he added two more to the list. (Email me if you have your own to add to the list.)

His addition for fifth place is: "We have good people." Ouch. This one seems to me like it's personal. Unfortunately, he's right. There's this general disconnect between sagging stock prices, tumbling profits, and the realization that there can really only be one explanation within an organization – it's people. Ask someone if they've ever worked with someone that they felt didn't deserve their job and you're sure to get a yes if they've had a job. (Be careful about asking this in state and local government, you may get hit as they instinctively raise both hands and then start hopping up and down like a jack Russell terrier.)

More importantly folks can either blame the organization as a whole (including its systems and people) or directly blame people for the relative success. The seemingly obvious escape clause to blame the organization doesn't really work – because the organization has been created by its people and thus they're ultimately responsible.

In the successful organizations I've seen a lot of emphasis placed on hiring the right people. One successful organization was interviewing me for a director level position and we spent about 6 weeks before I decided it wasn't for me. (This was back when I was considering working for an organization.)

The addition for sixth place is: "We're Competitive." This one is a little bit harder to address because being competitive in the market means being well suited for competition and it's hard to determine what might make you well suited for competition. For instance, Indiana, where I live, is located in the center of the country. Today it's a transportation hub with good interstates and plenty of logistics companies. However in the late 1800's there was still some development needed. Indiana didn't have a canal system like some of the neighboring states so we were missing out on the canal traffic. Unfortunately by the time that Indiana got around to building the canal the railroad had been invented and all but killed the use of canal shipping – invalidating a huge amount of capital the state had spent to develop the system and as a result bankrupt the state. (Ouch.)

Canal shipping was quite competitive in the pre-railroad days. However, in the post railroad days it just simply wasn't the most effective way to get goods from one place to another. Most organizations don't face this sort of radical transformation in the industry all that often – but they do happen. So what's competitive today may not be competitive tomorrow. (How's that for a happy thought?)

We sometimes delude ourselves that the number of sales is the only metric that matters. That if someone buys our product or service – we must be competitive. However, that's not necessarily true. Everyone gets lucky. Every buyer ends up buying something that isn't the best deal at some point. (Don't think used car salesman – please.) When transformations hit an industry they can be quick or slow – but it's likely that you won't see the change until much later than you want.

The only way to keep competitive is to behave like you're never competitive enough – constant, relentless improvement won't guarantee that your product won't become uncompetitive (the best canal system in the world wasn't going to compete with the railroad), however, it makes it more likely you'll see the change, redefine yourself as a transportation company, and start building railroad lines.

Top Four Most Common Corporate Delusions

Robert L. Bogue — Sun, 16 Aug 2009 08:59:00 GMT

Delusion is a strong word. It's a word used in psychology for "a fixed false belief that is resistant to reason or confrontation with actual fact." It is a word associated with disorder. I use that word here to describe the beliefs of some organizations because I see these things as so wrong, so completely incompatible with reality that I wonder how it's possible that anyone in an organization can possibly believe them.

I should say that not all corporations share these delusions and I should also say that the larger the corporation is the higher the probability is that they have them. I've been doing consulting for a long time so I've had the good fortune to work with many different organizations. In that time I've run into all sorts of structures, people, and delusions.

Here are the four most common corporate delusions from my observations:

We're unique and special. (No one else has anything close to our needs.)
We're productive. (We get things done.)
We're effective. (We get things done that matter.)
We have a specific process. (We know what we are doing.)

I'm going to dive into each one of these delusions and expose why they are so insidious.

One: We're Unique and Special

Having been a consultant full time or part time for the better part of 20 years, I've got to say to everyone: You are unique. You are special. You just as unique or special as you believe you are. I'm sure you've run into challenges that no one else has. However, that's the exception. It's not the rule. You don't pave every path. If you did you'd never get anything done. (See item #2.)

Here's the problem. Because you believe that you're unique you don't listen to experience. You hire experts to come in and help you with your problems. They produce beautiful full color reports, graphs, and presentations. You applaud the research. Your marvel at the insight. However, in the end when it comes to implementing what the consultants have recommended someone stands up and says "that may work for the industry, but it doesn't work for us" and the plans get put on hold until someone can quell the objection – but no one can. The problem is that everyone wants to believe their organization is unique. They want to believe that their organization is special. How can you prove – without implementing – that the recommendation isn't right?

In the end, the nay sayers freeze progress. So if you're smart you'll actually implement the expensive advice that you've paid for.

Two: We're Productive

We want to believe that we get things done. Each of us processes our mail. We attend the company meetings. We do the required training on sexual harassment. (We should be REALLY good at it by now.) We go to the implementation meetings for the strategy (or insight) in the last book the CEO read. However, if you take a step back you've got to wonder. What actually gets done?

Do you deliver the projects that you're working on "on time"? What about "on budget"? Do you walk into meetings where people around the table whine about the number of meetings and the lack of time to get things done – in order to support the fact that they didn't get their action items for the team done? Does anyone ever wonder why you need so many meetings? Could it be because you have to have the same meeting over-and-over again because team members don't get their action items done? Could it be that we don't do what we know we should do – document decisions, issues, action items, and risks?

We are busy. That's easy. The question is whether we're getting things done. In most large organizations, I can say that things don't get done. Projects just slowly take longer than planned. They release with half the features. In the end everyone has a party and drinks enough to not remember what they had originally planned. (I believe this is why many project charters end up missing.)

Three: We're Effective

Some organizations have implemented Six Sigma, Project Management Offices, Project Dashboards, and other techniques to keep projects from falling off into oblivion. These organizations have made it much harder to avoid accountability – good for them. However, somewhere along the way they've sanitized the sanity right out of the process. Some of my clients won't accept invoices via email. Why? That's a great question – and one that no one can really explain. Some claim it is compliance. (Yet, SOX doesn't have a requirement to kill trees – although admittedly it's good at that.) Others claim "we just don't do things that way" – with echoes of "We're unique and special."

In the end, the organization ends up making copies of documents, mailing them across the country to be signed and returned. Checklists are created to manage the documents that are out for review. Reminder mails are sent to indicate that the required approvals haven't been provided yet – and the machine churns on and on and on. We know that these processes aren't efficient but no one is willing to stick their neck out to fix them. The delusion that the organization is effective remains.

That isn't to say that there aren't executive retreats where some high priced consultant comes in to draw arrows and blindfolds the whole team and ask them to grope around the room. (Now you know why there are so many sexual harassment training sessions.) That isn't to say that there isn't some super-secret lofty strategy of how the organization is going to dominate the world by building a better mouse trap. However, implementing any of the important stuff that would really drive the business forward tends to get stalled. The transmission between the strategy and the tactics break down and at some level the same things are discussed at a new resort with a new consultant the next year.

The organization should be constantly evaluating its processes to identify which ones are helping it to be effective and which ones are creating work for people who don't need it. Remember we're all too busy. We need to make it clear how to implement the strategies that will drive the organization forward by converting them to specific tactics and assigning those tactics to specific people.

Four: We Have a Specific Process

Somehow when I entered the business world I developed this mistaken impression that corporations actually knew what they did. I couldn't have been more wrong. When the ISO9000 craze hit manufacturing I was blown away. When I got into it I realized that really all ISO9000 said was … "say what you do and do what you say." I thought this was plainly obvious. (I'm glad they didn't have to tell us to breathe.) In my work with clients I get to work on workflows. I get to ask them to describe their processes so that I can automate them. If would frighten you to know how many corporate "processes" aren't processes at all. Instead they're a loose collection of steps that most people "sort of" understand.

I've walked into meetings and watched spectacular fights erupt as different business users argued vehemently about how a process worked – or didn't. I've seen just short of literal fist fights as people had been working a process for years and fundamentally didn't agree on how it worked – let alone why it was being done. I often ask questions and get answers of "I don't know" – when I'm asking simple things like what happens when something doesn't fit the process. There's no standard procedure for handling exceptions – or even recognizing that an exception has happened. (That's why you should be prepared to follow up on anything important.)

At a high level most organizations understand their large processes. However, the devil really is in the details. They can't tell you what happens when they receive an invoice that doesn't have a valid PO# or contact person on it. (Actually, I believe they are routed into special micro black holes that the accounting department has.) Ask what happens when a shipment arrives that no one authorized. Ask what happens to a customer order when the order was accepted but the customer is over their credit limit.

Organizations need to understand their processes – enough that they can figure out what things are falling out, what things are taking too much time, and where they can optimize.

The Doctor's Prescription is Simple

These delusions aren't actually that hard to resolve – they're all solvable by holding people accountable for improvement. You see. You can't hire high priced consultants in to produce reports and then not do anything about them if you're accountable for those funds. You can't fail to be productive and effective and not create improvement. You can't improve until you know what you're doing.

Startlingly, few managers are willing to deal with the backlash that will come when people are actually held accountable for what they do or don't get done – that is until the board has to hire a turnaround specialist to bail the organizations out before it goes out of business for good. (When faced with job loss most people will do what it takes to be successful – even if it means being held accountable.)

To be clear, I'm not attaching specific organizations. I'm not saying everyone has these problems. I'm saying I've seen these things more than I should have in my experience. I'm also not saying that small businesses have a lock on the world of doing things right. I make plenty of my own mistakes. I have plenty of my own delusions – however, hopefully I'll listen as my friends, partners, customers, and vendors point them out to me.