It was an exceptionally cold winter. I was 7 years old, bundled up in long underwear, a snowmobile suit, a long scratchy scarf tied around my head (literally tied on), hand-me-down snowmobile boots that were slightly too big for me so they were stuffed with towels, and I was wearing two sets of mittens. Two sets of mittens? Well, my mittens were worn out for the most part and given that my brother had chicken pox and was out of school (the lucky guy), my mother put my mittens on and then took my brother’s and fit them on top. And off to school I walked with my sister like two miniature, very slow, Claymation snowmen trudging along to their daily learning. We grumbled and groaned to no avail (because our parents walked backwards through the snow barefoot you know) and it was okay because we were indeed warm and protected from the elements.
Now naturally, since my scarf had to be tied on to my head, you can imagine what happened to one of my “borrowed” mittens. As a 7 -year old child, who at the time did not know what it meant to be an ENFP (Myers-Briggs personality type) you can imagine my dismay, cries of woe and wailing when I realized the mitten was gone (my F was out of control). I was sure I had it when I got to school. What could have happened? After calming me down (no easy feat), the teacher took me to the lost and found over lunch. The lost and found? What was this strange and mysterious place? It was a cornucopia of lost treasures, a place where all fears could be allayed and all would be right in the world again! Okay, it was a very large cardboard box full of mittens, scarfs, and boots and there on the top was mine. I was saved! From the wrath of my brother getting over chicken pox. All I could think about was all of those “other” treasures and why had people not come by the lost and found to claim them? Today I do business analysis and sometimes I go to the lost and found to see what I can see and claim what I can claim.
Have you strolled through the cornucopia of your requirements lost and found? I am talking about reuse of requirements. Reuse of requirements can be a difficult thing if your company does not have an appropriate repository, tool, or a very structured system for maintaining old documentation but it is possible. Most of us have a Local Area Network where they are stored, in some strange folder under an obtuse name, or on a SharePoint site that is likely more organized than the LAN but can be equally as frustrating. Now whereas the taking from the school’s lost and found is inappropriate (beyond what is yours), taking from your company’s requirements repository is not. We just generally don’t think to do it. Here are two reasons why you should.
1. Don’t reinvent the wheel.
A lot of Business Analysts work on smaller projects or what we would call enhancements. Enhancements mean that the requirements have been done before and they are stored somewhere, so find them and use them. Any project that has been done before has a lot of good documentation that has been done. Okay, even if you find that by your standards it is bad documentation, it is still something to work with and can yield great results. Someone will know where that documentation is stored or have a good idea of the general area, and when you find it, pilfer it for all it is worth! Now don’t alter the original document or move it (compliance will be very unhappy) but certainly copy it and use it to your heart’s content and shave some time off of that project. It is generally easier to react to a document and tweak it then it is to come up with something from scratch. Additionally, this will make your elicitation easier too because you can use already documented models as a jumping point for the enhancement. If you are a Business Analyst that will be working on a given application for a while, I highly suggest you start keeping a spreadsheet of where all of the requirements documentation is kept as you uncover it. Reuse is going to be your friend. You should see an increase in your productivity as you get used to the idea of reuse.
2. You never know what you are going to find.
There is a ton of information out there on your LAN or SharePoint, and many of these projects are considered “dead” projects. They got started, folder structures created, lots of work and documentation was done, and then they were cancelled and abandoned like lost mittens. Perhaps they were started, then stopped, then started again with new scope and all of the documentation was recreated under a new folder structure creating a mismatched mitten. Whatever the reason they are waiting for someone to reuse them! Why would we reuse “dead” project documentation? Because there will have been work that has been done on the current state. Current state documentation is a very hard thing to come by for most organizations. If fact many BAs have to go create the current state as one of the first things they do when starting a project. Without a solid understanding of the current state we cannot assess our capability gaps effectively. And if I can verify that some of this “dead” project current state documentation is accurate, I have once again gained valuable time on my project. Another reason to look at “dead” project documentation is that it will drive future ideas and prevent us from making the same old mistakes.
What other ways can reuse of requirements help you? Give it some thought, you might be surprised by the potential it can provide. I think once you get a handle on reuse of your requirements it will help you and your company work more efficiently, faster, and with less potential defects over time. Find those lost requirements mittens so you will be warm and protected from the workplace elements.