Blogs

One of the things I am working hard to avoid is having any of our SharePoint solutions morph themselves into a bloated failure.  As people see the value in adding metadata to documents, reporting features to dashboard pages and workflows to business processes, the temptation exists to turn a Sport Utility Vehicle solution into a Dr. Seuss car. Our job as architects and designers often becomes one of talking people into also buying a sports car or a pick-up truck, but it can be a hard sell. The fact that SharePoint can do so many things makes it appear that any single solution can be made to accommodate 1,000 requirements.

As I write this entry, I am straddling a very fine line that I hope will separate two highly related projects. We have recently completed a project to help manage, track and store our engineering inspection reports. Now we are being asked to help automate a separate project that happens to use information in those reports as the basis of a different process. We could solve this easily, from a SharePoint practitioner point of view, by adding even more metadata to the report library and tweaking the workflows just a little bit more. The problem with that solution is that all these demands are cumulative. We can’t lose sight of the original goal, which was to simplify the reporting process. Fortunately, the users involved understand the key aspects of success.

Don’t Mess with Success – In our design discussion for the new process, the engineering director commented that “the reporting process is working pretty well” – that’s high praise from an engineer. It took a lot of work to get to this point, and we had to make numerous adjustments to fine tune things like Content Types, metadata, workflows and responsibilities. Simply put, we are beyond the point of changing the fundamental requirements of this working solution. On the other hand, we all equally deplore duplicating effort and / or creating duplicate copies of things that should be considered company records. We have decided that we can reference the reports, so that we only need one copy, but that the metadata associated with the reference can be kept and maintained in a separate list. One of the strengths of SharePoint is the way in which related lists and libraries can be brought together to solve a problem.

Do the Math – Engineers are good at math, so it wasn’t a surprise that they understood this key to success. Regardless of what SharePoint can be made to do, time and effort go into building, maintaining and using every solution. We recognized that a 100 hour effort that will potentially save 8 people 10 minutes a month equals a greater than 5-year payback. If you add a bit of maintenance and the fact that we might be adding a minute or two to another process, and the numbers become untenable. Of course the hard part of this equation is knowing that the solution would take 100 hours to build. We tend to simplify the effort required in our minds, but having completed several of these projects tells me that there is usually more effort than we are considering at first glance. Development, testing, training and documentation all have to be considered, and none of those are insignificant tasks.

We haven’t actually begun working on this project, but I am already happy with the way it is coming together. I am sure we will struggle to meet some of the requirements, but I don’t mind a struggle. I’m just glad we aren’t going to bolt a bunch of junk onto our successful project.