SharePoint Summit 2009 Recap

I have just returned from a fantastic trip to Montreal for the SharePoint Summit, where I taught one tutorial on making SharePoint work in the Enterprise and one regular session on Web 2.0 and SharePoint.    The sessions were very well attended (partially to my surprise) and I really enjoyed seeing a different side to SharePoint implementations – in the U.S., Consejo tends to see more commercial organizations and, while there were definitely a number of folks from commerical organizations, I saw quite a few Canadian governmental agencies represented as well.

Overwhelmingly, the questions about SharePoint remain largely consistent with the U.S.

1. What does SharePoint do well and where does it falter? 
   The answer to this question really depends on your needs.  I saw quite a few organizations who needed records management, for example.  However, as readers of CMS Watch’s SharePoint Report 2009 know, SharePoint does not have any real depth in records management; if that’s what you need, you should probably look elsewhere or find an add-on to improve SharePoint’s RM capabilities.  Beyond that (and imagining), SharePoint is a pretty mediocre player.  However, Mike Fitzmaurice  from Nintex (and his Microsoft days), made an interesting point: SharePoint doesn’t have to be the best at any one thing as long as it’s pretty good at a lot of things; partners, organizations or even Microsoft can add point capabilities to supplement what SharePoint does natively and cover a good deal of what organizations need to accomplish.  Interestingly, Mike made his point with a little “presentation zen,” by showing images that represented examples of the “best” animals in specific categories (e.g. Cheetah’s are the fastest land animals, the Bull Elephant is the strongest , a specific species of Shark is the fastest sea creature) and then comparing those “best of breed” animals to a human with a tool.  Obviously an elephant could lift, literally, a ton.  However, a human with a crane can best the elephant.
   
2. How do I control (govern) SharePoint in my environment? 
   This is something that I had the opportunity to give a keynote on during the conference.  I’ve also written a little about governance in the SharePoint Report 2009 and on SearchWinIt, in my article “Four steps to creating practical SharePoint governance standard.”  However, the short answer (if you don’t want to read the source material) is really about establishing “how” to use SharePoint within your organization.  Microsoft gave administrators some tools to limit growth or unused sites, but the tool won’t solve any real governance problems or create your policies.  Good governance has to be an explicit effort on your part.  You must actively engage in a process of policy creation and education to ensure your success.
   
3. Do I have to buy add-ons to SharePoint and/or why doesn’t Microsoft handle “this” out of the box?
   The answers to these questions are: “probably” and “by design.”  More often than not, organizations will have to buy/build/download add-on components to supplement SharePoint.  This isn’t necessarily a bad thing; Microsoft could not be expected to anticipate every need or “solve” any specific requirement in a way that all organizations may require.  In fact, as Mike pointed out, Microsoft explicitly excludes certain features and/or components by design.  Mike shared that even Microsoft does not have inifinite resoures and when deciding on what features end up in a version of the product and which don’t, the product team focuses on “platform functionality” over “improvements to the UI or scenario specific” features.  The expectation is that partners, consultants or customers will fill in the gaps.  This approach doesn’t work for every customer, so be clear about your own goals and how much you’re willing to accept with regard to “missing” functionality and/or capability.
   
4. What’s in the vNext of SharePoint?
   Only the Microsoft product team knows for sure.  However, what I did hear from people in the know is that Office 14 (the version number of the next release) will be largely evolutionary with some slightly cooler, but not revolutionary components.  The one caution I will provide is that point 3 (above) still holds true; don’t expect Microsoft to cover every base and you should still budget for consulting and add-on products in your implementation.

Beyond all of the points I’ve made here, SharePoint is one of the fastest growing portal products on the market.  There were over 300 attendees at the conference and, universally, everyone was legitimately interested in better understanding SharePoint – primarily because they had all committed to using the platform for some web-based application within the enterprise.  I’m excited to see what’s coming in the next release and encouraged by the excitement I saw at the summit. 

Rookie mistakes to avoid during the SharePoint implementation process

Despite what may seem like a virtual explosion of SharePoint in the enterprise, it has been around since 2001. However, because of the various architectural changes in the recent version, SharePoint's popularity has taken off. The challenge now is to ensure that it is implemented properly in your environment.

Read the full article here...

ECM Training from CMS Watch

CMS Watch recently released a new training program.  Their Fundamentals of Enterprise Content Management Technology aims to help educate organizations on ECM technologies.  The course has a broad focus from what "you're getting into" when implementing ECM technologies to how gather requirements (and a lot in between).  Even if you are working with  or plan to work with a consulting agency, it will greatly benefit your organization to be educated. 

 

From experience, educated clients are in a better position to make decisions about implementations than clients that have limited experience and/or education.  If you're considering implementing ECM technologies, I would highly recommend attending the course. 

Effective Project Management in Small Organizations

I've had the good fortune to work in a number of different organization sizes, in addition to working with a wide array of individuals, project types and technologies. In large part due to this broad experience, I've seen my share of successful, mostly successful (in spite of team member actions to the contrary) and failed projects. In all cases, I've learned a good deal about what makes project successful and not so successful. Particularly in small organizations (either in terms of employees or revenue), making projects successful proves to be challenging, since mistakes can't simply be brushed aside by adding more money, resources or both. As a result, smaller organizations need to be especially careful how they manage their IT projects. Unfortunately, these are the very same organizations that have little or no discipline around managing projects and, generally, think a bunch of really smart people simply "get it done."


Most recently, as Consejo was completing a series of projects for a medium-sized customer, I found myself helping them think a bit differently about managing projects -- gathering requirements, deciding what functionality "get in" to what phase, how to assign resources, how to perform solid on-going management and how to test and deploy the project once complete. While Consejo won't be involved in this next project phase, the information we shared with them is relevant for a great number of companies. As such, I thought it would be worth sharing what I shared with them. To that end, here are some general best practices we have developed at Consejo to help us and our customers manage projects to a successful conclusion.

