As we could see in the last post, there are real advantages to using client centric design, as its priority is understanding and supporting a business process as opposed to focussing on technical requirements.
So why isn’t this approach adopted by all solution providers? Why do we still see technology centric design, and the resulting systems, being used in production level SharePoint Installations?
Let’s look at the barriers, their validity, and how to challenge them.
Barriers to Client Centric Design – Technical Expertise
This is a completely valid reason for not being able to create a system using client centric design. A strong technical team enables good design.
Barriers to Client Centric Design – Design Expertise
Without a good design team, you won’t see the benefits good design can provide.
Barriers to Client Centric Design – Undervaluing Design
If you have two systems side by side, both are technically robust and meet all requirements, one has client focussed design, and one based design decisions on mostly technical considerations, which one do you think the client is going to choose?
Good Client Centric Design. Every time.
Barrier’s to Client Centric Design – Cost
A SharePoint solution designed and developed using client centric design is definitely not the cheapest option. Except in the case of systems that use the built in pre-configured front end tools, such as team sites or the issue tracking list, custom solution support development in SharePoint is not going to be the cheapest option.
The first question therefore for someone who is focussed on cost is “Why are you using SharePoint?” If cost is the sole and highest priority factor, then any system with intermediate or higher complexity could probably be developed cheaper using a focussed platform isolated solution approach, such as .net or java development. SharePoint strength is in its ability to provide a wide variety of tools and supporting information to encapsulate much more of a business process.
SharePoint isn’t the cheapest application development platform, particularly once systems become intermediate or higher complexity. It is the best choice however due to the variety of tools and degree of support it can give a business process, it is the best choice because it can best support the majority of the business process, not provide the cheapest support of core components of that same business process.
But, in the long run, SharePoint can also save money.
And that leads to the second point. Even though initial development of more complex systems in SharePoint using the client centric approach costs more, the efficiencies the resulting system give savings over time.
Let’s take a more detailed look at that argument using the vacation request system. The following table shows all of the activities associated with a vacation request system covered in the last post, who is responsible for them, and how much time they take. The technological centric approach and the resulting time effort are contrasted with the client centric approach and end user effort. The first table covers the technology centric system:
We can see from that table that completing all tasks associated with the average vacation request takes 55 minutes, 20 minutes for the requestor, 15 for the manager, and 20 for human resources. Now let’s look at the same table, but this time for the client centric system:
As we can see, having all of the information necessary to process the vacation request residing in SharePoint increases efficiency considerably, moving from a total processing time of 55 minutes to a total processing time of 30 minutes.
If you have a company with 400 employees, you could expect an average of 800 vacation requests per year. In this environment, you are saving 25 minutes for each and every vacation request. For a total of over 2 months of savings in one year!
Properly designing SharePoint Solutions results in real and measurable improvement in efficiency. Because, long term, a system developed using a client centric model ends up costing less as less time is used to support the business process.
The cost barrier to client centric design can therefore be challenged by:
1. Finding out what the goals for the development of a SharePoint system are. If cost is the top priority, except in the case of simple systems, then perhaps SharePoint isn’t the best choice. If the ability to effectively support the majority of a business process with a diverse range of interconnected tools is more important, if the effectiveness of the system is more important than the cost, then SharePoint definitely is.
2. Proving that the amount of time necessary to complete the same business process using a client centric approach will be less. Demonstrating that the solutions provided using this focus will result in long term savings to the users of the system.
In the end, a carefully considered and designed system, using the client centric focus, results in a system with higher client satisfaction because it more effectively supports the process than one designed with a more technical focus.