Tag: Best Practices

Requirements for the App – Tips and Tricks for the iPad World

Written by Remzil Kulkarni on March 19, 2012. Posted in Articles.

Tablets are omnipotent these days. They have revolutionized the way we do a lot of things. App developers are in high demand and businesses with a product are jumping over themselves trying to get ahead in the game by establishing a presence through offering an app. The recent slew of customers that approached us for requirements related to an app offering got me thinking of how doing requirements engineering for an app is different from a regular product and what key things you should bear in mind as you develop your app.

It’s all about the look

What makes an app on a table device cool is that the graphics are slick and somehow makes the person using the app feel tech-savvy in the process. Like it or not, the “cool” factor for a user interface is one of the things any app is rated on. My advice is to not take this area lightly, but rather to invest in user design experts whose work you have access to and appreciate. Ensure the process is creative and collaborative.

Tip: In order to contribute as a BA, explore various leading apps in the same domain or targeted at a similar audience in order to find out what you like, what’s popular and what suits your app perfectly.

The sense of touch

Tablets are typically devices with touch screens, so your app will have to respond to touch events well. This can open up an entirely new dimension of engaging with the user. The level of satisfaction a user derives from a well-performed task in response to an intuitive action can be very high and almost addictive, and can encourage usage of the device and app frequently. Innovation can be key in this area as well – the iPad started a revolution simply by tapping the potential of this aspect of interaction with the user.

Tip: Mimic the actions you would perform where applicable. For example, flipping a whiteboard to get to the next page, or for a charting tool, pulling a pie slice out to see what the rest of the chart looks like without it. Then, ensure your user interface responds to such motions.

Give something back quickly

While we are using tablets more and more for certain tasks, not everything has changed. Recent surveys of tablet usage [1] show that while we use tablets more for tasks such as listening to music, downloading, maps and information when we’re on the go, we continue to prefer our desktops for activities that require extended periods of attention. A lot of work therefore continues to happen on desktops and laptops. Given this nature of usage, a good principle to follow is to give something back to the user quickly.

Trick: If your app is helping someone plan their finances, make realistic assumptions based on some key data to show them projections quickly in order to demonstrate the capability and value of your app. Then give them the opportunity to fine-tune the accuracy of projections by entering their data for better results. Once users can see what your app can do, they will take the time to enter data as they know what they will get in return.

Scope

Organizations are rushing frantically to put an app version of their product “out there” and establish a presence in the mobile space. But the problem is that when you have an existing product or solution, you can’t really take it in its entirety and “app it.” You typically should consider reusing components and bear in mind the overall goal of the solution, but feel free to make the app different where it needs to be in order to fall in the category of a well-thought of and useful app.

Tip: A good exercise to carry out is to study the scope of the existing solution that’s available and prioritize what is necessary and what can be forfeited. Your app should have functionality that’s absolutely vital but can leave out the bits and bobs that are incidental.

Keep your app light

Keep your app light. Reuse components from an existing app by making them available as online services. Avoid unnecessary data capture. However, if your app needs to function as a standalone app, balance the need to keep it light with its need to be functional in a disconnected mode.

Tip: Explore non-functional requirements related to app development to ensure all aspects of the app are covered.

Be aware of app guidelines

Lastly, be aware of the limitations and guidelines for your app. While most leading target operating systems (Android, Blackberry, Nokia’s Symbian operating system) don’t proactively publish guidelines before putting an app on their store, Apple has stringent guideline [2] and your app will have to go through a two-week approval process before it is made available on the App Store. However, even for apps targeted at operating systems other than iOS, the guidelines on Apple’s website are a great read to help you develop a good app.

Trick: Go through the guidelines on the Apple website for pointers on your app.

Conclusion

With all of that said, requirements for apps are exciting and a brilliant learning opportunity. The aspects I’ve put forward in this article are an excellent starting point but there’s lots to discover along the way. I wish you all the very best for putting together your app – happy discovering!

Don’t forget to leave your comments below.

[1] BusinessInsider.com, TechRadar.com
[2] Apple app guidelines can be found at https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html

