Here is our monthly selection of interesting knowledge material on programming, software testing and project management: Blog: Agile Scenarios and Storyboards Blog: The difference between Test First and Test Driven Development Blog: Daily Process Thoughts: Agile Coach or Scrum Master Blog: Daniel Cook on 8 Laws of Productivity Blog: 5 Things That Will Make Your Agile Development Project FAIL Article: Transitioning to Agile Article: Exploratory test adventure: a creative, collaborative learning experience (PDF) Article: Designing Experiences for Responsive Web Sites Article: Is Agile Always Appropriate? Article: SQL Performance Issues: Query Compilation Article: The Implications of Having a Definition of Done on ...

I spent the greater part of my evening trolling Kickstarter.com. You’ve likely heard of it and maybe you’ve even donated funds to support a project. There were a couple projects which I found quite interesting, which I wanted to share.

1. Charge your iPhone as you walk, jog, and generally as you live your life: http://www.kickstarter.com/projects/358170719/infinity-cell-kinetic-charger?ref=live

2. Spark Core: Put anything you could ever imagine online: http://www.kickstarter.com/projects/sparkdevices/spark-core-wi-fi-for-everything-arduino-compatible?ref=live

3. Space Monkey: Have your home be part of the “cloud” without being reliant on one data center in a particular area: http://www.kickstarter.com/projects/clintgc/space-monkey-taking-the-cloud-out-of-the-datacente?ref=live

What do you think of these products? Do you have any others you think are awesome and would like to share? Let me know in the comments section below!

 

Trolling for awesome new products is a post from: http://requirements.seilevel.com/blog

In a survey of over 500 senior business and technology executives done by the MIT Sloan School of Management, only 18% say that their company’s IT spending was “highly aligned with business priorities.” This means that in 82% of organizations, IT is consistently spending time and money on projects that were not addressing the actual needs of the business.

As practitioners, our experience has shown that one of the reasons for this misalignment is that business and IT often have very different interests. Business wants to overload IT projects with features and expects IT to deliver quickly, while IT is much more concerned with mitigating project risk, keeping project budgets under control, and protecting themselves from being held accountable for project failure. As expected, such divergent interests often lead to friction between business and IT and lackluster project outcomes that don’t actually satisfy the business’s needs efficiently.

How can CIOs and other IT executives ensure that IT focuses only on those projects that will provide business value or address a strategic problem for the business? One way is to begin by analyzing the business problems that the project is attempting to address, and the business objectives of the project.

At Seilevel, we use a visual model called the Business Objectives Model to highlight the business problems that the project is meant to address, and the business objectives of the project. Creating this model requires extensive discussions with the project’s business and executive stakeholders to understand why the project is needed in the first place and the return on investment that the project is expected to receive. When done properly, these discussions should take the form of a dialog between IT project leaders and business stakeholders. The business help IT align the project’s objectives with the overall business strategy of the company, while IT leaders should provide feedback to the business on whether the project can reasonably be expected to meet those objectives. Rather than using the language of IT, the model should articulate the problem and objectives of the project in terms of money—fundamentally, decreasing costs and/or increasing revenue.

The business objectives of an IT project should align closely with the overall business strategy of the company. If they do not, or if the business objectives of the project are not clear in the first place, it is a good sign that the project should be canceled or retooled to align more closely with the organization’s strategy. While this may seem like common sense, it can be difficult at times to stop the momentum of a project once it gets going, especially when there is executive-level support and budget to pay for it. However, failing to perform this analysis before a project begins can lead to much higher costs later on. It can also damage the credibility of the IT organization as a whole, and create mistrust between business and IT that eliminates any hopes for generating alignment between business and IT. This type of mistrust can set up a project to fail.

As an example, when we worked on a project for a large technology company, we were faced with a hostile business executive who said, almost in so many words, that it was not IT’s job to worry about the project’s business objectives. His words were, “who are you [the product manager] to ask me about my business objectives?” However, after explaining how a lack of clear business objectives could easily result in the delivery of an unsatisfactory product, he clearly understood why the IT team needed to be a part of those discussions. The executive then agreed to work with us to define coherent business objectives, which we have used to drive the current direction of the project’s features and requirements.

