A few days ago, we held one of the most important meetings you can have during a project’s life-cycle, a Post Implementation Review. I have written several blog entries about the “system” we put in place to support the development, storage and distribution of our engineering inspection reports; now it was our turn to see if we got it right. We knew from our daily experience that we were close, but closing the gap between “close” and “right” requires reflection. I will probably share some of the specific results in future posts, after we address the issues, but for today I want to focus on the generic SharePoint lessons that we learned during this review.
Exposing the Details – One of the issues that we talked about was a “problem” one user noticed fairly recently. He had to reissue a report, so he simply changed the status to an earlier state in the process. He was disappointed to find that the status change didn’t result in an email to the person responsible for performing the format review of his revised report. We explained that the process was linear and designed to be one-way (we didn’t know that they sometimes reissue reports). We built in features to prevent notifying the same person more than once for the same task, and this feature was preventing the action that he expected to see. His expectation was valid, but now the reason it wasn’t being met was also clear. Rather than trying to tweak the workflow, we decided to add new discrete status indicators for reports that are reissued. Revealing a little more of the gory details in this case helped to explain that the “problem” was actually a “feature.” In addition to satisfying my desire to point that out (I’m an IT guy; I love it when problems are features!), giving the users a better understanding helped us to collectively extend our solution to meet an additional requirement.
Forgotten Features – Even though we had been using SharePoint in our company for over five years when we deployed this system, some of the users were not familiar with SharePoint at the time. During training, we focused on “process” first – how this system should be used to automate and support the inspection report cycle. We talked about specific SharePoint features, but we spent most of our time on the exciting new features we were using for the first time: managed metadata and document sets. Those two features were critical to the success of this project, so we spent a good deal of time making sure everyone understood how we were using them. During our meeting, the discussion revealed how one of the users was storing multiple drafts of his report locally, until he was “ready to put it in SharePoint.” Yikes! We forgot to explain the fact that this library was version controlled and what that meant to the people writing and reviewing these reports. Actually, we had mentioned versioning early on, but our treatment of the topic was from a different perspective. We talked about how, when a report is finalized, we remove all previous versions so that v1.0 will serve as the baseline in case someone inadvertently changes a report in the future. We made the assumption that everyone understood the benefit of versioning, and well you know what happens when you assume.
Degree of Difficulty – One of the hardest things developers have to communicate to users is how hard, or how easy it is to build something into a system. This system relies on Content Types as well as status to control the workflow-driven process. We noticed during the discussion that there seemed to be a reluctance to ask us to create additional content types. We wanted to dispel the notion that content types are hard to create, but we also wanted to make sure people understood both why we use them and how they can use them. As I once said in my AIIM Blog, “the answer is always yes” – Of course you can have additional content types. We pointed out; however, that they should create templates for those content types and they should define them in terms of the process. Are these new documents that should be managed during the process, or are we just looking for an easy way to create new documents in the library?
The most important thing to understand about a PIR, is that it is part of the development process. You must avoid simply adding features to stop people from complaining; the system still has a finite set of requirements. If requirements were missed, now is the time to include them. If people want to start muddying the water by mixing in features unrelated to any requirements, you have to encourage them to define a new system.