Remzil Kulkarni has over 15 years of experience in technology enabled business transformation focused on Insurance, Telecom and Finance. She has a Masters degree in Engineering Management from Southern Methodist University, Dallas TX and is President of the IIBA Pune Chapter. She is a certified Prince2TM Practitioner and a Fellow of LOMA (FLMI). She currently heads the Business Analysis Centre of Excellence at Mastek Ltd., where she has worked for the last 6 years.

Meet Your Business Analysis Influencer

Written by Kupe Kupersmith on March 6, 2012. Posted in Articles. 1 Comment on Meet Your Business Analysis Influencer

My goal in life is to meet everyone in the world. I know that goal is not SMART (specific, realistic, etc.). It is not reaching the goal that is important; it is the effort I go through to try and meet the goal that counts. The goal goes deeper than just “meeting” people. I try to meet everyone I can and establish a relationship. Building strong relationships is a constant, consistent goal of mine. Some grow deeper than others, but I don’t discriminate. I meet and engage with people sometimes without knowing how I will add value to that person or how they will add value to me. For some this is a hard concept to grasp. Some feel so busy and can’t fathom spending time getting to know someone new without knowing why you should get to know them.
We work in a highly collaborative work environment. You don’t have to do everything on your own. If you build strong relationship people are more willing to help you. So if you are too busy to build relationships it is because you are not building relationships.

If you still need some convincing regarding building relationships, here is one big reason you should bother. Build relationships to ensure your message is delivered. This thought popped into my head after seeing an interview with Bono, lead singer of U2. He is a huge advocate to reduce or eliminate the AIDS virus. He has helped raise money and awareness that is dramatically helping the cause. But Bono is not a doctor. He does not work for the Center of Disease Control. He is not trained to do the research, administer tests or provide medicine to patients. What he does do is use his influence to help raise money to support the cause. He uses his influence to convince lawmakers they should allocate funds and resources to support the cause. He delivers the message.

I speak with many BA professionals that get frustrated when they can’t convince their management that they need more focus on the BA practice. I speak with many BA professionals that realize projects are not going well, but are not sure how to get their message to the right person. Sometimes you don’t have the influence necessary to get your message across. Does that mean you should stop? Of course not. You need to detach the message from the delivery of the message. The point is not who delivers the message; the point is that the message gets delivered.

Most likely Bono won’t be stopping by your office anytime soon trying to convince your management that they need to fund your effort to start a Business Analysis Community of Practice. Go out and meet some new people in your company at all levels. Who knows, maybe they’ll be delivering a message for you.

Don’t forget to leave your comments below.

The Business Analyst: When Not Knowing the Answer is OK

Written by Josh Jones on March 5, 2012. Posted in Articles. 1 Comment on The Business Analyst: When Not Knowing the Answer is OK

A new project has spun up and you’ve been assigned as the Business Analyst (the same scenario outlined below could happen if you are added to a project that was already in flight). You’ve done your diligence preparing; you’ve read the scope, reviewed the charter document and called your first requirements gathering meeting with the business partners and IT representatives. Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME is talking about!

Though your notes are word-for-word with what the business SME is saying, they might as well be a foreign language that you don’t speak. The fear of looking foolish or not wanting to lose creditability in the eyes of the project team, you do your best to keep writing while desperately trying to grasp the concepts that the SME is laying out in front of you. When first assigned to a project, this is where most BAs get tripped up.

In my experience (ten years in the BA and PM space), I’ve been there many times. And it wasn’t until a few years ago that I finally figured out how to handle the situation described above successfully. No matter how seasoned of a Business Analyst you are, a situation like the one above will happen. It’s inevitable. It’s very rare for a BA — no matter how much experience they have — to start every project with knowledge that will allow them to know what’s going on at all times for all scenarios.

The hardest parts of when you don’t know the answer is 1) trying not to look dumb in the eyes of fellow project team members 2) knowing how to make sense of what is being said and 3) being able to take the information given to you — at a time when it makes no sense whatsoever — and produce relevant (and accurate!) requirements.

There are four simple tricks you can use to get you out of the jam of not knowing the subject matter yet still get something out of the meeting.