Why IT Needs to Know Business Problems is a post from: http://requirements.seilevel.com/blog

We’re thinking of attending the 2013 Mind the Product conference in London this September.

 

 

 

 

 

 

Have any of our readers attended? Thoughts? Please give us some feedback in the comments section below.

Thanks!

Mind the Product 2013 is a post from: http://requirements.seilevel.com/blog

Code reviews and software inspections have existed for a long time in the software engineering world. They have been however only adopted by a minority of software development projects. Programmers have always been reluctant to submit their code to the criticism of their peer. The pair programming technique promoted by the Agile approaches has faced the same obstacles and is regularly ranked in the bottom of the agile practices adoption surveys. The situation has a little bit evolved with the development of tools for static code analysis. The automation of the ...

A nice trick that business analysts can use now that collaboration technology like Google Docs exists is to allow meeting participants to simultaneously collaborate on documents during the meeting itself.  Simply have everyone in your meeting open up the document on their own computer, and then everyone can edit the document together in real time.  In spreadsheets, how this works is that whoever clicks to edit a cell locks only that cell for themselves, while every other cell in the spreadsheet can be edited by other users at the very same time.

This allows you do much more collaborative work in your meetings, and much more detailed collaborative work. Rather than relying on dictating your comments to the scribe responsible for updating the document, each participant can enter their own comments quickly and exactly as intended.  This saves time in the meeting, and also allows for more precision in the document itself.

Additionally, collaborating directly on documents allows for several different tasks to be taking place at the same time.  If one stakeholder is entering comments about one part of your document, other stakeholders can enter comments about other parts.  This prevents wasted downtime and allows stakeholders to work ahead when their topics are not being discussed.

A great use for this technology is to quickly gain a consensus on priorities. You could walk through a list of features and have a column for each stakeholder to enter their ranking of each feature. After you read off the name of the feature, wait a few seconds for everyone to enter their ranking, and then have a column that automatically averages all the rankings. Everyone can instantly see how everyone else has ranked the feature, and ask questions on the spot if they don’t understand other’s rankings. This may spur needed discussions and eliminate confusions about the feature. This method allows quick prioritization and records the input of every meeting participant, so there is no guesswork as to why a feature was prioritized the way it was. This allows everyone to have their say, no matter how many meeting participants there are. It works for small meeting just as well as for large meetings with dozens (or more!) participants. And distance is no obstacle. You could have participants all over the world editing the document as quickly as if they were in the same room as you.

A final benefit of opening your document to online collaboration is that the stakeholders can add more to the document after the meeting. If additional details or changes come to mind later, they can jump into the document and add them instantly.  Your document becomes a living document that doesn’t require repeated meetings to improve, since improvements can be made at any time day or night by all participants.

The quality and amount of collaboration your team experience varies greatly depending on the types of tools that you make available.  Simultaneous online document collaboration is a tool that you should employ as often as possible to make your team more effective through improved collaboration.

Want more tips? Check our BA online resources!

Collaborate on documents during your meetings is a post from: http://requirements.seilevel.com/blog

Joy Beatty and Anthony Oden discuss the top questions about managing software requirements with global teams. What skills do you need to develop in your teams? What process frameworks should you put in place? What requirement tools are available and which should you consider?

Introduction to Joy and Anthony.

Joy kicks off the Webinar by giving an overview of the concept “Being Global,” and shares an example.

This section of the Webinar covers the requirements framework that must be established for all requirements activities.

Joy initiates the conversation around building requirements skills. She discusses taking into consideration what each team member brings to the table and how to tailor the learning path for each individual in the team.

Knowing how to build requirement skills and mentoring people is important to making your projects successful. Hear Anthony cover how to educate your team with the skills.

Covering the next level of the pyramid, building a framework. In this video the team discusses building a common framework: terminology, methodology and templates.

Continuing the conversation on frameworks, hear a real life example of how frameworks benefit your projects.