• Make sure you understand what you want to build
  Another way of saying this is "make sure you document, review and validate requirements." I suppose this goes without saying, but Consejo has done work for more than one customer who felt that the business users (the folks who create requirements for applications or IT projects) simply needed to "tell" the IT group what they want. Often words and/or phrases like "simple," "shouldn't be hard," and "this isn't rocket science" creep in to those descriptions. Unfortunately, these customers often give requirements like "needs to be easy to use." While this is truly a requirement, what's missing are the details like: what is "easy" in the context of this requirement, what metrics do we use to measure successfully meeting this requirement and, most importantly, who's the audience for this "easy" application? Don't get me wrong, a reasonable person could arrive at approximations of "easy" on their own, but as the project starts to get close to finishing up and folks are rushing to meet deadlines, both IT and the business tend to get pretty picky about requirements; (over generalization coming) business users want to continuously tweak the application and IT simply wants to establish that they've met a particular requirement and move on. So, be sure to document, review and validate requirements up front -- before the coding or development begins.
  


• Establish a good change control system
  Almost no one can argue that requirements are fixed once they've documented, reviewed and validated. Even in the best case scenario, requirements change -- the business climate changes, the audience changes, new insight emerges or the Earth starts spinning in the opposite direction. Ultimately, something always changes. However, the difference between a well-run project and one that will spin out of control, is how the collective team developing this solution manages changes. Consejo recommends having a well-established and formalized process for defining, submitting, validating and approving changes to an in-process project. Project teams must understand precisely what the new requirements is, how it fits with the existing requirements (e.g. what changes and what doesn't), the impact to the project effort and/or duration and, if applicable, the cost of the change (which is usually tied to increases or decreases in effort -- but not always). More often than not, a bad project is the result of an unending set of changes, mid-project, that no one (including the folks providing the requirements) keep track of well enough to be able to establish whether the new application meets the modified requirements. This situation usually results in a very heated back-and-forth discussion at the end of the project, where no one is happy with the final outcome.
  


• Set project scopes so that you can meet requirements quickly
  Very long projects tend to yield the most defects and the most dissatisfied end users. Especially in IT, where the underlying technology changes rapidly, long projects simply aren't practical. Consejo recommends that customers define project scopes that can be accomplished (start to finish) in three months or less. This may seem unreasonably short, but consider that projects that take six months or longer suffer greatly due to changes in business climate (e.g. external to the organization) and organization needs (e.g. internally driven requirements). Having personally worked for organizations that had a "13 week year," a three month project allows organizations to quickly realize benefit without being unreasonably sidetracked by either internal or external forces. In addition, having such a tight project delivery schedule forces both IT and the business to focus on the highest value requirements and/or features, pushing other features or requirements out until later phases. To illustrate this problem, consider projects that take six months or longer. Businesses typically make changes to any number of aspects of approach in the market -- be it advertising, new product launches or competitive advantages. Making the business wait for a six to twelve month project to complete, just so that business changes can be integrated into this new application is an unreasonable expectation (especially if IT doesn't want to get a flood of change requests). A three month time line is much easier to manage and provides more immediate opportunities to improve the application once the development cycle has been completed.
  


• Use the "metrics for success" to test the project outcome
  Testing anything seems to be counter to corporate culture. This statement may seem overly dramatic, but I've been involved in more than one project where the customer expected less than a week's worth of testing for a project that took three months to complete (I've also worked for firms that understood testing to be the period immediately after the application was completed and place into production -- when real customers were using the tool). Further, these same customers are the ones that tend to "tell you" the requirements, without documenting and validating them. If an organization truly wants to be successful, it takes the time to document requirements and indicates what success means in terms of satisfying a requirement. They then use this documentation to craft a testing strategy to ensure success. For example, if "easy" to the customer means that a user can get to or access a particular function within two clicks, then there should be a corresponding test scenario that allows a tester to validate the application has met this metric. If there isn't a formalized approach to testing, you end up with developer-test solutions and developers inherently know where not to go to break their own code.
  


• Find the right people, not the convenient people
  In today's market, it's tough to find qualified candidates, get them involved in your project and/or find a candidate willing to work for what you can afford. Most often, the best resources are busy, stretched to thin and/or asking too much. If anyone has recently tried to find a good SharePoint resource, you understand what I'm describing. However, finding the right resource to lead, manage or participate in your project is critical. When describing the "right" resources, I want to be clear: the right resource isn't necessarily the most technically savvy, but the best well-rounded individual. The right resource, beyond being technically qualified to participate in the project, should understand and adhere to good project management practices (even if they're not a project manager), they need to be a good team player (I've met many "smart" and technically superior resources who were terrible team players) and, most importantly, they need to be able to find the answer if they don't have it themselves. In short, they need to be flexible, resourceful and have good "people skills." Some companies make the mistake of reallocating resources who are underutilized to projects when their short of team members -- either out of convenience or ignorance. This was common in the mid-nineties, when administrative assistants were made into "web masters" because they were enthusiastic and the web was thought of as a "toy" (this was especially true when companies were starting to create intranets). These admins may have understood HTML, but they didn't understand what the impact was to the organization or how to make the intranet work for the organization. In addition, However, consider this: the better resources in the market can often find faster ways to get your project done -- even if their per unit cost is higher, the project will likely cost you the same. In addition, these resource also understand how to make this new application "real" for your organization by being able to interact with the business and, potentially, end-customers.

This list is certainly not exhaustive, but it covers the points that are often overlooked by organizations taking on IT projects. I hope it's useful to you and I would certainly appreciate any feedback you may have.