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 |
|
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. |
|
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. |
|
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. |
|
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:
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. |
|
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. |
|
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] |
|
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. |
|
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. |
|
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. |
|
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.
Comments