Skip to main content

Author: Maryanne Miller

Do it Yourself Guide for Building Templates

Aug23rd_FEATUREWhen the requirements document templates that you have to use within an organization do not fit the situation, you should consider making a new template. There will be organizational procedures that you will need to follow but it is possible to request new templates for your project needs if you believe it provides a higher-quality deliverable.  Senior analysts can recognize such opportunities when they arise and have the skill set to create new formatting for requirements deliverables.  Less experienced analysts rarely think of building new templates but what you need to remember is that someone built that template from scratch so it’s not impossible or even a real obstacle. Rather, it could be the next building block to increasing your skills. 

When standard procedures and processes, templates or job aides do not give you what you need to be successful, managers expect business analysts to utilize their expertise and create what they need for projects.  Three common mistakes that business analysts can easily avoid are:

1) Refraining from using excuses such as “the pre-set templates are all I have to work with.”

2) Assuming you are not empowered to improve processes or expand the tools of your trade.

3) Listening to more experienced peers insist that their template fits every business situation.

     You need to first agree that there is not a one-size-fits-all requirements template document.  If you don’t believe this is the case then compare a requirements document designed for product development to a requirements document for a services organization responsible for product implementations.  What’s different about these two documents?  The differences between requirements documents within each organization are found in the intended audience, the document’s purpose and the overall tone or message.

     You might have a difficult time finding a requirements document for product development today since many organizations are changing to AGILE methods. The requirements document for product development is an output of a waterfall methodology for software development in which the market and business or detailed requirements were written out mainly for the purposes of developing the software.  Sometimes it’s called a business requirements document (BRD) and can be split with another requirements document called a software requirements document (SRD). Focusing on just the SRD, the audience is internal resources, mainly developers and testers. The intent is to provide the detailed system requirements (and sometimes non-functional requirements) for verification testing.  These requirements tend to be more feature- or function-driven with details about processing. The message or the purpose of the document is to provide direction for development organization in terms of scope, assumptions, constraints and detailed functional or non-functional requirements.

     With software implementations, the requirements document has a completely different purpose. First, the audience is your client. The client reviewers of this document can perform various roles within the client organization, including CEO, executive leadership, Director, Manager, subject matter expert (SME), and project team member.  The intent of the requirements document is to provide the recommended implementation approach for how the product can be implemented to meet the needs of the organization.  The message or purpose should be to easily and succinctly give executive management a clear picture of how the product matches up with the organizational goals.  Therefore, it should include an executive summary.  If there are unfulfilled requirements, they need to be clearly spelled out so executives understand the impact to the business and whether or not there are viable workarounds.   If there are decisions to be made prior to proceeding, it should be there and if there is additional work requiring new contracting or additional expenses, it must be noted in an executive summary.  As a manager of BAs, I insist that a requirements document should not exceed 25 pages in length and should include the detailed requirements in an attachment. All the detailed business requirements and specifics can be attached as references or included in appendixes at the end of the document.

     If the above scenarios for product and service requirement documents do not describe your situation, the direction that you have been given by your management team, or resemble the document structure that you use within your organization, don’t be surprised.  That is the whole point, as there are so many other variations for requirements documents.  The question is:  Which document is right for your situation?  You can make a determination regarding what you think would improve your templates once you begin to comprehend the reason and purpose behind the document template you’re currently using.

If you are thinking about creating your own template, ask yourself these few basic questions.  If you can answer “yes” to all three then you can successfully make a case to build another document template.

  1. Do I understand the audience, document purpose and message in the current templates?
  2. Have I formulated the message and done the analysis necessary to write a good requirements document?
  3. Do I have a unique need that is not fulfilled by the current template?

     If you do NOT answer “yes” to the above questions then your business case will not succeed. It will highlight flaws in your own analysis skills and that is something most people prefer not to bring to the attention of their manager.  Bringing a case for a new template  to management and not being properly prepared could bring to light root causes for why you are struggling to write requirements documents that have nothing to do with the template itself.  Common reasons that analysts struggle when using templates are:

  • Not realizing what is supposed to be documented.
  • Not having the analysis complete.
  • Weakness in underlying business writing skills that cause difficulties using a template, including problems with how to express opinions, persuade a reader, influence a decision, etc.
  • Lack of advanced Microsoft Word features knowledge such as inserting pictures or objects, inserting hyperlinks, modifying pictures, using and including styles, advanced page break or header/footer notation and section breaks.

If you did answer “yes” to the three questions above then you have to ask yourself if you want to improve the process within your organization.  You can do so by following a few simple rules: 

  • Talk to your manager about your intentions and he/she can connect you with the right resource within your organization. 
  • Recognize that someone is already in charge of the processes.  Check in with that individual and explain your situation. 
  • Partner with a few peers in order to get your idea realized and your template streamlined by building your business case and explaining your current need.

Do not forget how important including your peers can be to succeeding in new template development.   They can give you feedback, improve your template, and support its usefulness and need within the department.  If they are aware and were part of its creation, they will be less likely to resist using the document once it’s part of standard operation procedure.

Working towards improving templates and processes by building new tools for team use is a great way to show initiative and creativity.  It shows a commitment to quality and an interest in improving processes within your organization. Your leadership skills can be demonstrated by taking the time to work through an idea and navigating organizational processes and politics to see your ideas turned into realized solutions.

 
Don’t forget to leave your comments below.

Maryanne Miller, CBAP, Business Services Manager 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.  

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.

10 Ways Analysts Can Contribute to Mitigating Risk

BATimes_May24_Feature_croppedHave you ever started a project without the formal contract? Have you been on a project without fully defined scope?  As an analyst who has worked in various organizations and different industries, I can tell you that I have been in both those situations.  Is that normal?  No.  In fact it goes against everything that the PMBOK and BABOK state are required input materials.

However, if you’re a new analyst working in the industry it can be confusing to know what to do and how handle these work situations since these are required input documents to begin work activities.

Below, I will share 10 tips on how BAs can assist with mitigating risks when faced with some of the most problematic business scenarios for Business Analysts.  These suggestions also can really get a project back on track from an analyst perspective.

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.

Requirements Risk often become Project Risks as such they need to be communicated with the Project Manager and worked into the Project Governance.  The risks can be mitigated if managed early and BAs often see these risks first.  BAs can contribute to mitigating project and requirement risks.  Learning how to identify these risks and recognizing how to handle the situations is important to managing those risks.

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 healthcare IT services. As a professional consultant providing business and technology leadership; her areas of experience include business process improvement, business analysis, and Healthcare IT.  For more information see: http://www.medecision.com/