· First, use your “Veil of Unfamiliarity.” As a contracting BA, I have many clients. And most of the time, when I work with a client, I know very little about the interworkings of their internal process, knowledge workflow and system-to-system linkage. But that doesn’t stop me from quickly picking up the things I don’t know. When I find myself new to a client, I often stand behind my “veil of unfamiliarity.” What I mean is even though you have all the best analysis skillsets in your toolbox, they are useless unless you know how to use them on a project. When I find myself on a brand new project that I know very little about, I will often say (out loud), “Since I’m new to this subject matter, I’m going to step behind my veil of unfamiliarity for a moment, could you explain that in more detail?” This is similar to asking the client, “Would you mind putting what you just said into easier-to-understand terms/language?” The reason you want to use your veil is so you can understand the unfamiliar topic at a higher level (less detail) before later diving into the weeds of that particular process flow or UI functionality or whatever it is that you’re trying to understand. In other words, you are openly admitting that you aren’t familiar with the details of the subject matter…yet. Being open and honest by asking the client to make the topic easier for you to understand will further strengthen that trust relationship with the project team and business partners. Using your “Veil of Unfamiliarity” is another way of saying, “I don’t know what you’re talking about yet, but I will soon,” all the while saving face (protecting your integrity) with the project team.

· Second, look for action items — even if they aren’t for the BA — and insert yourself into them (when it makes sense, of course). Another trick I’ve found to work well is to associate myself to follow-up action items that come out of a meeting even if they don’t directly involve me. Take the opportunity early in a new project to absorb and learn as much as you possibly can. It doesn’t matter where the source is either; just immerse yourself in anything topical to the project. Of course, it goes without saying that you should take care of your BA responsibilities first, but if you have the chance to sit in on a meeting with IT as they review a design document or sit with the business partners as they figure out how they want to incorporate their needs into deliverables, do it. Even though some of the action items aren’t directly tied to your BA work on the project, you’ll be building that background knowledge that will come in handy later on in the project.

· Next, create a partnership with the Business SME (or wherever the knowledge is). While it’s always important for the BA to have a healthy partnership with the Project Manager, it’s just as important to have a healthy, open partnership with the Business SME. After all, they are the ones whose needs must be met by the project. More often than not, this relationship is overlooked, not in place or undervalued, and can lead to limited — or in worst cases broken communication — between you (the BA) and them (the owner’s for the needs/business requirements). If you want to be successful in the BA space, you must value the partnership with the business SME. It will be so much easier to get vital information quickly when the partnership with the Business SME is healthy, strong and open.

· Lastly, and probably the hardest trick of all, is to be humble and ask. This is the simplest trick to grasp, but also the hardest to actually do. If you are like me at the start of a new project, you’re cautious of exposing your proverbial underbelly to a new project team. By that, I mean you’re hesitant to let your colleagues know that you have a vulnerability around fully understanding the subject at hand right out of the gate. However, if you don’t speak up now (at the beginning of when you start a project), it’s too late. Because the role of the BA is so vital to the overall success of a project, you should never pass up the opportunity in the beginning to ask the business SME — or anyone else on the project team for that matter — to clarify their comments if you do not understand them. It could be comments about scope, business needs, requirements, functional specs or anything project related. The point is, it doesn’t matter what the topic is: if you aren’t crystal clear with your (the BA’s) understanding, ask them to clarify their statement(s). More often than not, the requirements phase of a project moves at light speeds, so it’s important to level-set expectations of understanding the subject matter early and often in order to avoid getting left in the dust. And if you’re worried about losing creditability in the beginning of a project for not knowing the subject in detail, just imagine how much creditability you’ll lose when you get three weeks into requirements gathering sessions and you still don’t know what’s going on. Trust me, I’ve seen it happen and it’s not pretty! In the end, the business SME — or whoever is providing the clarity — would rather provide more clarity on a topic that you asked about than find out you (the BA) did not fully understand it.

