The Seilevel message board is back up! The message board was on a hiatus for awhile but we’ve cleaned it up and revamped it. We are happy to say its back up and better than ever.

Do you have questions or comments on software requirements, requirements gathering, elicitation, conflicting requirements?

Do you have questions about business objectives?

Want to discuss a tool?

Are you looking for requirements resources? Use case questions?

Questions around getting your business analyst certificate?

General questions as a BA?

Want to discuss Agile or BABOK?

It’s all there plus much more. If you are not a member sign up today.

Check out our new and improved message board  today.

Seilevel will be at the University of Texas Career Expo on September 8th.  The expo is being held at the McCombs School of Business.

We will be there talking to current business students about a career path as a Requirements Analyst/ Business Analyst.

We are looking for people who:

• are excited to learn completely new subject matter
• have a history of success in everything they do
• are willing to admit and learn from their mistakes
• consistently perform in the top 5% of the population
• love interacting with people
• have a history of great team leadership
• are crazy about work and play

Do you want more info? Interested in our Requirements Analysts/ Business Analyst position once you graduate? You can check out more info on the Career Expo here and our full job descriptions here.

Over my professional years, I have learned one really important life lesson: Every time I make a mistake, I learn a lot. So I was thinking about that in the context of being a BA. I believe that making mistakes is not such a bad thing and instead should be seen as a wonderful opportunity to learn more about how to be a better BA. These are some of the mistakes I encourage you make….or if not to outright make, at least be ok when they happen and recognize the lessons learned.

1. Miss a requirement: As BAs, we know we must do everything we can to not miss requirements. But here’s the deal, we are going to miss requirements, I guarantee it. There is no such thing as a perfect requirements document. So the sooner you can miss one, have it later be realized, and see that you can survive it, the sooner you realize that it’s ok to not be perfect and there are processes to recover.
2. Hire someone who actually doesn’t want to be a BA: Working with a BA who doesn’t love the job as much as you will help you recognize even more so why you do love it. These people will likely not work as hard as you at the job, so you will be frustrated. And with this you will learn how absolutely important it is to hire the right people. I do believe hiring the wrong folks will ultimately help you hire more of the right ones over time by helping you hone the set of skills and personality traits you need.
3. Ignore the details: Go on, get lazy about the details and see what happens! As an example, you really have to follow the template formatting exactly and worry about your style headings? Well, I’m super detail-oriented, but sometimes I wonder rather I really have to be as careful as I am about those pesky details because they can be so time consuming, especially if we are working long hours. Well, once you make the mistake of not being detail oriented, and someone complains or you figure out you really needed to be more detailed and have a harder job to recover after the fact – then you will gain the appropriate level of respect for the details that do matter.
4. Manage your requirements in Word: I’m willing to bet, you’ve already done this one! Haven’t we all? But having a project right now where they refuse to use a tool and we have instead got 100 different documents of information to manage and not trip over each other with is reminding me once again that you must use one at all costs! With brand new BAs who don’t really know the value of using a tool over something like Word, I actually like to let them feel the pain of this fully before I force them into using a requirements tool – otherwise they won’t really adopt the tool and will be frustrated by it being forced on them.
5. Write 1000 shall statements, call it done, dump the 500 page doc on your developer’s desk and walk away: Check back in a few weeks later and see if the developer has used it. Or don’t, because we know they haven’t. One of the most important lessons I learned was from someone else’s mistake, though I had also been guilty. I had to come into a project and read 2000 shall statements to get up to speed on it. Needless to say, there was no way I had a clue about what the system really needed to from that document, and neither would a developer. If anything I just had  great reading material to put me to sleep at night! Anyway, in going through this, I realized I had done this very thing myself. I had written the long documents of requirements and was so proud because I was sure it was all there, written down in plain English. But up until that point, I hadn’t considered whether the stuff I’d written down was actually consumable. And with that, I learned the awesome lesson that you really do need models (like RML®!) – to add visual context and better explain the requirements.
6. Have a full on failure project: I really don’t want to promote purposefully failing your projects, but if you are in one that is failing, take it as a valuable opportunity to learn that you alone cannot save the world. Here’s the deal, most of us aren’t performing brain surgery (though if your project IS related to brain surgery, that’s a great example of a project NOT to make this mistake on!!). But rather, most of us are working on corporate IT software, so if you screw up, no one is going to die. Also, many of us have the type of personality that really does want to please our end users and help build the right software. So when things aren’t going well, it’s extremely frustrating for us – making this lesson so hard to learn. Once in a failing project, I found myself pouring more and more of myself into it, only to continuously be disappointed…and  tired. But I learned so much by stepping back and looking at why the project was failing – recognizing all the things I did right and learning from all the mistakes that myself or others made. But the big takeaway on this one for me was that you don’t have to save the world on every project. And if a project fails, it’s likely not your fault and not your responsibility to fix it. Just show up and do your best BA work and learn what you can do better next time!

