Be Master of Your Domain: Create a Business Requirements Template

There are many different elements that can go into a business requirements template, and I’ve found the terminology varies widely for how the different elements are labeled and described. It’s a shame there isn’t a greater consistency out there in what goes into a business requirements template, and unfortunately the Business Analysis Body of Knowledge (BABOK) doesn’t attempt to provide guidance in those regards. It simply states, among other things, that requirements must be documented, but it doesn’t say how to document them. I don’t think anyone would disagree with the need for documenting requirements, but it’s the documented requirements that are the most critical piece of all! It’s basically the contract between you and your client. So why, oh why, wouldn’t the BABOK include some guidance in creating a business requirements template? I scratch my head.

On the bright side, it gives me a reason to create a post on this topic. I will share my business requirements template with you, but first, allow me to share with you a little history on how it came into existence. I created it about 1.5 years ago based on what I know from experience needs to go into a business requirements document, and also what my organization expected to see in a requirements document. I went through documentation that predecessors had created, then I went to talk to people who had read and used that documentation, and I asked them what they liked and didn’t like about it. I also spoke to my manager to get her take on what was lacking in the business requirements documentation, and what her vision was on where business analysis was going for our organization. I learned so much about my organization’s stance on business analysis by doing this, and I can’t recommend doing this enough if you are considering creating a business requirements template for your organization.

Another important point to raise about the business requirements template I’ve created is that I do a peer review of it about every six months with fellow business analysts who have been using it. We talk about what we like and what we don’t like about it, what could be improved, what can be removed, and any new sections that we would like to add. The reason I do this peer review every six months is because I feel a template should not be a static document. That’s not to say it should be changed frequently, whenever the mood strikes you. If you do that, then you defeat the purpose of having a template in the first place, which is consistency in business requirements documentation. Rather, reviewing the template on an intermittent basis, about every six months or so, and carefully considering the various elements of the document is essential to ensure that the template continues to meet the needs of your organization, as the business of your organization continues to evolve.

In regards to the business requirements template that I created, there are a few things to keep in mind:

• I work in the IT industry, so the requirements documentation is tailored for an IT project. A requirements document for, say, the construction industry may be quite different.
• My organization supports enterprise business applications, so any projects that we undertake almost always require reports of some kind, hence the section called General Reporting Requirements.
• There are no sections for data modeling. This is because in my organization, we do not consider this be the role of the Business Analyst. We have Technical Architects who perform data modeling.
• This is not a technical specifications document. It contains sections for stating the business requirements, and in practice, I may include some high-level mock-ups of functionality in the appendix, if needed, but that’s as technical as it gets in my documentation. This is because in my organization, Technical Architects create their own technical/design specifications based on their assessment of the business requirements documentation.
• In the sign-off section at the end, you will see I list a space for the Project Sponsor or Functional Lead (SME) and the Technical Lead. Here I have a confession to make: so far, I haven’t been able to get documentation formally signed off (meaning ink to paper) by either of these parties. We don’t have a rigid sign-off process established in my organization. The most I’ve gotten so far is a verbal agreement or an email confirmation. My vision is to one day reach a comfort level where both parties can sign off the requirements documentation without hesitation. Long story short, we’re not there yet, and perhaps we’ll never be. I’ve got a long post brewing in my head on this topic. Once I figure out my stance on this subject, it will appear.
• I use italics throughout my template to provide instructions on how each section should be used. These comments should be removed in the final document.

Now that my preamble is out of the way, here is the link to my template, followed by a summary of it’s key elements:

Business Requirements Template

The following list identifies what I feel are the key elements of any business requirements template for an IT project:

• The project overview, including a list of project stakeholders/contributors, in-scope deliverables, and out-of-scope items. Including some of the project documentation in the business requirements is important to keep the requirements focused on the goals of the project. 
• Common acronyms, names, and their descriptions. Acronyms have a way of multiplying like bunnies. Sure, they’re great for reducing how much you have to type or talk, but they can be a nightmare for anyone new to the project or organization.
• The existing process(es). In Lean methodology, this is referred to as the Current State. Please don’t underestimate the importance of documenting the existing process, or let your client talk you out of documenting it because they don’t see the need for explaining what they used to do. Understanding the existing process, and the problems associated with it, has implications on the priority of the requirements, the analysis of the requirements, and the solutions that are proposed. Don’t overlook it!
• The detailed requirements. This is where you dig into the minute details of your requirements. In my requirements documentation, I always use the items listed in the In-Scope Deliverables section as the parent requirements in this section, and they are prefixed with PREQ-X.X. This creates the necessary tracing to identify where each requirement is coming from, as you don’t want to stray beyond the scope of the project. Child requirements are prefixed with CREQ-X.X. Be sure to state each individual requirement separately, ID’d accordingly, and don’t bundle them into long, wordy paragraphs.
• The business rules. Any rules affecting how a piece of functionality works need to be listed in the business rules section. The business rules specify the limits for expected behaviour.

There are many other elements that you could add to your requirements documentation, and you will have to make the judgement call on those other elements based on your analysis of your own organization. I would suggest you Google “business requirements template”, find a few other templates that you like, and pick out elements you think would be appropriate for your organization. It might take some trial and error, but this shouldn’t deter you. Ask your clients for feedback once you’ve started using a new template, and adjust the template as necessary.

I welcome thoughts from my readers on what other elements you feel are critical to a business requirements template. Please leave any such comments or questions below and I will respond.

5 Tips for Getting Started on a New Project

You’ve just been assigned as Business Analyst on a new project: the one you’ve been waiting for. This is the kind of project you can really hang your hat on. Great! So where do you get started? Unfortunately, you may not have the luxury of someone to guide you through the mountain of project documentation, but you need to hit the ground running. Here are my tips to get you off on the right foot:

Tip #1: The Project Charter is your Bible

The Project Charter is your Bible

Find it fast and commit it to memory, from a to z. You can’t count on your project manager to reign in the stakeholders if they start asking for things that are out of scope. That doesn’t mean that you should refuse any requirements that you consider to be out of scope. That’s not your job. But a good knowledge of the scope based on what you’ve understood from the project charter will allow you to flag requirements that may be out of scope to your project manager, and then you can let your project manager make the call as to whether or not they should be included in the requirements documentation.

Tip #2: Know thy resources

Know Thy Resources

Nothing is more important than knowing who your experts are, and developing a rapport with them. This may be the SME(s), the technical expert, the person sitting in the corner who’s been using the current system for the past 15 years that nobody asks their opinion, etc. You need to find out who these people are, and to do that, just start asking around. The official name for this is stakeholder analysis, and you can get as formal or informal as you like with it. Oh, and if someone tells you something to the effect of “I know what all the users want; you don’t need to speak to them.” Don’t believe them, m’kay?

Tip #3: Examine the characteristics of the project, and think about how they might affect your work

Examine project characteristics

You may want to seek a different approach to your requirements gathering process and/or how you plan to get approval of the requirements, depending on some of the following characteristics:

• Are there external factors imposing a hard constraint on when the project is delivered?
• For reasons beyond your control, are you unable to obtain the details on several important requirements, or are the requirements in a state of flux?
• Are the resources working on the project already known at the planning stage? Or will they be assigned at a later time?

The answers to some of these question may lead you to creating a requirements log, and seeking approval on individual requirements, versus documenting everything first, and then getting approval at the end. It may also lead you to work review cycles into your requirements gathering process with the people working on the project (“the doers”) to reduce the likelihood of re-work to the design once requirements are handed over for execution.

Tip #4: Hoard templates, diagrams, and any other organizational paraphernalia that you think could be useful to you someday like a pirate’s bounty

Hoard templates, diagrams, and other organizational paraphernalia

This is the stuff you need to give you background information on how things work in your organization, and you should start collecting it from day one. It’s not enough to know the tools and techniques for business analysis. You also need to truly understand the business you are working in.

Tip #5: Marry your project manager

Marry your Project Manager