The third layer of the pyramid, tools, are covered in this portion of the Webinar. Joy discusses the five types of tools that Seilevel uses during projects.

Covering the top layer of the pyramid, this portion of the Webinar talks about measuring the success of your projects and sample outcomes you should consider.

Skills, framework, tools and metrics in the perfect world are covered in this Webinar summary video.

Want to see more? Visit Seilevel’s website for additional tips and videos.

How To Successfully Manage Software Requirements In A Global Organization is a post from: http://requirements.seilevel.com/blog

Methods & Tools is proud to be the media sponsor of the upcoming Scrum Gathering India Regional 2013 that will take place in Pune, July 36 and 27 2013. For Scrum , Agile and Lean Practitioners, Scrum Gathering India Regional 2013 is a unique opportunity to share and learn from Agile and Scrum community leaders, fellow practitioners and coaches. As a participant, you also get a chance to discuss and deliberate with experts on how to take your organization to next level of maturity using Agile, Scrum, Lean and other new ...

Recently, I attended a luncheon with a diverse group of people in the IT industry–coders, program managers, product managers, business analysts, and architects.  The topic of the luncheon is not important, but at one point the conversation veered towards managing a product backlog, and how to prioritize items in the backlog.  Two of the engineers in the crowd mentioned “refactoring” as an item that might go in the product backlog.

For those who don’t know, “refactoring” essentially is “cleaning up” an existing code base to enable changes to be made more efficiently, or to improve the performance of the existing system.  Refactoring usually involves restructuring or rewriting portions of code which are convoluted, difficult to understand, poorly documented, or unnecessarily complex.  “Refactoring”, the engineers argued, is often essential to add future features, so developers should be given time to “refactor” existing code–even if nothing else is in that sprint or release.

Sorry, but I have to call B.S. here.  “Refactoring”, in and of itself, adds no value, so it is not a feature, and should not be added to a product backlog.  As a product manager, how am I supposed to sell a release which includes no new functionality, but has “refactored” code? Why would anyone want to buy such an upgrade?  What does “refactoring” offer to a user?  Sure, it may offer increased performance or flexibility, but what if the user is happy with the current performance?  If it doesn’t add any business value, it isn’t worth doing.

Let me pause my rant for a moment to mention that developers who typically fight for periods of “refactoring” are typically the best developers on a team.  They can’t stand seeing inefficient, messy, unmaintainable spaghetti code. I understand and appreciate their frustrations.  There may be a secondary value to allowing “refactoring” to make it into release–to keep your developers happy, sane, and from leaving for greener pastures and that mythical software company where all code is documented meticulously and written as elegantly as possible.  Besides that purely secondary value, I argue that “refactoring” is not worth doing as its own feature for the following reasons:

1. It doesn’t accomplish a business goal:  The goal of a software company is to sell working software.  Refactoring doesn’t allow me to sell more software, unless there is something I need to add to the software that requires refactoring.
2. It obscures the “real” problem that is trying to be solved with refactoring:  I’m hesitant to devote an entire sprint/release to “refactoring”, because as a user I don’t know what problems that will solve for me.  If you tell me I can’t add the features in the next sprint because the code base is munged, then account for the time you have to “unmunge” (yes I just made up that word) the code into your estimate. Otherwise, what you’re doing is gold-plating and unnecessary to delivering value.
3. There is no traceability between “refactoring” and any discernible feature:  This is related to the above points, but if I can’t trace what you’re refactoring to a requirement, then it’s gold-plating.  There might be activities that a development team needs to take in order to fulfill a requirement or fix a defect (e.g., “improve page response time to 2 seconds”), but those activities should trace to a requirement.  You can’t predict every feature I’m going to ask for as a product manager, so you might be unnecessarily refactoring portions of the code base.
4. Your work might be thrown away tomorrow:  Suppose I relented and allowed the development team 3 months to refactor a messy code base, without adding new value/features.  the following month, the CTO decides to change the platform completely and start (mostly) from scratch, perhaps for good reasons.  Meanwhile, my users are stuck with a release that included worthless “refactored” code instead of some valuable features until the new version on the new platform is released.