Too often, I’ve seen good business analysts lose credibility with a project team because they aren’t willing to admit that they don’t know something. Fearing they will be ridiculed, the BA will play along like they know the subject matter, but when it comes down to crunch time on a project and they aren’t as well versed in something they’ve said they are, then that is when the requirements are at risk of being incomplete, or worse, incorrect. It doesn’t have to be that way! The next time you find yourself sitting in a project meeting or requirements gathering session and you don’t know the answer to a question or don’t know how a business process works, try using one of the tips in this article to assist you with gaining a better, clearer understanding of the subject. In the end, you will thank yourself for being bold enough to put aside your fear of losing credibility and doing what it takes to have a clear, concise understanding of the topic at hand. By doing that, you will have put yourself in the position to produce solid, real and most importantly, accurate requirements.

Don’t forget to leave your comments below.

Josh Jones is a seasoned BA with over 9 years of experience in the BA and PM space. Josh has successfully applied project and analysis leadership expertise to deliver project initiatives in a wide variety of industries (including product fulfillment and distribution, insurance, broker dealer management, Life and Annuities products, information technology, network services, financial services, investment/retirement products, and agriculture).

As a mentor and BA coach, Josh’s hands-on, “create a solid partnership” approach blends his desire to share his business analysis expertise with his passion for helping others improve.

The Business Analyst Commandments

Written by Tim Ward on January 24, 2012. Posted in Articles. 1 Comment on The Business Analyst Commandments

Eliminate ambiguity. If you can arrive at more than one understanding or conclusion, chances are so can a developer or tester.
When using terminology, don’t assume everyone has the same understanding. Get immediate confirmation to avoid misunderstandings. A glossary of terms and related aliases are very helpful.
Promote “plainspeak”, the use of common (English) language when describing business facts, rules, regulations, processes, data, etc. If it is necessary to document something in business or IT jargon then paraphrase its true meaning in plain English.
When business or IT terms are used to describe something, always confirm the definition (e.g., when we say “transfer” we mean …).
Don’t ask for permission, ask for forgiveness.
Understand cultural differences within or between business organization entities and IT. It will help in following other commandments.
Requirements should describe what something isn’t as well as what it is.
When eliciting requirements, ask clarifying questions to confirm the requirements are being clearly captured.
When eliciting requirements, it is important to identify the audience affected (e.g., line of business, products, plan types, etc.).
When documenting requirements, decisions or issue resolutions, it is equally important to document the “why” as much as the “who”, “what”, “when”, “where” and “how”. If you don’t, it is more likely that no one will remember later why we went down a certain path.
When defining requirements, remember that it has to be testable. If you can’t adequately test it then the requirement is not adequately defined.
There are no assumptions, only a current understanding of the facts. Use of assumptions only promotes growth of undesirable anatomical features.
When writing (or speaking), put yourself in the reader’s (or listener’s) shoes. Would they really understand what I’m trying to convey based solely on the words I’ve written or spoken? Is there an unrealized expectation that they audience has some level of implicit knowledge in order to understand the subject matter?
Treat your developers and technical support staff as you would like to be treated: as a trusted ally and good friend.
Understand that people requiring your services as a BA don’t always know what they want and/or are unable to effectively articulate their needs. That’s why God invented BAs.
As a trusted subject matter expert, people will usually believe what you say as fact, especially if you are good at clear communication. Being in this position of trust, there is an inherent risk that sometimes you may be wrong in your understanding (and are unaware[RC1] ). However, you are persuasive enough to convince everyone of this truth. You need to rely on others to be able to detect the conveyance of false truths before it’s too late.

Don’t forget to leave your comments below

Tim Ward is a Business Analyst with over 30 years of experience in the financial services market dealing with group retirement plans. He is also a member of the IIBA and received his CBAP certification in 2009.

7 Trends in Business Analysis and Project Management to Watch for in 2012

Written by Elizabeth Larson on January 10, 2012. Posted in Articles.

The close of one year tends to make one reflect on what has occurred in the past year related to and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:
1. Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
2. Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
3. PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.
The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:
1. Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
2. Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
3. In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:
1. Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
2. Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
3. Post-project follow-up. We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.
1. Travel budgets. Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
2. Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
3. Collaboration tools have made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

“The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

Don’t forget to leave your comments below.

Elizabeth Larson and Richard Larson are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills.

They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4^th edition.