On our projects we are often asked to provide our requirements to the development teams with business prioritization.  I’ve been in meetings with my business stakeholders where we  have sat in front of a list of requirements and attempted to prioritize them one by one.  In my experience, this effort ended up prioritizing the list based on the stakeholders “gut feel” of the requirements, due to political clout, or just people being more demanding than others.  Using this gut feel method does not ensure that the critical requirements actually make it “above the line” for project development. 

After a period of time I realized that these prioritization discussions were repeatedly following the same path.  I wanted to be able to break some of the stalemates, and by providing some additional criteria to be used in these prioritization reviews. 

I came across an article called “Requirements Prioritization” on the www.requirements.com website.  To summarize, the article lists out several options for requirement prioritization.  Of course included in that list was the stakeholder agreement model, which I mentioned above but included other alternatives for helping with prioritization. 

Value, Cost and Risk
Prioritize based on business benefit or cost savings for implementing the requirement.  This is a great way to get people re-focused on the “quick wins” for an organization.  By focusing on business value you depersonalize the discussion. The challenge is that business stakeholders may not have had the time to do an in depth analysis, or the background to feel comfortable with this model.   This model works extremely well with executives who are focused on these business analytics.

Regulatory Compliance
Requirements that are needed to pass a legal and or regulator agency should be given the same priority an organization has to meeting those requirements.  I’ve been in several discussions where just because a requirement met a condition for a regulatory compliance issue that alone pushed it to the top of the list.

Difficulty of Implementation and Likelihood of Success
These two criteria go somewhat hand in hand.  These methods allow the easy “wins” to be prioritized and for the project to gain some critical success and key visibility before deep diving into more difficult development areas.   This approach would enable stakeholders to become more familiar with early project results and provide critical feedback before going forward to build more difficult and possibly more expensive aspects.

Since reading this article, I’ve attempted to incorporate these other viewpoints into my requirements prioritization sessions with good success.  I have found that by using these different perspectives on when prioritizing the requirements can help break stalemates, and end political arguments.

Being a relatively new Requirements Analyst/ Business Analyst ( BA) and being new to the industry, I have been blessed with the opportunity to have mentors. Receiving direction from more experienced BA’s has definitely helped me find areas that I can improve on, while at the same time, finding my strengths and improving those too.

Yet there still are challenges that I face while trying to learn as much as possible. For instance, Senior Business Analysts, who are my mentors, will most likely be at client engagements for the majority of their time and it can sometimes be very difficult to find time to teach. Through my experience so far, I have learned a couple of tips that can help those aspiring and budding BA’s out there:

1. Always be on time
This cannot be reiterated enough. I will admit that I have had a slip up myself, but it is crucially important that a junior Business Analyst always be on time.

2. Ask informed questions
Never be afraid of sounding stupid. My mentors would rather me ask a “stupid question” that helps me understand the business problem than floundering about and end up making a mistake farther down the line.

3. Do not assume
Assumptions are bad. Always ask yourself what assumptions you are making when you are creating deliverables for the client. You may come up with some good questions or issues that your Senior Business Analyst didn’t catch before!

4. Use Spell Check
Spell check is your best friend when creating deliverables for clients. Not only does misspelled words make you look less credible, but it can make your organization look less professional too.

5. Take Ownership
Take ownership of the tasks that you are given. Don’t just wait to be fed information and small little projects. Instead, think of yourself being the sole proprietor of the task and think to yourself, “What can I do to make this successful?”.

6. Understanding Communication
Understanding what you are being asked to do is crucial. If you have a small amount of doubt in your mind, that is your cue to ask your Senior Business Analyst for clarification. The last thing you want to do is make the wrong assumptions and create something that the Senior Business Analyst didn’t ask for.

I hope that these little tips will help some of you aspiring and budding Business Analysts out there. I will be sure to add some more simple smart tips in my later blog posts!

Last year, I wrote about my Lessons from a Bad Haircut.  I’m please to say I finally have a lesson from a good haircut.

 How did I finally get a good haircut? 