I want to reiterate that I don’t think that refactoring should never be done, but that it should never be done in a vacuum, without any relationship to business value, solving a business problem, or satisfying a requirement.  Hopefully, there can be fewer conversations about refactoring and more conversations about how developers need time to perform some housekeeping in order to satisfy a requirement.

“Refactoring” is not a Feature is a post from: http://requirements.seilevel.com/blog

I am currently knee deep in a project to configure data mappings for healthcare ETL processes. Although there are standard formats for every exchange of healthcare information, the new core system needs some TLC to make all of the data flow correctly into and out of the system.

The best tip for managing successful data mapping is to prioritize the data first. The business stakeholders can certainly tell you which data is more critical than others. In industries with well defined data structures, this can be as simple as showing all of the data available and asking your stakeholders to rank each element (or groups of elements) with the MoSCoW rankings.

Your stakeholders may be over zealous in their rankings. That’s ok. Not everything can be a “must have” element. With a little business analysis, you can shed some light on discovering the true rankings for data. Examine the workarounds for getting the data if it isn’t mapped. How much time would it take? What would this cost?

As an example, consider a healthcare claim. There are thousands of individual data elements on a healthcare claim, but chances are your health insurance company doesn’t use each data element to adjudicate the claim. The claim data that does not impact adjudication can be ranked “could have” at best. Of the data that does impact adjudication, consider which elements take the most time to get. If the member name is missing, a claims analyst would have to call the provider who submitting the claim to find out who the member was. If this data was unmapped, they would have to call each provider and ask about each claim. This would take more hours than are available in the day. Clearly the member data, along with several others, are “must have” elements.

Data that isn’t necessary for the delivery of the product, but is still useful in other ways, is ranked “should have”. Continuing the healthcare claim example, any data that does not impact adjudication could be in this category. The company may use this data internally to analyze trends. For example, the ethnicity of a member doesn’t affect adjudication (the product that the healthcare company is offering), but it does assist in setting premium rates for members.

Once you have a sense of your data rankings, you can begin mapping. Start with your “must have” elements. After thorough testing, the business may consider going live with the mapping. After all, time is money. It could be wasteful for the “must have” data to be held hostage by the unmapped “could have” data.

By this point, the agile methodology is recognizable. Continuing with a release that addresses the “should have” data enhances the product that is already operating to address the core needs of the business. Finally, adding in the “could have” data in a subsequent releases accelerates the product for future functionality. All of these planned releases avoid the time and cost of defining, mapping, implementing, testing and releasing unneeded data.

Don’t Hold your Data Hostage! Agile Requirements for Data Maps is a post from: http://requirements.seilevel.com/blog

In the preface of his book Essential Scrum, Kenneth Rubin writes “giving a new Scrum team just The Scrum Guide and expecting good results would be like giving a new chess player a 15-page description of the rules of chess and expecting her to be able to play a reasonable game of chess after reading it.” I like this analogy as the basic rules of Scrum seem simple, but a successful Scrum project, like a good chess game, depends on the ability to use these rules in the game context. ...

We have had a lot of discussions internally about “Measuring Project Success.”  At an extremely simplistic level, Seilevel defines success as having been achieved when all the business objectives identified for the project are met. Each business objective will have one or more success metric(s) defined for it. So, when we are able to measure and evaluate each of the success metrics identified at the beginning of the project, we will have an objective measure of project success.

As we work through this process of defining project success at Seilevel, one thing stands out to me. There is no universal or “standard” way of measuring the success of an IT project. In fact, there are probably as many definitions of success as there are organizations implementing IT projects.

Below are some examples of project success statements that you may have heard before.

