@Wonderlaura, Here’s How I Do Business

Laura Rogers (@wonderlaura on Twitter) responded to a comment I made the other day. Normally, I don’t name commenters, but because I’m sick and tired of being ‘polite’ and seeing clients and the community suffer from it, I’m going to be a bit more straight forward. If you don’t like it, you can kiss my abs.

The comment Laura made exemplifies a huge problem that the community has and that SharePoint has, in its understanding of the capabilities of the platform. She said:

“@furuknap Maybe you just like your customers to be completely dependent on you once you’re done, so you write all custom code for everything” (ref)

Wonderlaura quote

The comment to which she responded was that I said that often, consultants and developers waste months of client time because there is an attitude among some high profile people in the SharePoint community that ‘custom code’, or, probably more accurately, anything built in Visual Studio, is bad, bad, bad, and should be used only as a very last resort, and only after considering kicking small puppies and shutting down the entire company.

I’ll talk in much more detail about this problematic attitude and why those high-profile people, who don’t know how to code (and I think it’s interesting that @wonderlaura considered herself to be a target for that comment), should probably sit down and learn some basic solution development. I’ll do that in a later article, or probably several articles, but not now.

Now, I would like to respond to @wonderlaura’s comment and explain how I approach and work with clients. Making such accusations against me in public is extremely low, especially when coming from an MVP, but frankly, I’ve stopped being surprised at what comes flying from that direction. </rant>

And yes, I resort to third tier development, the dreaded Visual Studio approach, most of the time.

Client Selection

I never name my clients, because that’s none of your business, but also because I can talk about ‘a client’ without revealing anything about who that client is. I always send the client a one-sided NDA that effectively shuts me up about anything related to that client, so anonymity for those is mandatory.

When contacted by a client, I review the client. I don’t care about their problem or their suggested solution at this point, I need to know what the resources of the client are. Questions I ask are:

  • Do they understand SharePoint, or simply use it to screw their clients for money (all will say yes, but many are lying even then)
  • Do they have the resources in terms of (wo)manpower?
  • Are they willing to learn and advance or just perform and invoice?

I have a massive luxury in that I can choose for whom I want to work. I can easily say no to clients who do not take SharePoint seriously, because there are enough companies that do, and that need my assistance.

Client Resources

After accepting a new client, I start by interviewing their current developers or key personnel. This allows me to understand how they can solve the problem they have. No, I’m not referring to how I should solve their problem, I’m talking about what means are within their own reach, using their existing developers, to solve their own problems.

You see, to me, it’s not about what I know, it is about what my clients are capable of doing. I’m not sitting down with an HTML designer and teach them disassembly of the SharePoint assemblies, nor do I expect a programmer to fully understand the intricacies of organizational behavior. I pick the way of solving a client’s problems based on what the client (or their consultants) can do after I leave.

In 9 out of 10 cases, when asked, knowledge increase is on the request list of clients. They want their people to understand more after I’m done than they did before. As such, after fully understanding the current level of their people and the problem they are trying to solve, I sit down and create a plan to reach a ‘solved’ state for their problem, but more importantly, the resources, knowledge, and experience that the client developers need to be able to build their solution further.

Luckily, I’ve written more SharePoint books and journals than anyone in the world, so there’s a huge chance that I’ve already written something that I can give to the developers or to the client to help them understand. You can’t imagine the look on managers’ faces when I can give them a journal issue explaining, in language non-techies understand, what their developers are doing. However, the developers also greatly appreciate getting books and videos that explain the methods so they have something to which they can refer later too.

When breaking down the plan, I divide and assign the tasks so that the developers get a challenge that will take them in the direction they need to go. For a beginning third tier developer, for example, this may be to let them create features that are outside what they have previously done. For a first tier developer, it may be to ask them to build parts of the solution using SharePoint Designer.

Continuous Learning

During the actual work, I also incorporate regular (several times per week) briefings with the developers. These briefings serve both to help them if they are stuck in their assigned tasks, but also to explain, in detail, what I do in the project and the underlying technology of the platform. For a recent client whose developers needed to better understand how web parts worked, I explained to them the ASP.NET engine so that they instinctively knew what happened when SharePoint saw a web part definition. It was one of those “A-Ha!” moments for them, because up until that time, they had thought that web parts where the things they stuck in the web part gallery.

I don’t expect all of that to sit after just a few hours, so many times, I also record these sessions so the client can review the ‘lectures’ afterwards. This often goes into the client’s learning libraries, to be used with new employees too.

Finally, in every project, I also set aside a minimum of 20% of the time to do thorough walkthroughs of the entire solution with all the developers and lastly, to write proper documentation, both inline code and deployment and other documentation.

So, all my clients get:

  • Training and resources tailored to their current level and desired goal
  • Detailed mentoring while they are themselves solving their problems
  • Full walkthrough and detailed documentation of the solution

The result of this is that when I walk out the door, the client and their developers and key people know both how to solve their problems and how those problems arose. They end up having built their own solutions so they know that inside out. They have attained the skills required to support and maintain their solution in the long term and also to solve similar problems.

Does it Work?

I would like to say that so far, no client has come back to me to solve a similar problem to one I’ve already helped them solve. Many have come back with new types of problems, probably because they see that what I do isn’t to solve their problems, I make them capable of solving their own problems.

So, Wonderlaura, my clients depend nothing on me after I’m done. In fact, if they call me to ask about anything related to that solution, or even similar solutions, after I am done, I see that as a failure on my part, and obviously help them free of charge. I think that has happened once or twice, and I’ve always thoroughly examined my methods afterwards to figure out what I can do to improve.

But, I also end up writing ‘custom code’ in 95% of the cases. Recently, I solved a client’s Publishing framework problem, a problem they (and Microsoft support) had struggled with solving for two months. I solved the problem using ‘custom code’, including all the training, planning, documentation, and knowledge transmission, within a week. Incidentally, these developers did not know how to do any .NET development.

In a previous client case (about two years ago) I ended up creating (and teaching) a new framework for deploying and maintaining sites and site collections, including custom WSP solutions, within three days. This framework eventually made it into USP Journal issue 1/8, and the client for which I worked ended up completely restructuring their entire project so far (a six-month project) in another week, after I had taught them how the framework worked.

So, yes, I would say it works.

I have no idea how @wonderlaura approaches her clients, and how much time she spends teaching her clients everything she does, leaving documentation, videos, and detailed explanations, and empowering the client to help themselves rather than just solving the problem for the client, but this is how I do it.

I leave no client dependent, and I will not have some random MVP run around claiming otherwise.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

One thought on “@Wonderlaura, Here’s How I Do Business”

Leave a Reply

Your email address will not be published.