Tag: Best Practices

Three Tips for Solving the Communications Dilemma

Written by Elizabeth Larson on October 4, 2011. Posted in Articles. 2 Comments on 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.

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

Solve it with Science

Written by Neil Karan on September 20, 2011. Posted in Articles.

Remember those days in elementary school science class when the teacher would stand up in front of everyone and ask a question that required solving? The question was always designed to get the neurons in our brains firing, and begin brainstorming solutions to the problem. During those brainstorming sessions we’d eventually develop a problem statement or hypothesis, which was synonymously referred to as a hunch amongst the kids in class. Whether we realized it or not, our hunch or problem statement would become the foundation of our problem-solving process; the postulation as to why we felt the subject matter in question was occurring, and the possible causation.

Eventually we’d start going through the motions of testing our hypothesis; identifying our manipulated and controlled variables in hopes that it would provide us with a responding variable that would confirm our hunch. If at the end of our experiments we found that our theory wasn’t supported, then we’d develop a new hypothesis and start the process again.

So with that said, couldn’t a simplistic view of solving problems the way we used to when we were kids be applied to our problems today? The use of this basic method of theorizing and experimenting can become an intricate tool in solving problems that plague or hinder the success of a project.

This article is designed to remind and re-engage you in a thought process that was taught to us at a young age and that can help you tackle the problems impacting your project today. What this article is not designed to be is an exercise in technical jargon or buzzwords, but one focused more on the utilization of simple logic when trying to figure out the root cause of an issue.

No matter what the issue is, a similar thought process should be running through all our minds when identifying and responding to a problem:

Figure 1

A. Identify the Issues

Begin by understanding what problems have been plaguing the project (e.g., a lack of project charter, poor team member participation, etc.). A suggested approach is to go through the original plan for the project and perform a gap analysis of where things should be versus where they are today. As a member of the team, or as project manager (“PM”), you should have a good idea of what’s been slowing down the project. Consideration should also be given to collaborative discussions with the team that could also bring to surface issues that may not be apparent to all members or the PM but could have a material impact on the success of the project.

Once you’ve gone through and listed potential problems, the next suggested step is to risk rank each issue to determine their importance and resolution priority.

B. Prioritize the Issues

To determine which issues to tackle first, the suggested approach is to risk rank each issue and prioritize each based on complexity and impact. In this context, complexity can be viewed from many perspectives. But to provide simplicity and ease of thought, consider viewing it from a component standpoint (e.g., how many information inputs and outputs are impacted by the problem, how many parties or business units are impacted, etc.). For example, compare the following three issues:

Complexity:

Comparing each issue, it’s easy to identify that issue A is more complex than issue C, involves a greater degree of effort to resolve, and impacts more business units and information outputs than issue C.

Now that we have a basic understanding of complexity, let’s move on to the impact component of the risk ranking exercise.

Impact can be interpreted as the level of damage the issue can cause if it goes unresolved. The damage, for all intents and purposes, is most easily understood when quantified in terms of time required for completion and effort expended; this understanding translates nicely with project timelines and helps provide clarity when the project and identified issues are monetized to the project sponsor. Consider the same issues above, but this time with impact as the risk consideration:

Impact:

With an understanding of complexity and impact, the final step is to map each against a risk grid. The grid visualizes where your issues rank and helps to vet which issues should be tackled first, from highest to lowest risk. A typical grid that could be used is as follows:

Figure 2

Risk Ranking		Complexity
Risk Ranking		Low	Medium	High
Impact	Low	Low	Low	Medium
	Medium	Low	Medium	High
	High	Medium	High	High

Using the grid above, you should now be able to generate a list of issues that are prioritized based on the level of complexity and the overall impact they can have if left unresolved.

C. Figure out the Root Cause of the Problem

Now that you know which issues require immediate attention, the next step is to postulate the cause of the problem, because understanding why the problem is occurring or has occurred will be the only way to develop insight into developing a solution. For example, if the top-ranked risk for your project is that team members no longer attend project meetings, the first step is to develop a hypothesis as to why this may be occurring. The key of the hypothesis is stating the effect and the proposed cause that requires confirmation through experimentation, whether it is confirmed empirically or simply with reasons jotted down on a bar napkin. If, through your hypothesis and experimentation, you determine that no one is attending the meetings (effect) because food isn’t provided to attendees (cause), you can now move towards resolving the issue (i.e., provide food at meetings). The simplicity of the example may seem a bit ridiculous, but you’ll be surprised as to the simple cause of some of the problems impacting your projects.

D. Implement the Solution

The final step when trying to resolve issues is to implement the solution developed during the root cause analysis process. It’s during this time that you’ll be able to tell whether the hypothesized solution will in fact work (i.e., does providing food at meetings actually result in more people attending?). If during this process and the post-implementation of the solution there exists a gap between what is expected versus what actually results, there may be a need to reinitiate the problem-solving process (i.e., repeat step C.)

