Although last week’s rant ranked as the most popular installment in this blog’s short life, I’m going to return to SharePoint today. I am currently retrofitting one of our transaction processing systems with new processing capabilities, modified reports and a better control structure. In the past, the road to completion would be littered with notes that would be tossed aside when the system went into production. This time, the entire process is being documented in SharePoint. While this started out as an attempt to create an audit trail, I have been amazed at how truly useful this practice has been during development.
I’m going to spend a few weeks exploring this subject in detail, but let me set the stage today. This project started in a SharePoint site based on our Document Workshop template. We added a wiki to facilitate the design of several new screens and screen modifications. The wiki was well received by the system users and helped us quickly define several screens. Of course, as we developed our design documentation and test data, these were stored in document libraries. We also used several custom lists to help build a series of models for this system. The models were used to test scenarios for new ways to process transactions. Easier to modify than the system itself, the models let us zero in on the correct path for new algorithms. The completed models were moved to a controlled document library where tests were conducted and version comments recorded the results.
When we moved into coding, I thought that SharePoint had run its course as a support tool. Then I started noticing the stuff piling up on my desk again. First, there was a series of notes describing changes we made to the tables in our test database. At some point, we have to make those same changes in production. Some of those table modifications are associated with new system capabilities which need to be tested and documented. Some of the table modifications are associated with new controls, which also have to be tested and documented.
The next stage of development was the cycle of implementing the new features, establishing controls, testing and correcting errors. In this particular system, there are 19 transaction types which all need some of the same changes. We scratched out a form to track the progress as we moved from class-to-class. As soon as I created the paper form, I thought “this is stupid, this should be in SharePoint” – I was right and that’s where this information is today.
It’s hard to believe that a SharePoint advocate like me can still miss an opportunity to let SharePoint help with a complex project. As with the Document Workshop, having design documents, algorithm models, test data and a place to store test results all in close proximity has proven to be a huge advantage.
Next week, I’ll explore some of the techniques in detail and I’ll explain why I think SharePoint is the best platform for managing complex projects.