1. We met our business objectives. Successful project!!
2. We measured all the success metrics for each of our business objectives. All measures came in at or above our targets. Successful project!!
3. We solved the business problems we were addressing with our efforts. Successful project!!
4. We came out of testing and launched over the weekend. It has been five days since launch and no one has been fired as yet. Yay, we made it!  Successful project!!
5. The entire sales team has been using it for a week and we have not heard anything. So must be working out well, I guess. Successful project!!
6. We just finished our “Lessons Learned” meeting this morning. With that, we have hit all our project phase exit milestones. Time to move on to the next big thing. Successful project!!
7. You mean the stuff we worked on last summer? I have since worked on three new initiatives and moved on with life. Successful project!!
8. Are you trying to get me fired? I am not going to measure anything. Please leave my office immediately. Successful project!!
9. The whole team got fired. It was a disaster. This is what happens when you start measuring stuff randomly. Successful measurement.  Disastrous outcome!!
10. Did we spend all the money you had budgeted for the sales process improvement project last year? Yes? Excellent. Successful project!!

Your own organization is likely using one or more of these ‘qualifying statements’ or some variant thereof to measure project success. I would also guess there is no agreement even within the different teams in your company as to how to measure success or even bother with it.

So why does any of this matter? We have all been chugging along quite well so far without having to be held accountable for our actions in any meaningful sense so far. Why mess with a good thing?

Three reasons come to mind right off the bat to change the status quo of non-standard measures of success (for that matter, an outright indifference to even attempt to measure it in any meaningful fashion). None of these reasons are altruistic, and extremely meaningful to anyone who practices our craft or is considering it at profession.

1. Unless we can agree on some reasonable definition of project success, we can never really advance our profession in any consistent manner. If anything we do can be deemed a success or failure in some arbitrary fashion, then we are all on very dangerous ground.
2. We have no way of truly articulating the value we provide to our organizations. Unless we are perceived as practitioners of a well considered craft implementing a repeatable methodology that can deliver measurable success, we are all just glorified note takers with above-average Microsoft Office skills. This again is a very dangerous position to be in.
3. It is flat out nuts not to measure project success consistently across our organizations. Imagine for a moment if the Medical profession were organized like we are. Every doctor would be able to declare victory regardless of whether their patients actually felt better or not.  Worse yet, any patient would be free to call any doctor a quack and make it stick because they could just arbitrarily define “cured” as it related to their medical condition. We would all be outraged and demand that something be done to fix this affront to common sense immediately. Yet we have no qualms about accepting it in our own line of work quite cheerfully.

In subsequent posts, I will explore the reasons why we find ourselves in this predicament and what we can do to get out of this mess.

 

What is your experience measuring project success? Tell us in the comment section below, then check out some of Seilevel’s successes.

What Does Project Success Mean to You? is a post from: http://requirements.seilevel.com/blog

Here is our monthly selection of interesting knowledge material on programming, software testing and project management: Web site: NASA Jet Propulsion Laboratory Java Coding Standard (PDF) Web site: Guidelines for Unit Testing Python Code Web site: The Agile Atlas Article: Basing Earned Value on Technical Performance (PDF) Article: Ten Tips for Constructing an Agile Database Development Environment that Works Article: Taking on a Project in Difficulties Article: Iteration Retrospective Activity: Turn the Tables Article: QTP Best Practices Article: Dot NET Assemblies and Strong Name Signature Tools: Zucchini, a visual iOS testing framework Tools: cipra, a C++11 unit testing framework Video: How Good ...

For business analysts, a Process Flow is one of the most straight-forward models to interpret: Process Step 1 is related to Process Step 2, relating to Decision 3, which leads to either Process Step 4 or Process Step 5. Not much mystery there, right? While the flow may be easy to follow for you, there is nothing easy about structuring these flows in a way that is simple for other people to understand.
Let’s just say you have spent an hour with a subject matter expert (SME) going through all of the ins and outs of a process you want to model. You took great notes on all of the various details and have painstakingly translated each process step into its associated box, each decision into a lovely decision diamond, one connecting to the other until you have a complete model with 30 objects, boasting end-to-end coverage of the entire process. Everything seems to be right with the world, until you sit down with your SME to review your work of art and they can’t make heads or tails of the process you are describing. To them, your Process Flow looks more like a Jackson Pollock painting than the process they spent an hour describing to you. The verdict: unreviewable!

