If your company has a full-fledged software development process along with pre-defined templates for creating deliverables at every stage of the process, do you find that the templates encourage good thinking or a fill-in-the-blanks strategy?
In my last three projects, I feel I’ve been lucky to work on teams where there is little formal process or they are facing a big change in process. In this situation, I’ve been able to create requirements specifications that work specifically for the needs of that project. The risk in doing this is that I miss something important because I am not relying on an old stand-by. The upside is that everything I put into a document adds value.
The deliverables for these projects were shorter than documents I’ve done in the past and more to the point.
If you are working within a larger organization or within a formal process, you may or may not have this flexibility. In fact, I can recall some early days I spent as a business analyst or even as a QA-witness to requirements reviews meetings in a company that had recently implemented a new software development process. Everyone was still getting used to the new way of doing things (which, admittedly, was much better than the haphazard old way of building software).
We had meetings where we said things like “well, there is a section in this document about [insert favorite functional specification section here], what do you suppose we should put in that section?” And then someone would come up with an idea which usually involved copying something from another part of the document into the new section just so the document would be “done”.
On the flip side, on occasion a template section prompted interesting discussion. It encouraged the team building the software requirements to think through various aspects of the solution. Some good thinking was generated because of the template sections. But we also wasted a lot of paper and time filling in the blanks.
I’d be interested to hear about your experiences. Do you have explicit permission from your management or process owner to cut template sections? Do you need to justify not including a section? Do you feel it necessary to fill every section in, thereby making your documents unnecessarily bulky and more difficult to consume?
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 11 comments… read them below or add one }
The organization I work for is CMMi based and we have a full Process Asset Library that includes templates, guidelines and the like. The methodology was rolled out something like 3 years ago and the backlash has been occurring ever since. Why? Two reasons, it’s very time consuming and it’s perceived to be inflexible.
Those that know it a bit more intimately, like me as a result of being an analyst, know that from the beginning it was offered as a framework that allowed the practitioner to modify the template to the needs of the project. There are required sections in each asset that must be in place to pass an audit, but there are other sections that can be labeled as not-applicable if needed. We are not allowed to actually remove the unneeded sections, because the auditors want to know that we actually took the time to consider each portion of the document.
We also have another level of flexibility, though it is governed by process. Based on the project size and complexity, we have a rigor process that is used to cull unnecessary creation of documents that don’t apply. The higher the rigor, the more documentation work is required.
I won’t even go into the time consumption aspect of all this.
Thanks Laura
Thanks Doug. That’s an interesting perspective. I often think we get into a perception we can’t change a template when in reality we can (and it sounds like your organization is in this situation).
You add another layer here in terms of determining what the required documentation is given the type of project. It seems useful to be able to swap in and out deliverables. I know in an organization I worked in not too long ago each project was so different it was a challenge to come up with a unified process at all. We started down the path of “possible deliverables” with guidelines for what should be used when in our process development. Of course, you make a good point that the very process that’s meant to introduce flexibility can itself become a burden.
Hello.
Every project is specific and requires different points of view. I don’t have so strong rules that dictate topics in requirements specification. Organizational template was created a year ago and was used only for the first projects. Now when new project starts I take my better specification where the specific is closest, delete the part of content and use this as a template and example.
But in my case I don’t have QA “gate”. By the way what is the main task for QA checking specification? Content, traceability, structure, what else? And when it should be done – before the first version goes to customer or before signing? Does it have a real value?
The QA Audit is important to ensuring all of what you mentioned, but it also serves as a check point to ensure people are performing their tasks in general and within the realm of the methodology and organizational mandates. For instance, I work in health care, which is highly regulated. In an org that is young in methodology, this step is critical to ensure the firm is compliant with legal obligations. As personnel mature through the process, the focus shifts to specific tasks, like those you mentioned.
Hi Laura,
I am in process of finalizing a new requirements template for my organization (which is highly regulated).
I have seen one at Modern Analyst website which seems quiet generic.
Appreciate any suggestions.
Hi Kashif, You raise a good point. Templates, almost by definition, are generic. I’ve found that the most valuable “how to” documentation on BA teams I’ve worked on are in guidelines or questionnaires that help you use the template in specific situations. This is where you can dig into the key learnings for the types of projects your organization does most often and keep a repository of good questions, best practices, or gothcas that help guide the requirements process.
It’s on my long list of “to dos” to develop some questionnaires for the kinds of projects I’ve done a lot of, thereby helping BAs be more successful in a type of project that is new to them.
This seems like a good time to offer up this link to the Goddard Space Center’s Process Asset Library. This site has tons of public-domain template and process info. I often rely on it when trying to NOT start from scratch.
http://software.gsfc.nasa.gov/process.cfm
Good post! Personally, I like having a template to help standardize what an organization needs and/or wants in a document or set of documents. The challenge comes in when people do not understand that the template is a guide to help analyze and think through problems. There are environments where the only importance to the project team is *closing* the document on time! Sometimes I think the template distracts from the overall goal of the project team, which might be to analyze a problem, discuss and recommend appropriate solutions. On the other hand, I think that not having a template may be more dangerous than having it!
Thank you guys. Your suggestions are much appreciated.
Laura i fully agree with you that a document should be generic which BAs later on can tailor as per Project requirements. I have viewed different sample documents some of them which i myself have used in the past. And by taking important Artefacts from different docments i am making a generic document.
I am currently trying to finalize if AS IS/To BE should be a part of the Requirements document or it should only remain into Feasibility study.
BEst,
K.
I feel template driven software just doesn’t cut it. In the several firms that I worked at as a consultant, they didn’t have any formal software. Instead they were proprietary documents meant as a guideline. It allowed you as a consultant to use more of your experience to add to the guideline. A template is fine but is limited to only the people that know how to use it.
Tony,
I think you make a great point that a template only gets you so far. Knowing how to use the template is much more important. I find a few examples along with some context in terms of a “how to” is much more helpful than just a template.
Laura