No, I don’t literally mean marry your project manager, but just as communication is the key to any good marriage, the same is true for your relationship with the project manager on any given project. You have to keep them in the loop on issues in the requirements gathering process, and seek their guidance in issues affecting the bounds of the project.

These are just a few tips that I gathered over the years, partly through trial and error, partly through my own research. Starting a new project can be overwhelming sometimes, depending on the size and complexity of the project and when in the project life cycle you were assigned to it. I hope these tips prove useful to you, regardless of the circumstances you were brought on board the project. Good luck!

How to Fill the Potholes in your Business Requirements

Don’t let those potholes swallow you up!

It is springtime in Ottawa, Ontario, Canada. Beautiful, glorious, Spring! Everywhere you look, the signs are there: frozen rivers are starting to flow, birds are returning and filling the air with their sweet melodies, snowbanks are shrinking, and…oh yes, potholes are showing up everywhere in the roads. As much as I try to avoid them, somehow they always get me. It takes a special breed of car to survive the tough Canadian winters. My Honda Civic is on it’s 10th year, 181,000 clicks, and still going strong.

Trying to avoid the springtime potholes is a fair analogy to a task that I am often asked to do as a Senior Business Analyst: reviewing and providing constructive criticism on business requirements written by someone else.  A road filled with potholes can wreck your car, just as a poorly written set of business requirements can wreck a project. My job when reviewing business requirements is to look out for these potholes, make the writer aware of them, and provide suggestions on how to fill them.

Digesting business requirements written by someone else can be challenging, depending on the writers experience, knowledge, and ability, so to make things somewhat easier, I provide a template for my clients to use. Before they start their requirements, I will meet with them to explain how to use the template and to discuss any questions they may have. Using a template, I at least know the intent of all the sections of the document, and it gives a greater consistency to the documentation I have to review.

Once the written requirements are sent to me for review, I start by analyzing the document from beginning to end. One of the first things I look for are acronyms or business terms that have not been defined. This usually happens because the writer thinks that they do not need to elaborate on the use of terms internal to their business unit, but they forget to consider the audience of the document they are writing. Clear and unambiguous definitions of business terms are especially important to the developer, as they can have a direct impact on how they architect the system.

I also pay a lot of attention to the process diagrams of the current and future states. It is a very common mistake to omit the alternative paths to a process. It is understandable how this can happen. People assume that because the process usually happens a certain way, that they do not need to mention the other rare scenarios. Others may think they only need to describe the perfect world scenario, and forget to think of all the what-ifs. For a manual (non-computerized) process, unusual scenarios can be dealt with simply by communicating with those affected. When the process goes electronic, it is another story. The programming logic has to include all the alternative paths, or the system could fail spectacularly. This is a mind-shift for people that can take some getting used to.

When I am ready to dig into the detailed requirements, there are a few things I am on the lookout for. First of all, what I do not want to see are long, wordy paragraphs with several requirements buried within it. It may feel more natural to write this way, but not only is it painful to read requirements this way, it also greatly increases the likelihood that a requirement will be missed somewhere along the way, either during the development, or in testing. A much safer practice is to write each individual requirement separately, and give it an identification number. That way, even if a requirement does get missed during development, it will get picked up in the testing, assuming your test scripts have appropriate requirements tracing as well! That’s the topic of another post.

Secondly, I want to see a clear link between the in-scope deliverables laid out in the project charter, and the detailed business requirements. This is so important, because people can and will forget (perhaps conveniently sometimes) the original goals of the project, and before you know it, the scope of the project has grown exponentially. Believe me when I say, this is a crazy train that you do not want to be a passenger on. To create that linkage, what I will do is ID each of the in-scope deliverables, and use them as the parent IDs for the detailed “child” requirements. That way you know where each requirement is coming from.