It was what the stylist did after I explained what I wanted.  She drew a quick sketch.  It took about 15 seconds.  And, with that sketch, I was able to say “No, that’s not what I want.”  60 seconds more of discussing what I wanted while pointing at the sketch, and she’d refined the sketch until both of us were confident that we were talking about the same thing.  The sketch was very crude and would never be confused with a work of art.  But, that wasn’t the purpose.  The purpose was to convey an idea.  And it did.  And, I got a good haircut.

So, what does this have to do with requirements?  

Most people relate to pictures much more easily than to words.  “Pictures” are all of the diagrams included in the RML®, such as process flows, wire frames, BDDs, etc. 

One of the major things to remember about creating these diagrams is that they don’t have to be perfect to be useful.  They simply have to be sufficient to convey the idea.  And, once a model of the idea is out there, the discussion becomes very productive.   If you can project the diagram or sketch it on a white board, people will point at it and discuss—what’s right?  How do we make fix what isn’t?  At the end the discussion, with an updated diagram, you’re ready to move forward with all parties confident they are headed down the same path.

When working with a client who wants me to skip the model and go straight to the words, I’ve found they react well to the statement “If we’re not in agreement about the model, we won’t get the words right.”  They get it:  it’s a matter of being more efficient and synching up our understanding as rapidly as possible, rather than wasting time on misunderstanding.

If I revert to my hair style of ten years ago–all one length and all I need is a trim–I can skip the sketch or picture.  Otherwise, a picture or sketch will be a prerequisite to any haircut I get.  I similarly recommend that requirements models be a prerequisite to any requirements you write.

This is the typical response received when we suggest using a formal requirement management tool.

“Doesn’t MS Word provide enough functionality  to manage requirements? We’ve been using it and it’s worked fine for us so far.”

 It may be simple to jot ideas and start writing requirements in a Word document, or any other text editor, however, there are many limitations associated with using only one tool that is not designed to manage requirements.

These are the main limitations:

1) When making changes, it’s difficult to update and keep track of these changes,

2) It’s difficult to store extra information or additional detail about requirements, and

3) It’s difficult to link requirements to what is developed, tests, and defects. It is the goal of the requirements tool to provide a robust solution to managing requirements.

The following are some reasons to use requirements management tools.

Each tool you research should, at the minimum, be able to solve the following issues that a traditional text editor does not. The most obvious benefit is that with a tool, your requirements are all in one place: no more tracking down documents and trying to decipher which version to use, if your company uses versioning.

Ability to Manage Version and Changes

When business objectives change, requirements inevitably change. A requirements tool will keep track of changes implemented. It also becomes easy to revert back to previous versions, if necessary. Many people try to use SharePoint to distribute updates to documents. This can work, however, it’s easier to edit in real time in the same application rather than needed to put alerts on a document and checking it in and out. With a requirements management tool, people can work collaboratively in real time.

Store Attributes

Information, or attributes, concerning requirements should be associated with the requirement. This makes needing to remember what other document these attributes are stored moot. Additional examples of common attributes are author, person responsible, origin, priority, status, difficulty, stability, and risk.

Link requirements

It is necessary to link requirements to business decisions, emails, and conversations for traceability. It answers the question of “Where did this requirement come from?” and it also answers the question of “What other systems or element could potentially be affected?”. Also, being able to link requirements puts each team accountable for its actions. If, when you’re testing,  a test fails, it becomes convenient to link the requirement to the test to ensure that the team knows that the test should pass.

 Track Status

This helps to ascertain where the development team is on working each requirement, whether the requirement was deemed out of scope, etc. Being able to track status also provides a quick progress report for the project manager, or other responsible party. Status is an attribute of a requirement.

Control Access

If you’re working with teams across the state, country, or world, controlling access is a vital part of requirements management. You do not want someone editing requirements who should not be doing so and you want the ability to see a history of who edited which item.

Reporting

An additional benefit of a management tool is being able to better determine reporting and success measures.

 It does take time to determine which requirements tools would be the best solution for your company, and it does take time and effort to train users to ensure adoption, but those investments are worth the cost for better management and increased success. However, before starting your research, be sure to ensure your process of eliciting, developing, and reviewing requirements is effective, because a management tool will not help with the processes involved with developing requirements, it only helps with managing what you have.

I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team.  A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well.  However, unless you are at an executive level, there is very little you can do to shut down the black ops team.  In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built.  Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence.  However, once their presence is detected, a project and budgetary train wreck usually ensues.  

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place.  It’s probably because of one or more of the following reasons:

1. Low confidence that IT will be able to build something that actually solves a business problem.   Sometimes this low confidence is warranted.
2. No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it). 
3. Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it. 
4. Lack of understanding about why it takes so long to develop working software.

Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1. Keep the business engaged throughout the development lifecycle.  Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.
2. Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution.   Giving the business ownership of the process will help. 
3. Each project should have a clear ROI.  This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…”   People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem.   Just watch out for pencil-whipped  and contrived ROIs.  Be suspicious of any feature which does not tie back to a quantifiable business objective.
4. Use comparable projects to set expectations.  People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be.  This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”.  In order to head this off, it helps to show the budget, resources, and time to execute for similar projects.  It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?”  You can use the lessons learned on other projects to help answer this question. 

It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true.  Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.

One of my good friends recently changed jobs. For several years he was working with a fairly large software developer that loved to boast that they always had positive margins, always showed growth. I guess it isn’t too hard when you create nearly fixed cost products that can be resold over and over.

From my conversations with my friend I learned two things that I found very odd. The programs they created were never based on a researched business need or market analysis and none of the programming they did was based on documented requirements. Sometimes they created programs just because a sales person for a group said that he would buy it if someone made it. The worst of the stories involved having him program an add-in for an accounting software suite to integrate with an online sales platform. That doesn’t sound bad, except that they were going to charge for this add-in when the makers of the accounting software already offered the same product for free. I still can’t fathom how they weren’t losing money by just creating software for anything and everything, that they never made a business case for these programs. One of his ‘perks’ was that he had customer interaction by doubling as a customer support specialist for the software he created. Whenever he completed his sprint tasks ahead of time and was working with customers to fix bugs, he would get bored and ask them what they wanted the software to do. Then he coded it in. Otherwise, the customer’s needs never really got documented. However, he now works for a video game company here in Austin. A funny side story is that he actually had some fans of the company come up to him and ask if he worked for them and if he worked on their favorite game because of his company hat.

Several days into his employment he called me up and asked a few questions that made me chuckle.

 ”Hey, so what is this user story everyone is talking about?”, “Oh man we have a ton of meetings to decide what our programs do before we code them”, “So this is what you do? I love what you do!”, or “These wireframe things are awesome, I’ve never used them before!” The juxtaposition of his two roles is amazing.

Now when I relax on the weekend by playing a game or two I can’t help but think about all the requirements and documentation that went on in the background to make this piece of fun entertainment. Just like all the e-commerce websites, logistics systems, and loan originations software I have documented that was real serious business. Yup, even the game makers get it.

Lately we have run into a number of projects that focus on reporting and analytics. As always our job is to determine the requirements. For analytics and reporting however, the requirements are a bit different than a traditional functional based portion of the system. We use a couple of different models, the report table, report flows, data dictionary and display action response (DAR) models.

The purpose of this post is to outline the steps we take to document requirements for analytics and reporting. A lot people we see doing this work  focus on the data in the reports. However this is a bit backwards. Instead, we focus on the business processes and the key decisions that are made from the reports. Ultimately the reports are used to make business decisions (even if those decisions are sometimes to do nothing) or to decide to take a specific action. Instead of focusing on fields,  we start with the business process and the decisions that the people using the reports need to make.

The problem with focusing on the fields is that it becomes very easy to group related information together, yet make it very hard for someone in the business to make their decision because they don’t have all the information that they need in a single location.  

Here is the process in a nutshell:

1) Define the business process - hopefully this is done as part of the overall requirements effort so you won’t need to do it for this portion of the project.

2) Define the decisions or actions that are being taken – often times these are the diamonds in the process flows.

3) Define the specific information that is required to make the decisions.

4) Design reports that support one or more decisions.

The key model that we use is called a report table. Included is the information that we collect to form our report table.

Fields in a report table

Reports are also linked in a variety of ways. We typically define a dashboard level which shows KPIs. KPIs are groupings of metrics and metrics consist of layers.

An example might be, a KPI of Growth which contains multiple metrics such as new customers and canceled customers. Within the metric of canceled customers there would be multiple layers of drill downs into more detailed information. Potentially the first layer is at a company level, the next level is a regional level, and then down to the level of viewing a breakdown of cancellations by cancel reason. The format we use is an excel spreadsheet with tabs (worksheets) for each metric. Within each tab are the fields as rows and the layers as columns.

Layout of a Report Table Spreadsheet