Blogs

When I attended the AIIM ECM Master class, I was amazed at the similarity between the ECM project plan and the typical systems development project plan. From Requirements to Pilot Testing and Implementation, the specific steps were different but the path seemed very familiar. Ironically, the final step in both plans is to conduct a Post Implementation Review.

In 30 years of systems development, I only actually saw one P.I.R. completed as specified in the SD Life Cycle; it was my first assignment in my second job – it was also 1979. P.I.R.s are a hard sell because the project is done and the team members have moved onto other things. The project may have already taken too long or cost too much and it is a rare occasion that sees someone advocating “opening that back up”. Many systems development shops, ours included, rely more on user feedback, bug notifications and the normal influx of change requests. I would argue that in a small shop like ours, this works pretty well. On the other hand, for ECM projects, I am advocating a full P.I.R.

The difference between a systems development project and an ECM project lies in the comfort level of the users and the subjective quality of the goals. By now, everybody in our organization is pretty good at knowing what a computer program, even a fairly complex one, can do. Requirements are generally clear and we build our systems with standard components around a stable architecture. ECM is different; ECM is new and most people don’t know what to expect, and we are still in that mode where people are seeing complex ECM solutions for the first time. Our most recent project, for example, is a workflow driven solution for our engineering inspection reports. Our engineers are going from dumping Word documents into a shared-folder to launching a multi-step process in SharePoint. We have planned, built, demonstrated, revised, rebuilt, redeployed and we are getting ready to retrain, but I’m not sure we have this nailed down yet.

The unknown in this equation is user expectations. Actually, it’s not so much an unknown as it is a missing element – they don’t know what to expect. My expectations are clear; once they start using this “system”, they are going to see things they don’t like, they are going to see other things they wish acted differently and they are going to want things we didn’t think of. That’s fine. The problem would be if we started addressing those issues one-by-one as they emerge. Some of the questions, suggestions and complaints will be valid, but some will be the result of the unfamiliar nature of a new solution. That’s why I am telling the users during training that we are going to run with what we have for about 3 – 4 months before making changes. We will collect feedback during that period (we will fix any errors that show up) and, at the end of that period, we will review the project in terms of its objectives, user satisfaction and new goals. The P.I.R. I conducted over 30 years ago led to a significant new feature being added to the system in question. It won’t surprise me if we have similar results this time around.