Finally, I watch out for requirements that delve too deeply into design details without properly explaining the need behind it. This is a risky thing to do because when describing design details as a part of requirements, you limit the technical architect’s (or whatever you call that role) ability to design the best system to meet the client’s needs. That said, there may be cases where a specific design may be warranted, but the reason for that should be explained clearly. There are, in fact, some people who feel that requirements should not contain any design details at all, and only state the need. Others feel that not only is it ok to include design in the requirements documentation, but fully expect it. This is a contentious issue that I will not attempt to resolve here, but suffice-to-say that you should do your homework before you start writing your requirements. Find out what the practice has been in past projects, and what is expected of you now.

While this is not an exhaustive list of everything I am on the lookout for when I review someone else’s business requirements, this represents the bulk of my work. Hopefully you’ve read something new in this post, or at least can relate to what I’ve written. If you would like to weigh in on this topic, please leave your comments below.

Storyboards: Use Cases on Steroids

Use cases are great for gathering high-level requirements, and they should play a role in all requirements gathering processes, however; they are limited in their usefulness when you’re ready to dig into the nitty-gritty details. Sometimes you may want to drive your discussions down specific paths that your use cases just aren’t taking you to. Or maybe your client is having a hard time visualizing how the pieces of the system fit together. Another possibility is that you have multiple groups of clients who are all supposed to following the same process, but each is doing it a little (or a lot!) differently. That’s when you know you need something more. And that’s when I pull out the big guns. I’m talking about storyboards, folks.

Pulling out the big guns

The origins of storyboards come from the movies. They are used to visualize and plan the various scenes in a movie. When it comes to defining business requirements though, I like to think of it as telling a story with your requirements. Just as they can help visualize and plan the scenes of a movie, they can help you visualize and plan a business process.  Used together with your use cases, they are sure to take your requirements gathering to the next level.

There are no hard and fast rules for constructing your storyboard, so you should do what works best for you. What I like to do is create a document describing my storyboard that my clients can follow along with. Then I throw it up on the projector for everyone to see, or worse-case scenario, I print it off for the attendees of the workshop. To each step of the storyboard, I append a list of question that I go through with the client, and I record their responses right in the document. The end result looks like a long list of these:

A typical step in my storyboard.

Tip: When recording your answers, you may want to keep track of who said what, as this question tends to come up from time to time, or if you plan on analyzing the distribution of your requirements.

Using storyboards like this, you can describe a process step-by-step, end-to-end, in a way that’s easy for your clients to follow and understand, and it will drive out the details of your requirements that you may not have been able to get at until now. Depending on how many clients you have involved in your requirements gathering, you may have several copies of completed storyboards, each one representing a different group that you met with. Once you’ve completed all your requirements workshops, now comes the fun part: figuring out which requirements to keep, which ones to throw out, and of the ones that are kept, the relative priority. That, however, is a topic for another day. Watch out for my next post on requirements prioritization! Yes, it deserves a post all of it’s own;-)

A Real-World Example of the State Transition Diagram

Whenever a workflow of some kind is being converted to an electronic process, you’re going to be looking at creating a status-driven process. That’s because the object passing through the workflow needs to receive status changes to indicate that the previous step is completed, and to trigger the next step of the process. Recently I was involved in a project converting a thesis submission process from a paper-based process to an electronic process and it serves to illustrate the usefulness of the State Transition Diagram for this type of project.

In this example I used the Bizagi Process Modeler to create my State Transition Diagram. I prefer it over the other tools I use because it’s free, the diagrams are more aesthetically pleasing than the other tools I’ve used, and it is quick and easy to use.

To give you some background about the project that the State Transition Diagram presented below is based on, the submission of Master’s and Ph.D. theses in my institution is not overly complicated, but there are many different forms that must be completed by a variety of people, including students, administrative staff, and faculty. I needed an easier way of explaining all the steps of the process and what forms were being released at each step. Enter the State Transition Diagram.

Something else we had to make a decision on with this project was where to start the electronic process. The thesis submission process is lengthy, and we had to decide whether to include the part of the process – before it is officially deposited at the Graduate Studies office - when the thesis is still under development. To reduce the scope of the project, we decided to start the electronic process after the thesis has been developed and the student is ready to officially submit it to Graduate Studies.

