Skip to main content

Tag: Tips

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

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. 

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

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.

  1. 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.
  1. 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.

  1. 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.

  1. 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.
  1. 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.
  1. 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.
  1.  “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 – 4th edition. 

Three Tips for Solving the Communications Dilemma

Recently I talked to a colleague with a communications dilemma. She wondered how she should communicate with her various stakeholder groups. Thinking out loud she pondered, “When I’m with business people, I always try to use business language, including their acronyms, which I’ve gone out of my way to learn. But what about when I’m talking to the technical experts? Should I talk techie to them?” She went on to say, “I write a lot of proposals. I have some stakeholders who let me know right away about typos or if my grammar is not exactly right. I have other stakeholders who have told me that my writing style is too formal and that I shouldn’t use such correct grammar. They feel it’s intimidating and unfriendly.”

As BAs and PMs we know we’re supposed to be good communicators, but what exactly does that mean? We are trained to be aware of others’ communication style. We use our intuition, empathy, and awareness of body language to “read” others. But is that enough? And does that apply equally to our written and our verbal communication? What about the language we use? I have always loved the quote from the poet William Butler Yeats, “Think like a wise [person] but communicate in the language of the people.” Does that mean, however, that when we are talking to someone who misuses the language, that we should match our language to theirs? I don’t think so. Matching the communication style does not necessarily mean mimicking their language. However, we do want a communication style that makes our stakeholders comfortable.

How can we solve this communications dilemma? Here are three tips for both written and verbal communications that can help.

  1. Take the time to keep it simple. We are all aware of the wisdom of keeping it simple, but simple doesn’t mean easy. Simple doesn’t mean careless. It is often harder to keep it simple, because keeping it simple requires thought, precision, and a good command of the language. I find that it takes a great deal of thought to write concisely and say everything I want to in language that all stakeholders will understand.
    That same principle of simplicity applies when we paraphrase, or restate what was said in different words while keeping the nature of what was said intact. I think paraphrasing is one of the most difficult skills to master. It requires the ability to take in a lot of information, to synthesize it, to concentrate on what is being said, and at the same time to rework the ideas to make them understandable. It’s tough work!
  2. Be correct without being pretentious. When we use incorrect grammar or when we don’t bother to check our work, we run the risk of being judged poorly, of reducing our credibility, and of not being taken seriously. On the other hand, when we use ornate language and complex sentence structure, we run the risk of losing our audience. I remember taking a multiple choice test in high school where the correct answer was “It is I who am going shopping.” Wow. And of course there’s the famous line from Churchill. Apparently his editors rewrote a sentence to make it grammatically correct, and apparently he responded with the famous line, “This is the sort of bloody nonsense up with which I will not put,” pointing out the ridiculous nature of obscure grammatical rules. In a nutshell, I think we should strive for communications that are both intelligent and clear.
  3. Use language that both technical and business people understand. I have found that when I use technical language with business people, they have a harder time understanding me than if I use business language with technical people. Using business language, then, tends to be more easily understood by all stakeholders. As a project manager working on software development projects, I always encouraged the developers to use business terms, even when the subject was technical in nature. For example, instead of saying DB17, I encouraged the team to talk, even among themselves, about the Price Change database.

Another example I use is that when we need to find out about data business rules, we might walk into a requirements workshop and ask about the cardinality and optionality, but we’d probably get some blank stares. However, we can translate those concepts into questions our SMEs can understand and answer. For example, we might ask if end-users can set up customers who don’t have any accounts. Or what information the end-users need to enter before they can leave the web page. I have always believed that translating technical concepts into business English, while annoying to some team members and technical whizzes, has always been worthwhile. It encourages us to focus on the business need rather than the technical solution.

Finally, let’s look at the intent of the communications. If we all understand each other and what we’re trying to say, then I believe we are communicating effectively, even if our grammar isn’t perfect or we don’t use the right words. And I believe that most stakeholders get that and won’t judge us harshly. However, for those stakeholders who want each “i” dotted, let’s proof our work. It will help build our credibility. The key is to know our stakeholders, but that’s a topic for a different day.

Don’t forget to leave your comments below!

How To Squash The Template Zombie Problem

Sept6FEATUREWestern culture worships the massacre of zombies by the dozen in movies, books, and music. Wherever we encounter zombies, whether it’s in the garden shed, the attic, the mall, or even the local if your name’s Shaun, we are taught to mow them down with whatever’s at hand.

