Thursday, December 29, 2011
Book Review, Professional
It takes a lot of moxie to call yourself a definitive classic. However, the subtitle of The Adult Learner is probably correct. I picked up the book because of my work on the SharePoint Shepherd Presents DVD series. The goal of the series is to make learning more accessible to people who need it. The series started with some preliminary research on the challenges of getting specific content at a time that was appropriate. I was being asked by customers – who were ready to make a move – when there would be a conference they could attend that would have what they need. Even with the conferences cranked up to full speed it was an average of three months away for someone to get to the conference that would get them the information they wanted and even then there would always be gaps. A conference organizer has to pick and choose with limited slots what content they want to have delivered. All of this lead to the realization that we needed a way for people to get to the information they needed – when they needed it.
This is consistent with Andragogy – a framework (or set of techniques) for teaching adults. Before I get too far into this discussion I should say that The Adult Learner goes to great lengths to discuss the validation – or lack thereof – of the andragogy principles. From my point of view the primary issue, raised in the book, is that there's no effective way of measuring learning in a broad sense. That brings us to the difference between education and learning. Education is about the acquisition of knowledge or skill. Education is therefore difficult to measure. You can measure recall of the information but since usefulness – what we're aiming for – can only be measured in context, it's notoriously difficult to measure education. Learning, however, implies a change in the behaviors of a person and those behavior changes may be able to be monitored – except that there's no psychometrically valid instrument to do so – yet. (Psychometrics is completely oversimplified as applying statistics to psychology mostly to measure education and learning.)
All of that is to say that we believe that the principles of Andragogy are appropriate for most adults, however, there's not a lot of hard numbers that are available to support this belief. Andragogy was moved forward most by Malcolm Knowles (one of the authors of The Adult Learner) with what became six basic principles:
- Need to Know
Trying to put these together into a single context; it's clear that adult learners need to be trained at the moment in time that they need the learning (readiness), why they need to know a piece of information (need to know), that they have the foundational concepts necessary to integrate the new information (foundation), and that they have an understanding of the problem they are trying to solve (self-concept). The training must be focused on solving problems (orientation) and the motivation for learning must map to the internal motivations of the student (motivation).
In addition to the core framework of Andragogy, there are numerous other citings and alternative views presented. The Adult Learner explores why adults choose to learn – to solve a problem, to develop a social network, or for the joy of learning itself – as well as reasons why adults reasonably reject learning.
The Adult Learner also explores the tension between Andragogy and the needs of human resource professionals who are charged with training the organization in the key skills it needs to be safe and effective. Andragogy proposes that learners should be in greater control of their learning experience – that they should be self-directed – and yet human resource development would dictate that the organization has certain needs for skills that employees and volunteers must be taught.
I believe that if you're trying to teach adults, whether it is as a content or a courseware provider, an instructor, or a learning professional, you should read The Adult Learner.
Sunday, December 25, 2011
Book Review, Professional
David Meerman Scott shares his view of how the rules have changed in The New Rules of Marketing and PR. There's a subtitle longer than your arm that seems to include every possible keyword that anyone who is doing marketing might be looking for – I was not really interested in trying every possible approach to marketing. After all I'm not checking off items in a list. I want to try to figure out how to make my marketing effective.
To over simplify the message – you're not trying to get attention – you've got attention – you're trying to educate the market on your value proposition or build credibility through your content so that they'll come back to understand your value proposition. Instead of building a site to sell to a prospect, you're creating a place for the prospect to learn about you and what you know. As a consultant I can say that I learned a long time ago that there's a certain amount of "spilling the candy" that has to happen when you meet a new client. That means that you have to give the client some of the answers so that they know that you've got the rest of the answers to their questions.
The interesting bit about this is that you can't spill ALL the candy – you can't solve every problem for them – but you have to create the credibility that comes with having answers to their questions. This would tend to leave you with the idea that you shouldn't share everything you know on your web site or blog – however, this misses an important point (or two). That is that you'll never be able to codify all of your knowledge on to your web site. There are nuances and details that can't be communicated until you're literally in the situation. I can tell you everything you want to know about SharePoint Workflow, professional SharePoint Development, Information Architecture, however, having to put all of the pieces together from a few dozen blog posts, articles, and presentations, there will be gaps that will refuse to be filled. (Sidebar: I'm spending a great deal of time refining my posts, articles, and presentations into the SharePoint Shepherd Presents series of DVDs to ensure that those gaps are filled.)
A key area of focus for the book is Personas and their power to help focus your marketing efforts. I was exposed to the idea of Personas through work with Microsoft. These fictional characters represented an anchor for product development – and they can do the same thing for marketing. It's really hard to target everyone because so often in targeting everyone you're targeting no one. So personas give you a way to anchor to a specific ideal person. Of course, the persona is fictional, just a made up person but the story of that person is the story of your target buyer or buyers. A persona consists of a bit of demographic data basis… including the age and gender of the person who buys what you're selling as well as a picture and a made up story of their background to make them more real. There's something magical about thinking about a specific person to focus your thoughts. Personas are a way to help you get to marketing messages with a target.
One of the other encouragements in the book is to learn the language of your customer and use those words – rather than the words that you would normally use – to improve the chance that the prospect will resonate with the message you're sending. If you're selling training (as I am) it might make sense to talk about ILT (Instructor Led Training) or CBT (Computer Based Training) rather than talking about training in general – or making the assumption that all training is ILT. Scott recommends researching the magazines the prospect is reading, reading the conference packets to understand what is being talked about, and anything that will help you better understand the concerns the prospect is facing and the language that the prospects are using.
If you've been reading my blog for a while you know that I've been reading and reviewing social media books for a while. (See: Wikinomics, Blink, The Wisdom of Crowds, Linked, and The Long Tail) As a result I'm no stranger to the idea of using social media as a platform for driving business forward. Scott delivers more push around ideas for leveraging the power of social media from giving eBooks away to participating in the social networks that operate today.
The book wraps up with the idea of using press releases targeted to the consumer instead of the press as a way to get better search engine optimization and as a way to communicate with the consumer. I can say that I'm not a big fan of this approach. Having run a web site for Internet.com where I was reposting press releases as stories I can support the idea that journalists are hungry for content they can repurpose and use, however, I never saw much response to the work I was doing.
The New Rules of Marketing and PR is a good survey of concepts for marketing and a good read if you're looking to sharpen your focus on marketing efforts.
Saturday, December 24, 2011
I vividly remember working in publishing in 2000. We had just survived what was supposed to be the cataclysmic events of the millennium. Of course, we were not plunged into some dark abyss where power plants stopped functioning and traffic lights started showing green in all directions. Microsoft was talking about moving Microsoft Office to the server. They wanted to play in the document management space. They also had a rag-tag group of folks from Vermeer Technologies who were demonstrating interactive web sites with FrontPage extensions. The result was Microsoft releasing SharePoint Team Services (STS) and Microsoft SharePoint Portal Server 2001 in relatively short succession.
The problem was that STS and Portal Server were as different as night and day. Portal server was built around the Exchange database engine and STS was built around SQL server. Portal server was focused on documents and had versions. STS was built around lists of items and didn't have versions.
Ten years ago there were expensive document management systems were expensive. You only implemented them if you had a major process to automate. Lists were being created with Microsoft Access – or more commonly Microsoft Excel but sharing and managing that list data was difficult. Inside an organization the spreadsheets would fly back and forth. The lists were shared externally via email as well – sometimes unintentionally. Coordinating changes was a huge challenge.
I started building on SharePoint in 2001 with a project designed to improve the ability for a packaging company to communicate with its partners. It was innovative at the time – and it meant struggling through the development on a platform that wasn't really ready for people to program on it. The version of the Exchange database engine that SharePoint used had issues – and it wasn't really designed for what it was being used for so we found quirk after quirk. I vividly remember that none of the monitoring tools would tell us that SharePoint was down because deep in the core SharePoint would send an HTTP 100 Continue message if it ever couldn't respond quick enough. That's great if you're waiting on the database to return a record but horrible if you're in a deadlock situation where the resources are all consumed. It meant that we had to write custom tools to plug into the monitoring tools to detect if SharePoint was down.
The 2003 versions of the software moved Portal Server to a SQL database engine but lost versioning in the process. The net result was organizations that really couldn't upgrade because they had built processes around the versioning – sure there were the backwards compatible document libraries in 2003 – but that was just the same as leaving 2001 around since they still ran on the Exchange database engine and had a completely different set of features which served to create confusion.
By about 2005 my entire world became SharePoint. Instead of doing ecommerce development I was building intranets and integrating systems into SharePoint. Mostly it was moving from a system designed to support external folks to supporting internal folks. The real benefit was that I was used to high-activity web development which most developers of the time weren't used to – and in many ways high volume web sites is still a rarity.
In 2007 portal server was dropped from the name and Office was added. This reflected the much stronger integration to the Office client applications than had ever been possible – but the loss of the word Portal was the definite signal that the world had changed. It used to be that everyone wanted a portal, a place from which everyone would launch into the corporate resources. However, by 2007 it was clear that the word portal was too fuzzy and confusing to be useful. After all, we were in the age of search, not the age of portals. Yahoo had lost to Google.
In 2007 we were finally back where we started with versioning with a few enhanced features along the way, like our new workflow engine. However, the big change was less about SharePoint and more about the transformation SharePoint had caused – or at least participated in. By 2008 the document management market was starting to soften. People realized that the big systems for document management weren't needed so much anymore. SharePoint 2007 might not handle large organization document management needs but most organizations could see value by using SharePoint.
By 2010 we finally had the set of tools in the product to support larger scale document management scenarios. Development tools were integrated into Visual Studio so we didn't have so much heavy lifting. No longer were we hand-crafting XML, Text files and creating CAB files. Finally we can focus on getting things done rather than dealing with the mechanics of SharePoint development.
I had the honor of spending 10 months working on the Microsoft patterns and practices SharePoint Guidance – so we've finally got some good guidance for SharePoint development. In short, I believe we've finally got a platform for development.
Today, we're thinking about enabling corporate developers to create solutions by developing code in the Sandbox. We're looking at enabling organizations to have SharePoint hosted in the cloud. Strangely while I'm having conversations with clients about Sandboxed solutions and the cloud very little of what I do fits in either of these categories.
It's a pretty different world than 10 years ago when I started – but I believe it is honestly a better one – at least when it comes to SharePoint.
Saturday, December 24, 2011
Like it or not, 2 out of every 3 organizations are using SharePoint, Microsoft's unstoppable platform for communications, collaboration and information management. SharePoint can be a great tool for learning organizations and it represents potential competition for a learning portal. The good news is that SharePoint's array of options for integration that make it an ideal platform to marry up with an existing Learning Management System (LMS).
Saturday, December 24, 2011
Several times over the last few weeks I've been confronted in one way or another with the need to protect coding from the interloping of the user and site administrator in SharePoint and conversely I've seen attempts to pour concrete around development that could be better left in sand so that it could be changed and moved. Through this I realized that there's a need for better understanding around the model shift with SharePoint and its impact on software configuration management (SCM).
SharePoint's a Different Kind of Animal
It's often been said that SharePoint is a desert topping and a floor wax – paying homage to Shimmer a fictional product from Saturday Night Live. It's also been said that SharePoint is like the proverbial elephant discovered by five blind men – each having a different perspective of what the animal is. Even within SharePoint you can see very different parts of the platform, however, some of the most interesting changes aren't about the product itself but in the things that it enables organizations to do.
By removing the barriers to creation (what Microsoft calls composites) the tool allows business users to create solutions to their problems. They dynamically create storage for new kinds of information – which in the past required a database administrator to create a table or add a column. The business user can string together a list, a workflow, and some alerts and create a system for managing or supporting some business process. The agility afforded by this toolset means that changes can be made at any time. In SharePoint many of these changes are version controlled so if a mistake is made the user simply reverts to the previous version.
This agility is in stark contrast to the structure of a large scale development effort. Organizations spend an inordinate amount of time building structure around the software development process so that systems can be recovered and recreated. This effort is necessary in a world where specialized skills are necessary to create and maintain systems. You simply can't have the payroll system changing everyday – and changing in ways where it's difficult to explain to an employee – or the government – why a person was paid exactly what they were paid. So there are source control systems where code is maintained and controlled. There are configuration management practices which are used to govern changes to the system.
All of this leads to both repeatability – you can restore to any point in time and replicate it anywhere at any time – and control. This is desirable from a recovery perspective. These two outcomes are very desirable in a traditional system – and since traditional systems don't allow users to create solutions on their own their relatively limited flexibility and need for coordinated activities is not a major barrier.
The real question comes when the rigidity of a SCM meets the agility of SharePoint and we have to answer hard questions about whether something should be treated as traditional code or whether it should live in the user world of agility.
Mapping the Extremes and the Middle
Even in SharePoint there's some level of clarity that some things are software development and need SCM. If you're deploying farm based solutions there's a need to have a brief outage as the software is deployed – this is a clear reason to control the rate of deployments of solutions. Equally clearly if you are adding a contact to a contact list, you know that this is content and therefore should be handled like content – instead of being handled like code. That's the easy part. Where it gets more difficult is when you look at items which are markup languages and non-compiled languages.
Consider that Cascading Style Sheets (CSS) controls the look and feel of the web site. It's a language for expressing how the display should look. Most folks don't consider CSS to be a programming language; it's a markup language much like HTML. However, there is a sense that CSS should be protected like code because it has a great potential for causing issues on the site. Yet, many new web parts need their own snippet of CSS to work, sometimes overriding the behavior of the code CSS for the solution.
Like CSS, eXtensible Stylesheet Language Transformations (XSLT) isn't a programming language. It's a markup language with potentially huge power to change the appearance of the site. With that sort of power it "feels like" it should be a part of SCM and managed. But what about the XSLT used to format search results, or the results from a Really Simple Syndication (RSS)? It seems like our rules break down when the same technology is used for core system things and for user controlled formatting of resulting data.
In SharePoint we also have the unique challenge of SharePoint features and the XML they contain. XML can tell SharePoint to create a content type, a list or even to create data. So does the XML that sets up your list and the sample data count as code – or content? Making the situation more challenging is the user code host – sandbox execution – which allows compiled code to run in a restrictive environment.
Does your head hurt yet?
Criteria for Decision Making
It used to be that we could make a simple decision. If it was compiled it was code – and if you didn't have to compile it then it wasn't "real" code. However, over the years the lines have blurred to the point where making the decision based on the file type doesn't work. Instead we need to make decisions based on the intended use of the file.
Breaking down intended use a bit there are two key things to think about. First, what's the worst that can happen? In other words, if the file gets modified, out-of-sync, or destroyed what's the worst case? Second, how are changes going to be managed?
In the case of what's the worst that can happen, you might have a style sheet that drives the rendering of the entire site. In this case the impact of the file being modified or deleted is pretty large. As a result you would want to protect against that. Conversely, if there's a style sheet that is responsible for a minor part of the web site – it might be OK to treat that as content. SharePoint has built in version control and a recycle bin so recovery should be as simple as reverting to a previous version or recovering the file from the recycle bin.
The other side of the coin is how the changes are going to be managed. If you go the code approach to management you have to go through the configuration management process to deploy the code to controlled environments. This can add weeks and weeks of time to the deployment cycle. If there's any need for agility you can't treat it as code. Conversely, if the item never or rarely changes it might be acceptable to treat it as code. When making the decisions you should consider how many variations of the same thing that there may be – if there are many variations it's harder to manage them as code.
Of course, some items, those items which are compiled code that can't be deployed to the sandbox must be treated as code and managed through the software configuration management process so the decision has been made for you due to technical or design limitations. For everything else, the question is how you're planning on using it.
Making it Concrete
Treating anything with a configuration management process is like pouring concrete around it. It's certainly possible to remove something buried in concrete by breaking the concrete out and starting over – but it's not nearly as easy as pulling up stakes and moving on. There are some things you need to pour concrete around. A backyard basketball goal needs concrete to steady it. However, Pouring concrete around the stakes of your tent may not be the best choice. Pour concrete when you need to – and avoid pouring concrete when you don't need to.
Friday, December 23, 2011
You may have snuck SharePoint Foundation 2010 under the radar, or it was an official but unfunded project. You're trying to figure out how to get the support you need for the new intranet the organization needs or to extend it to the Internet so you can get partners engaged and get some real value from the platform.
However, you can't seem to find an executive sponsor to drive the project forward.
All of the "experts" keep saying that you need to get executive sponsorship or executive buy-in, but they're noticeably absent on how to make that happen. So here are four tips on how to get your executives to buy into SharePoint
Sunday, December 18, 2011
I don't have a huge marketing budget. In some sense I don't really have a marketing budget at all. That means that when I do marketing I've got to do it Guerrilla style. I can't fight the british in organized straight lines, I've got to use guerilla tactics to succeed. (This is a reference to the American revolutionary war.) Jay Conrad Levinson's book Guerrilla Marketing: Easy and Inexpensive Strategies for Making Big Profits from Your Small Business aims to show small business owners how they can do marketing without a lot of money.
A good place to start is what is marketing. Levinson says that it is "is the art of getting people to change their minds - or to maintain their mindsets if they're already inclined to do business with you." That's a pretty good definition – if you're sure that the market it is even aware that you exist and they're making an informed decision between competitors. (See my review of Sources of Power for more on decision making.) I believe that there's another option – the option that I find myself working with so my definition is "Creating awareness of your position and value in the market."
Levinson follows up with "More than half your marketing time should be devoted to your existing customers. A cornerstone of guerrilla marketing is customer follow-up." The problem with this is that in some cases, there's little to sell to existing customers. In my case, I've got two worlds, my consulting world and my SharePoint Shepherd /intellectual property (content) world. In the consulting world you can always sell customers more time, however, on the SharePoint Shepherd side the product offerings are narrow enough that there's not much to sell an existing customer. It's more about finding new customers when it comes to marketing for the SharePoint Shepherd side of the business.
From here Levinson starts to align better with my needs and says "reminds you that the main number that merits your attention is the size of your profits." That's sage advice. Particularly when evaluated against the noise of web site hits, click throughs, and impressions. For me the only number that matters for the SharePoint Shepherd is bottom line profit. I don't give a lick about click-through numbers if they don't lead to sales.
Levinson is keenly aware and relates the best weapons for the small business is ingenuity and agility. There are numerous stories of organizations of all sizes doing the unexpected – paving a new path – and being effective at it. These are things that most large organizations simply can't do.
Perhaps the hardest part of the book for me to read was the section on commitment – not because it was hard to read but rather because commitment is built on patience – and that's not something that I have an abundance of – honestly, I don't believe it's something that most folks have an abundance of. One ray of hope for me was the ability to leverage measurement to focus on more effective strategies of marketing. I've placed several bets down on the roulette table of marketing with several sponsorships over the last few months. I'm tracking each one to see how many leads it's generating. Further, I'm even starting to tag my BIOs in my public articles. If you look carefully you'll see that they're tagged with a specific tag that lets me know when someone clicks through. This ability to monitor what's happening is helping me to keep myself occupied a bit while I'm waiting on my different marketing activities to take hold.
Levinson also is helping me to remember that what is crystal clear to me may not be in the mind of my buyer. It makes sense to me that if you're offering your employees self-service help that your helpdesk calls will drop – however, that's a connection that not everyone will make so I'm trying to get better about making my marketing messages very specific and to clearly articulate the business value of licensing the Shepherd's Guide.
All-in-all, Levinson's perspective is right. It will help you to think about how you can do marketing even if you don't like it. (For what it's worth I don't like it.) Pick up Guerrilla Marketing and see if you can make a game out of getting more out of your marketing than you put into it.
Tuesday, December 13, 2011
One of the problems that happens when you put together a new virtual machine for development is you have to make a decision about how big you make the hard drive. Too big and you chew up space and too small and you're constantly fighting for space. Invariably if I use a development machine for too long it starts to run out of space – no matter how big I made the drive in the beginning. However, a lot of that space is just log files for the database. Every change in the database gets logged and since it's a development machine I'm not backing it up. In fact, I never backup the data in a development machine. So what I really need to do is set the recovery mode for the databases to SIMPLE so SQL won't make log files and then shrink the log files I already have. This isn't hard it's just tedious for the 20 or so databases that make up a SharePoint installation. So I started making a script and ultimately found one at http://codesnippets.joyent.com/posts/show/665 that I could tweak quickly to get what I wanted. Basically it was resetting the recovery mode to whatever it was when it started – and I didn't want that. I wanted to stay in SIMPLE recovery to prevent the logs from chewing up space again. Here's the script (with modifications):
-- From http://codesnippets.joyent.com/posts/show/665 w/ modifications
declare @ssql nvarchar(4000)
set @ssql= '
if ''?'' not in (''tempdb'',''master'',''model'',''msdb'') begin
declare @tsql nvarchar(4000) set @tsql = ''''
declare @iLogFile int
declare @sLogFileName varchar(55)
declare @RecoveryModel nvarchar(10)
declare LogFiles cursor for
select fileid from sysfiles where status & 0x40 = 0x40
fetch next from LogFiles into @iLogFile
while @@fetch_status = 0
set @tsql = @tsql + ''DBCC SHRINKFILE(''+cast(@iLogFile as varchar(5))+'', 10) ''
fetch next from LogFiles into @iLogFile
set @tsql = ''USE [?]; '' + @tsql + '' ALTER DATABASE [?] SET RECOVERY SIMPLE '' + @tsql
set @tsql = @tsql + ''; ''
--print @tsql --for debugging
exec sp_msforeachdb @ssql
Monday, December 12, 2011
Book Review, Professional
Where does Information Architecture begin and end? It's a question that I've been struggling with. There are so many impacts into user experience, visual design, navigation, etc. I tend to think of Information Architecture as the overall framework or structure. To me IA is the overarching thing under which many other disciplines fit. However, Jesse James Garrett sees the problem differently in The Elements of User Experience: User-Centered Design for the Web and Beyond. The book walks through his model for how he believes user centered design should work. The heart of this is a diagram showing five planes (or levels):
The book effectively walks through each of these levels and explains the relationship to the prior level – and the other concepts on the same level. So we move from a high-level strategy of what we want to scoping a project then defining its structure and so on. The book makes the point – effectively – that you need to focus on the bottom levels before moving up on the higher levels. This is pretty consistent with other things which build like change management. However, the good news here is that by exposing the linkages between the levels Garrett helps to provide arguments why the previous levels are important.
In general I struggle with user experience (UX) initiatives. Despite how much I know that a pretty interface is easier to use. (There's research to support this.) I still struggle with the black and white definition of right and wrong that some visual designers try to use for things which aren't quite so black and white and the insistence that an approach is right when there's been no testing to support that perspective. So I was somewhat concerned about this book – however, I found that the book kept to the key goals of improving efficiency and allowing the users to get their job done and didn't spend an inordinate amount of time about why changing from blue to purple would make people feel more powerful.
Because of the need to cover a breadth of topics the details can be a bit fuzzy at times. For instance, you'll find much better coverage of wayfinding in Ambient Findability: What We Find Changes Who We Become and Information Architecture: Blueprints for the Web but the coverage here gets you the basic concept so you can dig into more later.
All-in-all, this is a good place to start to learn about Information Architecture – because it's a good overview of Information Architecture and the related disciplines. Give The Elements of User Experience a read if you have time.
Friday, December 09, 2011
You've got a burning sense for the fact that your SharePoint project hasn't gotten the adoption you want. Perhaps it's your ears burning as others talk about the failure of the project to meet the adoption goals, or perhaps it's just a fire in your belly that tells you there's more to be had. Here are five tips to help you measure your success. Read More @ SharePointProMag