When I was managing projects as a consultant, life was great. Our work plan defined our role, and, when we got to the end of that plan, we were on a plane or on the highway home. Our workpapers were bundled and archived and the client… well, they were no longer my concern.
These days, projects don’t really end for me. They cycle, as I described last week, from “under construction” to “in use” to “planning for maintenance” and the types and amounts of information change as that transition occurs. Also, the requirements for archiving information are different during each phase, and these requirements have changed over time. As we did last week, let’s look at a few examples of the kinds of activity this project includes, the information management required and how SharePoint helps us meet those requirements.
Development Now & Development Later – System development is like the weather; there are intense periods of activity followed by what we would call “normal” a.k.a maintenance, as well as periodic dry spells. The only difference is developers enjoy storms and dry spells and despise normal. The often overlooked requirement, is the cycle-to-cycle communication. Maybe we put a band-aid on something today that needs surgery in the future. Or, maybe we added data or transactions today that should be reflected in screen or report changes down the line. But did we pass this information to our future self?
I know our track record of documenting these things has been poor because I found evidence of these types of changes but little in the way of documentation. The next developer will be luckier; I am leaving a trail and not just a pile of notes. The Custom Lists I created during development include references to changes that may/will/should impact future development. Requirements generated along the way have been documented in two ways. First, each completed task has a HTML text field called “Remaining Activity” – I love that this can include links and pictures so I can include a screen-shot if it’s helpful. Second, if the requirement is more complicated than tidying up some code, I can add it to a list of “Development Tasks” and create a new list item in the outstanding requirements list.
What We Keep For Auditors – The other people who want to know about our development efforts are our financial auditors. Mostly, they want to know that there were controls in place around the development process and that adequate testing was performed. They may ask this question this year, regarding this specific system, or they may ask two years from now regarding systems development in general. We’re keeping our design, our models, our test data, our test results and our database change log for them to review.
What we keep for documentation – Some of our experience in development will impact the users of this system. Rather than leave them to figure that out, we are collecting information as we go that needs to get woven into their documentation. For example: we sometimes build in support for transactions that rarely occur. Our test data is probably the best example to use in documenting these transactions, so having the ability to link the feature to the document and to the test data is very helpful. What we keep for this purpose also helps us with training.
As I have suggested before, the ability to contain all this information in proximity to the task at hand is a huge benefit. The flexibility to have lists reference each other is also critical as is the ability to include richly formatted content in the lists and attach documents to list items. “Project Management” may benefit from project management software but “managing projects” requires managing information. SharePoint has made that task easy for me!