We have only recently discovered that there are different types of zombies, and one type has invaded your office: the template zombie. There isn’t any need to panic but there’s cause for mild alarm and you should kill them. But in the nicest possible way, by feeding them sweeties.

Template zombies are BAs who just fill in the template blanks. When they’re asked to assist on a project, they immediately reach for the templates they’ve been given, fill in all the blanks and then send them on to the developers. And, let’s face it, that’s a lot of documentation to wade through and we all know developers bin the bulk of it, use a small section to write the programs and everyone’s happy. Or are they?

Companies with a poor requirements discovery competency take 39% longer and spend 49% more to deliver their projects. Nearly 80% of their projects are over budget and over time, and a whopping 50% are runaway projects. Runaway projects are those that go 180% over time, 160% over budget and deliver less than 70% of functionality.

You see, grabbing for templates and filling in blanks is akin to BAs reaching for a bag of liquorice allsorts. There’s no control over what’s in the bag, they simply get the whole package whether they like it or not.

In doing so, there’s little, if any, thought given to what the business is actually looking for. The Dryfus model (used in the IIBA Competency Model Version 3.0) for skills acquisition defines a novice as “someone who rigidly adheres to taught rules or plans and is unable to use discretionary judgement.” The template zombie has never been allowed to develop beyond being a novice, no matter how long they have been doing the job, and it’s no wonder their brain dies after a while. That’s a poor approach since the BA has a role to play in achieving a desired business outcome. If it’s properly done, the business gets a working process, be it manual or automated, but if it’s improperly executed the business gets a lame duck.

In fact, the duck can be so lame that the business has late projects, projects that cost significantly more than they were supposed to, and processes, automated or manual, that don’t meet the requirements. More specifically, developers end up with reams of documentation they don’t need that require effort and expense to create, and they ignore most of it. Poor business analysis also negatively impacts stakeholder input and user acceptance.


Bullet to the brain

So now you know how to spot the zombies: they’re the mindless template devotees. What you must now do is rob the zombies of their sustenance and turn them back into effective BAs. How? Steal their liquorice allsorts and give them pick ’n mix. Pick ’n mix allows people to choose precisely what they want; it’s the ultimate in sweet flexibility because you get a bag and then you browse the seemingly endless options, placing the type and number of confectionery delights in it that you want. It gives a much wider selection than liquorice allsorts because the latter’s a predetermined bag of goodies, while the former is an endless sea of choice that lets wave after wave of sweetie, lolly and candy choice wash over you. Again, it’s effective and that’s our watchword in taking down the zombie menace one toe-scraping carcass at a time.

Template zombies like the liquorice allsorts approach because they get the bag, eat the sweets, repeating ad infinitum. But you have to shake them up, make them think. Of course, in doing so, you need to remember that you’re dealing with zombies here and even the most docile template zombie can be dangerous. Don’t give them free rein with the pick ’n mix bag of sweeties or they’ll likely shuffle along the shelves grabbing all their favourite goodies and leaving everything else. You need to point them to the right shelves and only then release them.

Frame the zombie

While it may be ideal to leave BAs to decide what sweets they want from the entire sweet store, only the most senior BAs are capable of doing that within the greater business context, which is the task of what the Dryfus model defines as an expert. Template zombies aren’t the senior BAs. They’re the other BAs. What template zombies need is a framework to guide them through the process.

The business analysis framework must deliver value to the business, otherwise why are we doing the project? And it implies a problem scope. Not necessarily problem in the standard sense—think of it more in the mathematical sense as a problem for which there is a solution. Once we figure out what the solution is, we need to figure out how we are going to deliver it. Think of it as three layers of a pyramid: at the top we ask a) why are we doing this project, followed by b) what do we need to do, and finally c) how do we deliver the solution?

When we ask why we are investigating the business objectives or goals, when we ask what we are eliciting the business requirements, and when we ask how we’re looking into the functional and non-functional requirements. 