If the problem is large or complex enough with multiple variables, the above process can become quite extensive but the baseline principles will still hold the same.

To summarize, thoughtful thinking throughout the problem-solving process is essential to the success of resolving issues in a timely and effective manner. It’s important to be cognizant of your actions and activities throughout a project. Emphasizing a greater effort in planning with a preventative mindset in place aims to ensure that problems won’t arise due to a lack of project charter, multiple project sponsors, etc. If, unfortunately, you are experiencing problems with the project, barring any unusual or extreme circumstances, consider the steps above to help devise a simple and methodical strategy for resolving issues threatening your projects completion.

Don’t forget to leave your comments below.

Neil Karan, CFE, CISA is an experienced financial process and IT auditor who provides direction and guidance for audit and project programs. His areas of expertise include business process effectiveness and efficiency programs, operational process design and financial/IT integrity audits.

How To Squash The Template Zombie Problem

Written by Robin Grace on September 6, 2011. Posted in Articles.

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

Implementing Change

Written by Catherine Perks on August 8, 2011. Posted in Articles. 2 Comments on Implementing Change

Evolution is key to the survival of any species. This isn’t a revolutionary concept; it has been around since man moved from eating raw meat to finding his first source of heat and energy. In business, the same is true. Those still using caveman techniques in a world evolving around them are likely to become extinct like the dodo.

There is clearly a need to constantly adapt, to realize that if one approach doesn’t work that it isn’t the end but rather the beginning. There is a need to recognize that you do not know all the answers, but collectively, those around you may. This ability to adapt, to change tack at will and collaborate with others is what distinguishes the business analyst profession.

I have sat in many meetings listening to stakeholders who are convinced beyond a shadow of a doubt that their approach is right, that what they have been doing for the last 10, 20 or 50 years is right. That no outsider could, or should, tell them otherwise or even propose that another way is feasible or better. I have also sat in meetings where the stakeholders love the new approach, some even raving about it, while their ash-faced colleagues look on, knowing full well the work required of them and the difficulty involved in implementing such a change. The change-experienced business analyst is willing to assist them through this process, and help both the stakeholders and the users adjust to (and even celebrate) the change.

Yes, business analysts are great at changing, at adapting. We can go into an industry, ranging from publishing to banking, airline industries to petroleum, adapting our approach to the content as necessary.

What we business analysts often forget is that our clients and stakeholders are not always ready for such change, especially in the timelines expected of them.

“Change management” is becoming more and more of a buzzword. The adoption of a word by industries somehow seems to devalue its meaning, perhaps as a result of its frequency of use, or use in the wrong contexts. Whatever the reason, phrases like “synergy,” “business model” and “thinking outside of the box” all end their days unappreciated, undervalued and disused in the cemetery of boardroom blabber. And if they haven’t yet, they should.

A project is only as successful as the change embedded by it. A solution that meets 80% of requirements but is 100% embedded is by far a better outcome than a solution that meets 100% of requirements but is only 20% embedded. Implementing change in small to medium organizations or multinational conglomerates should be pursued with the same amount of vigour, conviction and creativity.

Asking people to change the way they function is no easy task, nor should it be viewed as such. The scale may change, but ultimately people are reluctant to change, particularly when they do not see anything wrong with their approach. Often, they will simply ask why? Unfortunately, this is a question that remains unanswered in most failed change management attempts.

Based on my interactions with change management, there are 6 key concepts that should be kept in mind:

Answer the unspoken question first: “Why is this change being made?”
Ensure that everyone is reassured, e.g., “This change is not being made as a result of you, but rather to improve our overall approach.”
Remember that not everyone enjoys change. Make sure the approach taken is creative, innovative and engages all stakeholders. As a business analyst on the ground and interacting with a variety of different stakeholders from different sections of the business, your role may be more important than you realize.
Involve as many formal and informal influencers as possible. Observe team/group interactions: there will be indicators of who to engage with.
People will often only do what they are measured on, so to ensure a sustainable change is created, it is important to introduce reasonable measures reflecting target behaviours.
Be patient and communicate. The change cannot be implemented or accepted overnight. Implement regular reminders of why the change is being made, and why each individual involvement is crucial.

Change and the management thereof is a key part of evolution, and without it we will stagnate. Without sufficient change management, people will covertly continue to do as they have always done, or will accept the change with barely contained contempt. Remember, unless shown otherwise, people will prefer to do things as they’ve always done. After all, “why fix it if it’s not broken?”

Don’t forget to leave your comments below.

Catherine Perks is a London-based business analyst working for BSG (UK). She looks at what make a solution work, including the technical and interpersonal effects of implementing the solution.

10 Tips to Working Without the Essential Inputs

Written by Maryanne Miller on August 8, 2011. Posted in Articles.

It 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
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.
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.
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.
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.
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.
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]
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.
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.
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.
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.