10 Ways Analysts Can Contribute to Mitigating Risk

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 reviewing the assumed boundaries of scope.  Secondly, clarify those original assumptions once the contracts are finalized and reset expectations if there were changes through change management procedures.

2. 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 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 perhaps at a later date the client may be more open to re-addressing with you.

3. 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.  You can conduct a joint planning meeting on their first day of the project and continue into the second (if necessary) with the clients while onsite 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 have a tactical approach.  The time spent planning will save overall and this is the time to flex your influence and ensure that this critical step occurs.

4. Your organization does not have a Requirements Management Plan.

Many of the things that typically are handled in Requirements Management Plan also exist in the Project Methodologies.  It is not uncommon for 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 Process

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

• Traceability of the requirements
• Requirements Communication
• Requirement Deliverables / Requirement Package

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

This could be a show-stopper if you are a BA on a Business Process Re-Engineering Project.  The current state versus to-be state business workflows are essential to that type of project.

What if you are on a project to implement a new system at a client organization?  In this case, it becomes more important to draft future state business workflows and or business use cases during your elicitation period.  Project estimations often do not account for time spent focusing on current state processes on an implementation project as this is an assumed responsibility of the client.  You can reiterate the importance of utilizing current procedural documents to ensure that nothing was missed when defining future-state documentation.

6. Business requirements have received sign-off however the requirements continue to change during the implementation phase.

Not every change request to the base-lined requirements ‘need’ to be accommodated.  Most changes need to go through a change control process which means they can be addressed at executive review meetings to identify the potential impact to the project go-live dates or success of the project.

BAs need to use a model for assessing the risk and be ready to answer risk score and drivers behind the new business requirements.

7. Stakeholders are not prepared for the elicitation session(s).

Stop the elicitation session by taking a break and have a sidebar conversation with the client’s Lead BA and PM.  You should take a quick pulse check and get agreement on how to change gears.

While it may be a disappointment that that single elicitation session was not successful. It would be far worse to continue so 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 implementation 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.

8. All product enhancement requests are ranked as “HIGH”.

If you are on a project installing or implementing software, your focus is on what the client needs now for their business to go-live with the software they are implementing. 

At times, the perceived needs by the clients are more of ‘wants’ versus ‘needs’.   If this is the case, you might be able to negotiate with the clients by holding a prioritization meeting and using certain criteria which helps they categorize those into Critical, High, Medium and Low. 

If that fails, utilize relative ranking 1 thru n. Make a recommendation for the cut-off for the Critical and High items as well as the Medium and Low.

9. You cannot obtain the buy-in to conduct 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 often become agitated if you start over and ask about their vendors or their stakeholders.

Stakeholder analysis helps to ensure you have not missed the evaluation of certain needs.  When you need to be a little covert about validating or identifying the stakeholders of the project; do so by validating the stakeholders in each elicitation session or when addressing a new business segment area. You can continue to capture the information regarding the stakeholders along the way and include it as a reference in the final requirements package for client review.

10. Resources responsible for elicitation are not communicating 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.  In this case, it is typical that there have been assigned Responsible and Accountable resources for each area of elicitation.  The Lead Analyst needs to share with them the expectations of how to communication requirements to him/her and share their 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.