Another way of looking at it is when we ask why we are seeking the value of the project, when we ask what we are investigating the entities, processes and business rules, and when we ask how we are looking at the required solution functionality. The framework gives us a matrix of objectives on one axis, and tasks or techniques on another, all culminating in outcomes and deliverables. It’s that matrix that arms BAs to choose which techniques are best suited to their projects. All BAs are armed with a bag of sweeties they can dip into, containing practices and disciplines such as planning, business case, business requirements, functional requirements, non-functional requirements, transitional requirements, solution validation, elicitation, and requirements communication. Within each of those portions of the matrix are tools that BAs can use to help them achieve their goal and that’s their pick ’n mix. They’re given the matrix, the framework, but they get to choose within the framework because that’s where they’re the domain experts. For example, they may choose more common tools such as process analysis, ERD, use case and others. But there are several methods of analysis, such as PESTLE, heptalysis (which is not a gum disease), MOST, SWOT, CATWOE (which is not a sad cat), De Bono’s Six Thinking Hats, Five Whys, MoSCoW, and others in their bag of sweets.

Powwow

But what are they looking for in selecting these techniques or sweeties? Some time ago I attended a presentation by Scott Ambler, who is an Agile guru. Often at a conference or industry powwow, there’s a pearl of wisdom that leaps out and sticks in your brain. For me it was, “We need repeatable results, not repeatable processes.” Pick the right tool for the job.

It requires some thought from BAs in the context of the business while considering the numerous techniques available before ensuring a suitable match. Handing BAs a bag of liquorice allsorts in which they’ll find a predetermined collection of techniques that they must follow because “that’s the way we’ve always done it” doesn’t cut it—that is just a repeatable process. You need to appropriately select the techniques that will most effectively deliver against the requirements in the context of the business objectives for repeatable results.

Don’t forget to leave your comments below.


Robin Grace is a Business Analyst Principal Consultant at IndigoCube.


10 Tips to Working Without the Essential Inputs

FeatureAug9It can be trying to read about what as a business analyst you should have as inputs to begin BA activities when you don’t have those materials but are still actively working.  Business analysts who are responsible for product installation and software implementations at client sites do not always receive the necessary information they need as inputs to their processes.  In addition, not every organization is supportive about providing input materials to begin business analyst activities.  Still, projects kick-off and resources are assigned and business analysts and project teams get to work.  What should a BA do when placed in this situation?   

Below, I will share 10 tips to help guide BAs mitigate requirement risks when faced with some of the most common business scenarios where they do not have the essential input information.

Business situation

What you can do
  1. The contract is not finalized so the scope is still not defined.

After the formal project kick-off, start off the requirements project by reviewing the assumed boundaries of scope.  Secondly, clarify those original assumptions once the contracts are finalized and reset expectations if there were changes.

  1. The project charter is not shared with the consulting BA team.

Project SMART goals can still be established through means of elicitation either before the kick-off or during the first week of elicitation.  This is as important as the scope to understand how the project success will be measured and it should not be skipped.   Even if the goals are not SMART and measurable, obtain as much information as you can and include it in your discovery notes and documentation, and perhaps at a later date the client may be more open to re-addressing with you.

  1. Requirements planning cannot be conducted prior to a formal project kick-off.

When the pressure is on to begin a project immediately after a contract signature and the time is not given for proper requirements planning, you can roll requirements planning into the project itself.Requirements planning still needs to occur and must happen in a joint fashion with the clients.  You can conduct a joint planning meeting on the first day of the project and continue into the second (if necessary) with the clients while on-site prior to any elicitation activities.This is a very important activity that can save time and iterations of unnecessary elicitation sessions by having the joint teams ready for each session and taking a tactical approach.  The time spent planning will save time overall and will allow you to flex your influence and ensure that this critical step occurs.If your company does not have a standard tactical approach for the planning of your projects, save your plans, take out the client references and begin to build your standard plan for re-use on other projects.

  1. Your company does not have a requirements management plan.
Many of the things that are typically handled in a requirements management plan also exist in the project methodologies.  It is not uncommon for a service organization to default to utilizing project management planning or methodology to cover areas such as:

  • Project communication plans
  • Conflict and issue management
  • Identifying project deliverables
  • Sign-off procedures for project deliverables
  • Change control processes

What you will need to work out with the PM and the team is a smaller requirements management  plan for:

  • Traceability of the requirements
  • The streamlining of every BA’s notes to requirements in a single format

Again, if your company does not have a standard tactical approach for the management of the requirements activity during the project, save your plan, take out the client references and begin to build your small requirements management plan for re-use on other projects.

  1. The current state documentation or the business workflows are not always made available.