To keep this from happening to your Process Flow, keep it simple! Any given Process Flow should have approximately 7 steps (plus or minus 2); meaning, the overall amount of process steps and decisions should be limited to between 5 and 9 steps. This way, you can start out reviewing a generalized version of a process in the first level of the flow (L1) and dive into the details of a step in a separate level two (L2) Process Flow. Each L2 process step could even have its own level three (L3) process flow related to it, if necessary.  You can go down the rabbit hole as far as you want, but it makes the most sense to stop at the level of detail necessary to start pulling out your functional requirements. As we saw above, there is such a thing as too much detail!

While the L1, L2, L3 Process Flow structure sounds obvious enough, in practice, this can be really tricky to build. After struggling with this myself, I was given the following sage advice that I found really helpful: Imagine each process step as a person doing a job.

Let’s say, for example, we want to model the process a magic shop goes through to price a pair of wacky X-Ray Glasses (Hey, at least it isn’t another example based on a retail website, right?) First, we need to understand the cost associated with making these glasses (Production Costs). They aren’t selling these X-Ray specs for charity, so they can’t charge less than it costs to make the glasses. Next, they need to understand what your average-Joe magician might be willing to pay for the pleasure of seeing through walls (Demand). Are there comparable X-Ray Glasses selling elsewhere? How much demand is out there for goofy glasses? Finally, the magic shop needs to be able to determine how many pairs are currently collecting dust in the storeroom (Available Stock). If they have a bunch lying around, they had better be priced to move.

So, based on the above scenario, it is clear that the magic shop has a variety of questions associated with each aspect of the pricing process. Instead of attempting to capture every aspect of the process in a single flow, imagine each step (Production Costs, Demand, and Available Stock) as a person. Start out by imagining each step of the above three step pricing process as a person doing a specific task.

As you build your L1 flow, imagine yourself going to each person and asking for pricing information: Siegfried knows the production costs, Roy knows the amount of customer demand that’s out there, and Harry H. knows how many X-Ray Glasses are sitting around in the stockroom. This would represent your L1 process flow.

To get to the L2 process flow, imagine yourself asking Siegfried how he arrived at the production cost? He might say, “Well, the mini vacuum tubes cost 300K, the tungsten anode costs 46k, glasses frames cost 10 cents. Add them all up and you have X-Ray Glasses.” This information would constitute your L2 process flow.   If there are sub processes within the L2 flow, model them in a L3 flow, and so on, until you have a series of models that has enough detail to identify requirements.

When the time comes to sit down and review these flows and the associated requirements derived from the flows, it will be easy to step through the overall L1 flow first, and then visit each step in greater detail, using the L2 flows. Trust me; your stakeholders will thank you for not having to rely on their X-Ray Glasses to interpret your Process Flow.

 

Want more requirements development techniques? Check out Seilevel’s comprehensive list of business analysis tools online.

Modeling Tip: Make Your Process Flow Easy to Review is a post from: http://requirements.seilevel.com/blog

Karl Wiegers and I are chipping away at Software Requirements, 3E, and well over 1/2 way done! He wrote a blog post for the Microsoft Press blog about our writing and collaboration process. He describes a bit about our decision to undertake the writing effort and how it works when we live far apart in Oregon and Texas. An interesting thing if you are going to co-author – make sure you have some confidence you will be able to collaborate successfully! Simply knowing you have interest and knowledge in the same topic isn’t sufficient. You need to explore enough to ensure things like:

• your writing goals align
• your ideas align
• you have a collaboration process that works for both of you
• you are both equally committed to the project (or agree on who will do the bulk of the work if not equal)
• and…you get along, so you can enjoy the project – because you will spend a lot of time on it

In the spirit of a good BA, Karl developed a swimlane diagram for our writing and collaboration process! Check out his post on much more about co-authoring Software Requriements, 3E.

From Karl Wiegers and Microsoft Press: Co-authoring Software Requirements, 3E is a post from: http://requirements.seilevel.com/blog

