With a section header like this, it sounds too good to be true. However, if a project is not staffed correctly, implemented without a business strategy, or is misaligned with the business's strategy, problems will arise. This may sound obvious, but a .NET developer cannot start working immediately with the API without training or coaching and a .NET developer who may have technical knowledge, is not an administrator. This knowledge and insight can be key to a successful SharePoint deployment.
This is a very common mistake made by companies, including Microsoft Partners, attempting to build a SharePoint practice. This is covered in more detail in Chapter 6, How to get the .NET Developers on Board Quickly?, and Chapter 8, Managing your First SharePoint Project, of this book.
This book follows the Data, Information, Knowledge, and Wisdom (DIKW) hierarchy, where the authors have applied their wisdom to knowledge of the SharePoint technology and projects that they have participated to information and data. This is illustrated in the following figure:
The authors' SharePoint wisdom provides insight for the reader to increase their effectiveness with SharePoint decision making process.
A few years ago, one of the authors was consulting at a government department in New York and working with a newly hired CIO who asked his team to assist with their first SharePoint implementation. SharePoint had just been deployed and a few small applications were complete, and they wanted technical knowledge transfer to their .NET developer so that they could take ownership of the technology and the on-going maintenance. At this point in the deployment, there was no custom development.
He was the only resource they had and concerns over single developer/administrator fell on deaf ears. The developer, who had no administration skills with limited SharePoint knowledge became the department's technical point of contact and product evangelist.
Prior to training, we informed the developer that he needed to read a 500-page SQL server book on SQL server and a 100-page installation manual that we had written to help him (even though SharePoint had already been installed in their environment and the developer would probably not be using this skill in the near future). After the training the developer had a lot of knowledge of the backend SharePoint technology, but little practical implementation skills of the technology.
Three months after the engagement, the author was called in by the CIO and was asked to review a project that had been deployed in the SharePoint environment.
Well, you can imagine, the developer had developed a wonderful .NET solution for the SharePoint platform. However the forms, workflows, and security features that were in the application were all custom developed and could all have been deployed out of the box in SharePoint, in probably a fraction of the time and be more easily supported (if they had someone with basic end user SharePoint knowledge).
This is unfortunate for the developer, because he was a contractor and probably felt that he had to build a solution with his skill set or he would be replaced. But you have to admire his mind set, "Don't worry, I can do it."
Shortly after this meeting, the author did hear back from the developer as he was asking about how to make the content on SharePoint externally available to users, without a VPN connection. The author was asked about his IIS (Internet Information Services) skills. There was a long pause on the phone and the sound of a few keyboard strokes; presumably a Google search occurred. His response was, "Don't worry, I can do it."
The CIO is no longer with this organization. This may or may not be related to this SharePoint project. You can only speculate.
This experience is personally frustrating to witness because it impacted careers and undermines the reputation that SharePoint can add real business value to an organization. So if situations like this can be avoided, it is a winner for everyone.