You can be working with a client who refuses to give you the information or you can be working with a client who doesn’t have it documented.  The outcome is the same regardless—you don’t have an idea of what they do today as a business model.When implementing a new system, it becomes very important to draft future state business workflows and/or business use cases during your elicitation period.  Remember to validate those business workflows by conducting brief system mock-ups and creating high-level scenarios for which the client will validate whether the workflow is accurate.  These workflows can then be used as a baseline going forward.  Obtain the client signature by including these in the requirements package for sign-off.Project estimations often do not account for time spent focusing on current state processes so you really need to discuss with the project manager.  Ultimately, you can request a change order to the current project or call this out as a potential project risk.

  1. Your client signs off on business requirements and continues to change requirements during implementation.

You will need to work with your project manager to enforce the change control process for the project.  Assess the root cause for the new business requirements and address them at executive review meetings to identify the potential impact to the project go-live dates or success of the project.Not every change needs to be accommodated so you really need to focus on those prioritized the highest.  Use the simplest model for assessing the risk.  What is the risk of not accommodating a requirement and is it an obscure area of the company or one that’s widely utilized in all business areas? [Risk = Impact * Rate of occurrence]

  1. Your client is not prepared for the elicitation session(s).

You should stop the elicitation session while it’s in progress and change the plan.  No one wants their time wasted in sessions that do not serve a purpose.  Bring this issue up at project risk meetings as a requirements risk and something you need mitigation planning around. It’s better to spend time planning the sessions, prepping the attendees and marking out the information that is required to be brought to the meeting versus continuing on and getting only some of the information. Lastly, remember that most projects do not have the budget to continue iterative rounds of elicitation sessions.  This can be the main reason for overages in requirements projects.  You must avoid this situation and assist with mitigating it if it occurs.

  1. Your client continues to identify product enhancements and rank them all as “HIGH”.

If you are on a project installing or implementing software, your focus is on what the client need now for their business to go live with the software they are implementing.  Sometimes, the perceived needs by the clients are more of ‘wants’ versus ‘needs’ .   If this is the case, you might be able to negotiate with a client by holding a prioritization meeting and using certain criteria to help them categorize items as Critical, High, Medium and Low.Also, at times the perceived critical or high needs of the end users are not enough to stop the overarching project goals.  If your client insists that you submit enhancements as Critical or High for go-live, as a BA you should take those needs and prioritize and rank them.  If the ranking still seems incorrect to you, you may need to work with the project manager to bring those project needs forward to the executive steering committee overseeing the project for final project determination.

  1. Clients are not interested in participating in formal stakeholder analysis.

If the client has been a long-standing customer, they expect that their partnered IT solution company understand who they are and what they do.  They may become agitated if you start over and ask about their vendors or their stakeholders. I do not recommend that stakeholder analysis occur on every project with clients like this. During IT projects, especially upgrades for which stakeholder analysis happens internally within the organization, some clients are not open to this concept and so it’s best to assess the client’s openness and expectation of how well you know them already.  When you need to be a little covert about identifying the stakeholders of the project, do so by validating the stakeholders that you know of in each elicitation session or when addressing a new business segment area.You can continue to capture the stakeholders along the way and include them as a reference in the final requirements package for client review.

  1. You had a team of people assisting with elicitation and they have not provided you with the requirements.
During projects that hold parallel paths of elicitation, it is not always feasible for the lead business analyst to be in all of the sessions. It is typical that there are responsible and accountable resources for each area of elicitation, and the lead analyst needs to share with them the management plan on how to communicate requirements.  Request the documentation and give the deadline for the information.If resources continue to not provide their information, the business analyst needs to communicate the expectation of the documented requirements by a stated date and copy their resource managers along with the project manager.  Not obtaining the necessary team requirements internally can jeopardize the requirements documentation and should be escalated as a project risk if it continues to be an issue during the project.

When it comes to working without the necessary inputs, it requires business analysts to get creative and find alternate ways to get the information.  Take a lesson from the 1840 short poem “If at first you don’t success, try and try again.”  Input materials do not always come to you in a nice package, nor do they come exactly when you need them.  

Business analysts really need to have constant communication with project managers during a requirements project on what they need and what they recommend for the success of the project.  When a project manager and a business analyst work together on project and requirement risk, project and business scope, and project time, budget, hours versus project needs, projects roll out with a higher likelihood of success both in terms of budget and met business objectives.

Don’t forget to leave your comments below.


Maryanne Miller, CBAP, Business Services for MEDecision, Inc., has over 15+ years of business and technical experience in the corporate world of health care IT services. As a professional consultant providing business and technology leadership, her areas of experience include business process improvement, business analysis and health care IT.