Here is a list of software development related conferences and events that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine: STAREAST, April 28–May 3 2013, Orlando, USA GeeCON, May 15-18 2013, Krakow, Poland ICSE 2013, May 18-26 2013, San Francisco, USADevOps Summit Europe: Enabling DevOps, 23 May 2013, London, UK NxtGenTesting – Next Generation Testing conference, 23 May 2013, London, UK Android DevCon Spring, May 28-31 2013, Boston, USA Better Software & Agile Development Conference West, June 2-7 2013, Las ...

Have you ever written a requirement, or, more likely, business rule, that you know to be correct—but, you also know that many people will stumble over it?  This usually happens when the language in the requirement/rule is not familiar to everyone or the concept is complex.  In these situations, examples are usually more helpful than more words, such as:

1. The number must be expressed using digits (example: “7″ not “seven”).
2. A = the ceiling of B/C (examples:  ceiling of 10/3 is 4, 11/3 is 4, 12/3 is 4, and 13/3 is 5).

A colleague and I were discussing this the other day.  He pointed out that sometimes examples are trite and provide more to read/review with no real value.  I agree, don’t use them everywhere.  As a guideline: provide examples if you believe at least some of the people reading the information will sketch out their own examples to understand the requirement or rule.  Or, if you would provide an example if you were discussing the requirement/rule in person, provide it in the document.

There’s another place where examples can come in handy. Once, I was revising some requirements written by someone else.  There was a log of detail, and I understood what was being requested.  But, I didn’t understand the practical application of it.  I like abstraction, which gives flexibility.  Providing examples of how the abstract becomes concrete is useful.  In these cases, be careful no one takes the example as a limit in scope.  Perhaps you have a system that allows users to customize data entry prompts. One example would be that a person can change labels to another language.  However, this doesn’t mean changing language is the only use.  Some users may want to use different verbiage, while others may simply want to change the case of the prompt.

 

Need more help on clearly defining your requirements? Check out Seilevel’s comprehensive list of business analysis tools online.

Business Analyst Guideline for Using Examples in Requirements and Business Rules is a post from: http://requirements.seilevel.com/blog

Lately I’ve been thinking to myself, “What does it mean to be a professional?” It’s a word no doubt you’ve heard thrown around, often in a cavalier way. People take one look at another person and say, “They are not professional,” or view the actions of another and think, “A real professional wouldn’t act that way.” What, then, defines professional?

To be certain, a “professional” is someone who is qualified in a profession. That is the formal extent of the definition, but in everyday use what does that mean? Well, clearly this is tied to a profession. It follows then that every profession has their own standard of what it means to be a professional. For instance, you wouldn’t say a doctor is unprofessional because they didn’t file a brief with the court, and you wouldn’t call a lawyer out on professionalism for not scrubbing into the operating room. As a business analyst, I can’t help but wonder, “What is a professional Business Analyst?”

To help me in my quest for knowledge, I thought I’d poll my coworkers with, “In a few sentences, and in your own words, how would you describe what it is to ‘be professional’?” I had everyone give their role within the company as a context to their comments. Here are a few responses I’ve picked as a point to think things over.

 

Professionals own results and outcomes, rather than “agreeing to work for a certain number of hours at a certain rate”.  Professionals own their mistakes and fix them. – Requirements Architect

 

As business analysts we should be striving to be creating goals and objectives that are finite, measurable, and can be delivered upon. Going further than that, we should be meeting these objectives we set, and should not flounder on our accountability. In fact, accountability is an important part of any profession, regardless of if you’re a doctor, lawyer, or business analyst.

 

Do what it takes to enable our customers to succeed and achieve their stated (and unstated) objectives for a project while treating them and my coworkers with the respect, courtesy and consideration that they deserve. – Senior Product Manager

 

Follow-through and respect. Even if you’re not a consultant and don’t necessarily serve your requirements to customers, there should be a standard of excellence that is universal to all business analysts. Additionally, showing respect to coworkers and customers alike is key. It allows them to put their trust in you as a professional.

 