This diagram demonstrates the status progression of the submitted thesis. Starting from the left, we see the first status is “Pre-Upload”. This is before the thesis is uploaded by the student. The circle following that status is the “Thesis Uploaded” event. Any circles like this one that have a double border around it are known as events. This first event indicates that the student has uploaded their thesis via the new electronic process. From this event we see a dotted line leading up to a gray rectangle, known as an annotation. The items listed in this rectangle indicate the forms that the student must complete as they upload their thesis. Once this event occurs, the status of the thesis becomes “Thesis Package Received”, which triggers the release of the Thesis Defence Authorization Forms. These are forms that go to the members of the defence committee who must decide whether the thesis is suitable to defend, hence the decision diamond that follows this status: “Defence Authorized?”. If the decision is no, the status of the thesis becomes “Defence Denied”. If yes, we next see the “Notice of Defence Approved” event. This is where a notice is posted in some locations around the university listing the members of the defence committee, and the date, time, and location of the defence. Once this event occurs, the status of the thesis becomes “Ready for Defence”, and from this status we see another annotation leading upwards listing some more forms that are released with this status change. Following this status is the “Defence” event. This is where the student defends their thesis before the defence committee. At the defence  the committee will determine whether revisions are required or not, and thus we see another decision diamond for “Revisions?”. If the decision is no, the status proceeds to “Thesis Accepted”. If yes, the status becomes “Requires Major/Minor Revisions”, and in the annotation above this status we see the Thesis Revisions Approval Form is released. Following the “Requires Major/Minor Revisions” status is the “Revisions Uploaded” event. This is where the student has uploaded their modified thesis according to the revisions that were provided to the student at the defence. At this point the decision must be made as to whether to accept the revisions or not, and so we see the decision diamond “Accepted?”. If no, the flow goes back to the “Requires Major/Minor Revisions” status. If yes, it proceeds to the “Thesis Accepted” status. Going down from this status is another annotation showing the final forms that the student must complete before the thesis is electronically packaged and sent to the Library for publication. That’s why the next event we see is “Thesis is sent to the Library”, followed by the final status “Transferred to Library”. This is the end of the electronic thesis submission process.

Explaining this workflow to my stakeholders with the help of this State Transition Diagram that they could follow along with was much easier and was more meaningful than reading just a written explanation or explaining it verbally. It may not be a useful tool in all situations, but for workflows, I find it indispensable.

If you have any questions or comments about the process I’ve described, please post them in the Comments area below.

Scope Modeling: A Case Study of the Context Diagram

Defining the scope of a project is something I have often heard referred to as “herding cats”.

All joking aside, it really is a very good analogy to the early stages of a project. It is common to see multiple stakeholders, often with different agendas and perspectives, and that’s just the stakeholders you know about. Always do a thorough stakeholder analysis before you attempt to model the scope, or you may be in for some unwelcome surprises down the road.

For the purposes of this article though, I’m going to assume you’ve done that already, because what I really want to talk to you about is scope modeling.

You don’t have to stick only to written statements to define your scope. There are a variety of models you can use that can help you capture the scope of your project. Some of those models are:

• State Diagram
• Entity Relationship Diagram
• Data-Flow Diagram
• Organizational Model
• Context Diagram

There are some very good reasons to model your scope. First of all, many people understand things better when they can see it visually. People quickly grow tired of pages of documentation, and sometimes important details get buried in paragraphs. A diagram is just faster and easier to understand. Secondly, it makes a nice compliment to any documentation that you’ve written, thereby facilitating comprehension. Throw a lot of mud at a wall, and some of it will stick.

What I like about the Context Diagram is that it’s pretty easy to grasp by almost everyone. As I’ve explained it to others, it represents who’s doing what. It is not flow. There is no sequence or timing represented in this diagram. Just interactions. This is quite useful when you’re defining scope because you generally don’t care about the sequence of things at that time. All you want to know is, what’s in and what’s out.

