Access Denied when trying to Schedule a Crawl in SharePoint

While I'm not a huge fan of simply re-posting content originating on other individual's blog, this particular re-post is warranted, if for no other reason that it was a bear to find the solution. My hope is that more references to the posting will increase the likelyhood that someone else will spend less time finding the answer in the future.

Now, effectively the problem I encountered was an "Access is Denied" message when trying to schedule a search crawl in Office SharePoint Server 2007 (RTM). While, I could manually start a crawl and it would successfully complete, I was not able to create a schedule for either an incremental or a full crawl. Apparently, the trouble was missing permissions on the Tasks folder in the Windows directory; the "WSS_WPG" group (created by SharePoint during installation) needed read and write access to the folder.

It totally makes sense that SharePoint would leverage scheduled tasks to kick off scheduled crawls, but I would have hoped that the installation process set this for you. In my case, the server I dedicated to the index function was a "recycle" and was never reloaded with the OS -- the prior implementation of SharePoint was uninstalled and I re-installed the new implementation over top. In hindsight, this may not have been such a good idea, but we live and learn.

Here's the article that saved me the trouble of rebuilding my machines (yes I was that frustrated): http://www.folin.se/index.php/category/microsoft-office-sharepoint-server-2007/

Many thanks to Michael Folin for posting such a great tip!

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.