My perspective definitely isn’t going to be the ‘norm,’ but in my opinion professionalism is being an attentive listener, being empathetic, being honest, and caring about the customer and his/her success in a real and personal way. – Product Manager

 

To me, this comment touches on what I would call “personal” professionalism. While most people would consider the conservative, suit-clad person with a firm handshake to be the epitome of professional, I would rather place my professional trust in a person who is honest with the people they interact with, truly listen, and can create an air of understanding. Business analysts should be producing a front which communicates, “I hear you, I understand you, I will do everything to make sure you are involved.”

 

To be professional means to be competent at what you do, be reliable, respectful, and honest with others, making sure your professional life does not interfere with your work, and always look for ways you can being doing things better. – Requirements Analyst

 

This last comment, I feel, is one of the most important considerations for professionalism. Professionals should be “competent” at their profession. That is, if you are asserting yourself as a professional you should know what you’re talking about, you should know what you’re doing, and you should know where to go from here. Simply asserting that you know what you’re doing is not enough, but often people cannot tell the difference. However, if you are not being honest in your professional representation, and people figure it out, all trust in your professionalism will be lost.

In no way is this an exhaustive list of what exactly a professional business analyst should be, nor does this set out any framework to describe the professional business analyst. I think that as a profession Business Analysis may not be mature enough to garner such standards. However, these are the considerations that must take place. What would you add as a quality of a “professional” business analyst?

I would encourage you, dear reader, to open up the conversation to your fellow professionals and come to an agreement.

 

Want to work on your professional development as a BA? Visit our site for details on Seilevel’s business analyst training.

What is the professional Business Analyst? is a post from: http://requirements.seilevel.com/blog

A Feature Tree is a high-level model that allows the creator to organize features into feature groups, capturing the entire scope of a project into a single model. See how a Feature Tree model can assist you in capturing the scope of your project.

 

 

Want more tutorials? Visit our website for more Seilevel videos

Feature Tree Model is a post from: http://requirements.seilevel.com/blog

When you hear the terms “risky” and “invites failure,” do you imagine a successful project methodology?

The debate between waterfall and agile methodologies can be found in any analysts’ meeting of the minds. The linear approach of waterfall methodology runs the project in one large cycle. Agile methodology takes the project in cycles, taking time at the end of each cycle to re-evaluate priorities and keep risk low.  Dr. Winston W. Royce coined the methodology term “waterfall,” however it may have just been by accident. In the 1970 paper Managing the Development of Large Software Systems, a graphical depiction of the software lifecycle is presented. We see the flow of requirements from a top-down structure, all pooling into the testing phase.

When the testing phase of a project following the waterfall methodology is in place, it is essentially the end-all of the project cycle. If a change is necessary, the team doubles back to the requirements phase. “Either the requirements must be modified, or a substantial change in the design is required.” (Royce 2)  Relating the aforementioned term “risky” to a project in this way, a team or business might think twice about adopting this methodology.

In the field of economics and investing, risk is often mitigated by diversification. You never want to pool all of your resources into one industry, country or mutual fund. Let’s suppose you place your entire investment into the Brazilian copper industry. What happens when a small disruption occurs to your single portfolio? Risk can be a multiplier of loss- thus, any disruption (hyperinflation in Brazil or a natural disaster) will become exponentially more disastrous to your wealth. It seems obvious here that you would not want to risk all of your investment in this way. Software development methodologies are similarly applicable to the risk factor. Taking the waterfall approach is like placing all of your funds into one risky investment. A disruption, mistake or incorrect analysis may not be discovered until testing. At this point, it is too late to pull out your investment. Your schedule and/or costs will take a hit.

Dr. Royce makes this point throughout his paper. The “origin” of the waterfall method begins by illustrating the flaws within it. The latter pages of the paper outline ways to mitigate the risk of the waterfall method. Diversify your project by allowing a bilateral flow between stages. Be careful not to place all of your investment into one portfolio. Your team may be able to avoid any mistakes or changes, but why take the risk?

Risky Business is a post from: http://requirements.seilevel.com/blog