So to show you the Context Diagram in action, let me show you how I used it for a project I’m currently on. The project is for a research office at a university that oversees the process of applying for research funding, ensuring compliance to  governing bodies, and providing reporting on the progress of ongoing research projects. They have a strategic goal to increase research funding on campus, but they are using a data system that is poorly suited to the work that they perform. They have little hope of being able to handle the increased activity that comes with meeting their strategic goal when they are using inadequate tools to do their job, so they need a new system that is better suited to their needs.

My approach to this project has been to identify which processes they wanted to be improved as a part of this project, model the current state (as-is) of these processes in a Context Diagram, then model them in their future state (to-be). Modeling the current state in this way will allow us to spot automation opportunities or other improvements, and the future state model will demonstrate how we expect the new system to affect these processes. There were three main processes the stakeholders identified to me:

1. Proposal development – this is where the researcher constructs their application for research funding.
2. Communicating results – after the research office receives the responses from the funding agencies in regards to which proposals have been approved and not approved, they must communicate the results to the greater research community across the university.
3. Final documentation processing – Updating compliance information, entering/updating protocols, and sharing funding data with the department for research accounting.

Bringing these three processes together, I came up with the following Context Diagram representing the current state:

The square at the center of the diagram with the word CURO appearing in it is the research office. As you can see, they are the gateway for all the information that goes into their database system, Eclipse. In the left third of the image, you see the Proposal Development process. In the right third is Final Documentation Processing, and in the center is Communicating Results. How easily we can see from this diagram all the pressure on the research office, CURO, to keep this process moving. Clearly, if they want to increase their research activity, they need to alleviate some of this pressure.

Now take a look at the Context Diagram for the future state:

Notice the decrease in the number of arrows going to and from the research office, and the increase in the number of arrows going to and from the new system. This will shift some of the pressure off of the research office and onto the new system.  There is also considerable interaction between the researcher and the system, so not only will the new system have to have some self-serve capabilities, but this system will have to be intuitive enough that the researcher can use the system effectively without extensive training. Last but not least, notice the second oval to the lower right. It is the student information system at use in the university, Banner. The new system is expected to pull information from Banner to reduce data inaccuracies and the amount of manual data entry that is currently required.

Putting these two diagrams together, we now have a much better idea of what the scope of this project is, and what expectations we have for a new system. These diagrams will also be used when we go through the RFP process to select a third-party vendor.

I hope I have demonstrated the value of using the Context Diagram when defining the scope of a project, however, it is not the only tool that can be used for this purpose, and in future posts I will be exploring the value of some of the other diagrams mentioned at the start of this article. Stay tuned!

Getting Sign-off: How to Educate and Get Buy-in From Your User Community on Requirements Sign-off

Getting sign-off of the business requirements can be a tricky business in some workplaces. Everybody seems to have a different idea of what it means for them to sign off on the requirements. There are people who are willing to sign off before they’ve even read the documentation, and others who wouldn’t sign it if you paid them money. Neither one of these extremes is a good thing, and if you are facing these challenges, you need to consider how you can educate and get buy-in from your user community in getting sign-off on your business requirements.

To educate and get buy-in from the user community for sign-off on requirements, let’s first establish what “sign-off” means in your workplace. Sign-off can mean different things in different workplace cultures and you need to find out what is acceptable in your organization. Here are some options for sign-off:

1. Physical pen to paper
2. Emailed statement of approval of the requirements
3. Verbal agreement in front of stakeholders
4. Approval Workflow using SharePoint

There may be others that you might want to consider, but of these four options, my favourite by a mile is # 4, however, not a lot of people have SharePoint available, so if that’s the case for you, I think your next best option is  #1 first, and if the client expresses significant reluctance or hesitation, then go with option # 2, but only if you are working with clients internal to your company, and on projects that require less formality. When you are dealing with external stakeholders, you need the additional formality that option #1 has to offer. That said, the trouble with # 1 is that it smacks too much of a legally binding document that will have severe repercussions if something goes wrong, and this intimidates people.

On the plus side though, if you can get a client to agree to it, this is the most accepted form of approval that you can get.  I believe option # 2 is a very close second because it provides a clear history of when and who approved the document. Better still, the client can word their agreement how they wish, which makes them feel more comfortable with the sign off. I have used this method on some of my own projects and found it worked very well. Whatever method you choose, you must stick to it and be consistent in its use. This will require training combined with continuous reinforcement.

You also need to establish who you want to sign off, and why. For example, getting sign off from the business SME(s) is not likely to be debated by many, but if you intend to seek sign off by a technical lead (and I think you should) you need to be ready to justify that to members of your technical team if they have not been asked to sign-off on requirements before. In my line of work, the technical team doesn’t usually like surprises…

The approach for training should be different depending on whether we’re talking about people internal to your working group, or those stakeholders external to your group. You cannot expect external clients to attend training sessions explaining the requirements sign off process, but you can talk about it at project start up. The project kick-off meeting is a great opportunity for this, as well as explaining all the other aspects of the project. This should be done for every project, big and small, even for repeat clients. At every kick-off meeting, all the tasks of the business analyst should be stated (i.e. will write the requirements, will seek sign-off on the requirements, will conduct meetings, will perform testing, etc.) In addition, the process for the requirements gathering process should be explained in detail. For example:

Step 1: Gather requirements using whatever means necessary, i.e. stakeholder interviews, meetings, brainstorming sessions, etc.

Step 2: Model the requirements and solicit feedback.

Step 3: Write business requirements documentation.

Step 4: Release initial draft for feedback.

Step 5: Update document and release second draft for feedback.

Step 6: Repeat step 5 until there is no more feedback/changes.

Step 7: Release final copy and seek sign-off.

Reviewing the business requirements template(s) is also a good idea at this time to let the client know what to expect, and also to let them know that their feedback on the process is welcome. Last but not least, the reason for sign-off should be explained to the stakeholders so that they understand this does not mean the requirements are frozen (a common misconception!) but that the means by which requirements change will be different from henceforth, for example, after sign-off they will be using the Change Request Process, rather than simply adding new requirements to the list of existing requirements. You may also need to explain the Change Request Process.

Project kick off meetings may be good opportunities to get the message out to project stakeholders, but they may not be a good way to get the message out to the members of your technical group due to the fact that technical resources are not always assigned at the start of the project, so for these folks you should find other ways to reach them. If your organization has wider general meetings to discuss the latest happenings amongst the various teams, this would be a great place to reach the group as a whole. All it takes is a short presentation once or twice a year on the common roles and responsibilities of the business analyst, and the requirements gathering process. The points of emphasis for this group, however, should be slightly different. In this case, you should highlight what it means for a technical lead to sign off on a business requirements document. It is important to state that the signature of the technical lead shows that they support the solution that is proposed and believe it is “do-able”. That said, you must be prepared to answer the inevitable question, “What happens if the project fails? Will I be blamed?” By presenting an overview of the BA role in this fashion, it gives your technical group the opportunity to give feedback on the subject before they are committed to a project, so they know what to expect when the time comes, and are therefore more likely to be willing to sign-off.

Another point that merits discussion within your technical group is where to draw the line between business vs. technical requirements in the business requirements documentation. This discussion can touch on the tendency for BA’s who have a technical background to get into the technical details of the solution when documenting business requirements, but that this should be avoided. The BA’s job is to state the business need; not design the solution. For this discussion, you can present a list of dos and don’ts that can illustrate this point.

In addition, you need to be clear on what artifacts you will be producing for the project, and who will be producing them, for example, the BA does the Business Requirements Document (BRD), but the Programmer/Analyst is responsible for the functional/technical specifications, etc.

Finally, you need to decide on a repository to store and maintain business analysis documentation that everyone has access to and can refer to if needed. This could be kept on a network share, however network shares tend to get lost, disorganized, or ignored. Ideally, such documentation could be kept in a more visible location, such as a SharePoint site that is accessible by the entire department.

These are just a few ideas to get you going in growing support and buy-in from your user community in getting sign-off on the business requirements. Don’t be afraid to try new things, and even make mistakes sometimes. It takes time, perseverance, and some trial and error, but it will be worth the effort.