Tuesday, March 3, 2015

Tips -Business Analysis !

  




Tips 1


 Fired Up -
  • For Car as your PMO, your PM is the Engine and you as the BAs are the GAS – The source of Power
  • For Tree as your PMO, your PM is the Trunk and you as the BAs are the roots – The source of energy and stability
  • For the war as the Project, you are the Chief Commander of war and your PM is the king observing that war from distance.
It is your skills which will equally decide the success or failure of a project as much it is with your PM. Else it won’t be true that about 70% of projects fail just because of BA’s poor requirements.

ALWAYS REMEMBER- > You are paid for identifying the real need, documenting expectations, generating the best and improved solutions, coordinating and managing team, and last but not least maintaining the company standards and code of professional conduct. Your are the SME - Subject Matter Expert for Technology Team and you are the Researcher for the Business Team. You are the link between Technology, Business and PMO.  You are the first contact for everything happens in the project from start to end. You are the leader of team and PM is the mentor & owner of the team.

Tips 2

Whenever you see a new person around you or in a meeting, always try to categorize them into two broad group (ask either they are from Business or Technology). Then if from Business the try to understand which operations or business are they from? Identify their position and their authority level by understanding how high they are in the organizational structure. Most people you encounter will be Directors, Sr Managers, Executives, Chief of Operations or Technologies etc who can make the decision on final requirements and solutions. Other people like officers or staffs of operations like Customer Service Representative, user of the product etc will be the one who will help you understand the detail of the product or scope of project but may not have the power to make any decision. They will have to go back to their executives to make the final decisions. ALERT - Business Stakeholders can have the power to terminate your project immediately if not satisfied.

If you encountered a Technology SME or Team member then you will have to start sorting them according their position. Understand about their power or level of authority on the system or technology they own. If now power then you will have to move one step up and determine their boss role and authority level –who may have the power to make the final decisions. In most cases, technology Executives or Chiefs make the final decision but the system level details are provided by lower level SMEs or tech experts or the tech users.

Tips 3

Most Important Stakeholders:  Each product of project is normally owned by one or many Business Owner(s) and one or many Technology Application Owner(s). It is critical to involve these owners to keep them informed of the impact of the project on their business or application. It is extremely important to get final approval on the requirements, solutions, UATs and other project artifacts from these owners. Never forget to get approval from your Project Managers as well. They are the owners of the project as a whole.

Tips -Bonus

Never avoid any stakeholders, rather embrace them all at once. Always create Stakeholders Log (RACI List) and keep track of all stakeholders’ expectations and needs both. In most cases expectations turn out to be requirements during the project execution. Project team is always changing and does this log, and the requirements.

PMI (PMBOK) recently started focusing more on Stakeholders Expectation (not just the requirements/needs rather expectations as well)? GUESS WHY? Now you know why, right?




Scary stakeholders influence the project future! What ?

  






What are the types of these Stakeholders who are so scary to influence the project success or failure?
  • Sponsor: a project sponsor is typically a senior executive either from program or department in your organization. Just thinks a person with the MONEY who is willing to take risk on the project future. Sponsors assign the Project Managers and authorize to start the project! Envision – an executive with project charter on one hand and money on another. Taking risk of project failure should be his/her habit. Whenever you see such a person in your team- you know now who this confident man/women is!
  • Vendor/Partners: Mostly the external parties who are in relationship with the project either due to contracts, agreements, bids, SLAs or work Orders. In most -cases they sell services or goods to the project. These people are important to understand the product feature of the solution (business requirement) if they are selling the goods. If they are selling the services then they are critical on the project process/tasks – ultimately responsible for the project requirements. DO YOU KNOW DIFFERENCE BETWEEN BUSINESS REQUIREMENTS AND PROJECT REQUIREMENTS? Letting you brainstorm a bit! While you are thinking – think also about the buyers & their impact  (not the sellers as stated above)
  • Project Team: the project manager is the person who was authorized (mostly by the project sponsor) to manage a project.  The project manager’s and business analyst job is to identify all other stakeholders as early as possible determine their role, responsibility, impact, influence. 

            These may be:

1.       Project Manager (also Sponsor)
2.       Business Owner (executive or director level)
3.       Technology Owner  (executive or director level)
4.       Business Analyst, System/Solution Analysts (may be combined as one role)
5.       Lead Engineers & Engineers
6.       Quality Assurance Analysts & their leads
7.       User Acceptance Testing Manager/Lead & UAT Testers
8.       Others – Vendor Project Team Members, External Team Members, etc



  • Requirements Stakeholders/Owners – You already know about them from the last post. If not yet then visit the post again.


CAN YOU ANSWER A MOST IMPORTANT QUESTION ALL EXPERIENCED PM OR BA KNOWS? Is the Business Analysts (or Lead BA/BSA or PM) the owner of requirements or is it someone else who owns the requirement? If you thought BA as owner then note you have a long way to go before you become a True Professional Business Analyst (not talking about Lead BA/BSA it is even farther away).
BA/BSA simply owns the requirement document not the requirements which are listed inside that document.  You are simply the author not the owner. Owner of each requirement is generally the accountable (sometimes responsible) person who provided you that requirement. That is the reason why we ask for their hard approval at the end.
Brainstorm again – what are the differences between BA role, Enterprise BA role, BSA role and IT BA or Technology BA role (not talking about Lead)? Add one more thought wave to your storming brain – Does BA approve artifacts (example – BRD or FRD) that they authored? In other words- is the author approver of any project artifact? Why? (Hint- look at the paragraph above)


  • Customer/Users/End-Users (future or past): customers or users are persons or organizations that use the product or service created by a project.
QUESTION- Can they be the past users? Yes- all the users who once used its previous version or all those who will use the future version for the enhancement projects (not brand new projects) are considered users of the product. User requirements mostly come from these users. Have you ever heard of User Stories? Yep – that’s it. User stories are higher level User Requirements (mostly said Business User Stories) which gets broken down into solutions and use cases.


If I get enough time to create other posts then I will bring up new topics on “Most Effective Ways Of Identifying User Stories”, “Their Relationship To Business Requirements” , “Their Use in Agile /Adoptive Methodology” and “Do They worth the Hype (Answer Hint –No)?”


 Leaving you with few important questions – Are stakeholder requirements same as User Requirements? Are they part of business requirements or business requirement is part of User Requirement? What about project requirement then? You don’t have to answer these questions online – they are just meant for you to think and research around …. 

Why do we need to involve all the Project Stakeholders?

  




All projects involve people with certain interests and priorities in the ongoing or future project(s), these people are known as stakeholders as they can directly or indirectly influence or impact or your project. In simpler words, stakeholder can be a person or organization that is affected by a project or that influences the project.
The most obvious rationale may be:
  1. Stakeholders from different domains/areas/segments may have different expectations; if their expectations not considered seriously then they may positively or negatively influence your project. It is not about being scared of these stakeholders rather it is about understanding what they expect from the project and helping resolve all the current issues & future risks.
  2. They may have conflicting interests or requirements which doesn’t align with the project scope- so what to do with them? Ignore them or take them seriously. Only suggestion is to get them involved as soon as you can, communicate to them regularly and meet their expectations. It doesn’t mean chance the project scope rather it is about bringing everyone on the same page. You will need strong negotiation skills and interpersonal skills.  
  3. Although normally stakeholders work on the favor of projects success but in few scenarios –stakeholders with high Influence & high Authority may negatively impact the project.  You obviously know now what to do with these stakeholders? Don’t, you?
  4. Few stakeholders are the Subject Matter Experts who may provide insights to the future risks and may help in designing the efficient & effective solution for the requirement. They are the gems of your project, and never should be ignored. Exploit SMEs Knowledge!
  5. There are other types of stakeholders who will either constrain your project (example – federal employee handling laws , compliance.. or environmentalist concerned about the fish near your project home etc) or  the ones who wish ultimate failure of your project (the competitors). You will need negotiation experience, market knowledge, product knowledge and soft skills to deal with these stakeholders. They may not directly impact your project progress but they may definitely change the outcome of your project.  If constrained tighter than expected then your Venus rover (final product of your project) will either land on moon or will look like a school bus.  SCOPE CREEP!

Be Careful!

Expert judgment is considered most efficient and cost effective method of requirement analysis. Be careful when you involve such judgment in the project solution. Different people (experts) may have different angle of viewing the same thing- one may see it as orange and another as an apple. If you don’t know whether it is orange or apple (in most cases you will never know) then go to the larger group to find the answer. Example – Information is defined differently by Accountants than the IT Developers; it doesn’t even align with the particle physicists’ definition of Information. Always and always perform a feasibility test on such proposed solution and verify it with larger audience (experts who wants to listen to you & care about the project) .

If you are thinking, is there a way to categories and strategically handle all stakeholders? -Then the short and sweet solution to your question-is again to involve them as early as you can and as many as you can. Never think of starting with few and growing in number of stakeholders- RATHER think just opposite. Most of the people who are not impacted by your project will soon leave the project. If you already involved a stakeholder who has high authority/power & influence and confirmed that he/she is not impacted by project then you are safe to ignore him/her in future, but think what would happen if totally missed out to involve this stakeholder in your project? Don’t you think it will be a disaster, ether your project will fail due to his/her influence and repeated change requests or you will soon be searching for the new job? So, you now know the answer to question - When is the best time to involve them?


Follow the next post to learn more about these things which we tend to ignore knowingly. 

Friday, March 9, 2012

Using BRTM/RTM for Risk Mitigation

  


Using BRTM/RTM for Risk Mitigation





The correlation between requirements inconsistency and designed product (software) inconsistency created due to inconsistent requirements (Business or System), generate a new risk which can be easily mitigated by traceability analysis. The traceability management (gap analysis) is the most important tool, yet easy to use, to identify the gaps and tracebility inconsistency even before major risk/issue occurs, especially helpful when the project is risky or sensitive. The traceability can be implemented in almost all phases of project life cycle as the best practices especily if you wish to accurately and efficiently product the exact product stated in Requirements Documents. The whole idea behind the traceability management is to ensure that all the development artifacts are directly or indirectly mapped back to one and another. Doing so provides us greater control over the execution of project and it efficiently migrates the risk of project failure.
BRTM/RTM, Gap Docs, Issue Logs, Risk Logs are the artifacts which act as the guidelines for all distributed (geologically diversified) teams to stay on the right track on project execution. In most cases, business needs are identified during the early stage of project but when those project requirements move down to the downstream teams (say Technology teams such engineers or QAs) then most often those requirements are misinterpreted by those teams. The result of this misinterpretation makes the project fail and accounts about 70% of total failed projects. It is not just the bad requirements that is accountable in such cases, sometimes it is the receiver of the message that comes from requirements documents. If we create BRTM/RTM than it provides a way to deliver the requemenyts and track them untill the project is complete. It helps as the meeting tool to brainstorm to identify the gaps and keep every team members on the same page. In other words, it is the language that every team member in a project can easily understand. Rememeber – BRTM/RTM is always a living document, meaning it is not a one time deal . It must be updated continually throughout the project.  This documents also help to identify the lessen learned for the future projects.
RTM and BRTM can also be an automated process or manual depending on the situation and the need for the use of traceability. The version control is also traceability that provides one step higher level of traceability to the BRTM & RTM.

How to create a BRTM and RTM?

  

Traceability in a professional way-How to create a BRTM and RTM?





The simplest way to do this is to use an excel file, however, requirement management software is an efficient way to create any traceability. Traceability is immediately created in such software as soon as you pass both requirements and comparable project objects.

Creating a BRTM in Excel:
Start an excel file and follow the steps below:
  1. It is important to mention the Project Name, Project  ID , Date and Name of Author in the beginning on the page
  2. In the column A, list down all the requirement IDs
  3. In column B, list down all the business requirements corresponding to the requirement ID
  4. In column C, provide the requirements type. It can be functional or non- functional.
  5. In column D, provide the description of the requirement.
  6. In the column E, list the corresponding High Level Design requirements or the project elements against which you want to compare the requirements. It can be business objectives or other  system requirements
  7. In the column F, provide the corresponding ID of the High Level requirement (project element from step 6)
  8. Requirements can be compared against any higher level project design or objectives which can be either of these: Business Objective, SLA, Higher Level BR, Domain Level BR, and Higher Level SR. So, you can add as many columns as you like to create your BRTM depending on what you are comparing your requirements against.
  9. The second last column can be a verification column to confirm if the requirements are traced back or not. This column is normally Yes/No answer column.
  10. The last column can be Comments/ Attachment column to provide additional comments or reference documents.

Creating a RTM in Excel:
RTM is no more than the extended version of BRTM. In the RTM requirements are compared against Higher Level SR, Design Level SR, Test Scenario and Test Cases. Follow the steps below:
  1. It is important to mention the Project Name, Project  ID , Date and Name of Author in the beginning on the page
  2. In the column A, list down all the requirement IDs
  3. In column B, list down all the business requirements corresponding to the requirement ID
  4. In column C, provide the requirements type. It can be functional or non- functional.
  5. In column D, provide the description of the requirement.
  6. In the column E, list the corresponding Higher Level System Requirements.
  7. In the column F, provide the corresponding ID of Higher Level System Requirements
  8. In the column G, list the corresponding Design  Level System Requirements
  9. In the column H, provide the corresponding ID of Design Level System Requirements
  10. In the column I, list the corresponding Test Scenario
  11. In the column J, provide the corresponding ID of Test Scenario
  12. In the column K, list the corresponding Test Case/ Test script
  13. In the column L, provide the corresponding ID of Test case / Test Script
  14. In the column M, can be a verification column to confirm if the requirements are traced back or not. This column is normally Yes/No answer column.
  15. The last column can be Comments/ Attachment column to provide additional comments or reference documents.

My Other Blogs:
Traceability in a professional way-Traceability Matrix and its uses

Traceability in a professional way-What are the differences between BRTM and RTM?

Traceability in a professional way-Traceability Matrix can be bidirectional

Traceability in professional way- BRTM/RTM risk mitigation

Traceability Matrix can be bidirectional

  

Traceability in a professional way-Traceability Matrix can be bidirectional








The normal flow of traceability is as shown below but this process can be reversed to identify the gaps and glitches:
Business Objective à SLA à Higher Level BR à Domain Level BR à Higher Level SR à Design Level SR àTest Scenario à Test Cases


My Other Blogs:
Traceability in a professional way-Traceability Matrix and its uses

Traceability in a professional way-What are the differences between BRTM and RTM?

Traceability in a professional way-How to create a BRTM and RTM?

Traceability in professional way- BRTM/RTM risk mitigation


What are the differences between BRTM and RTM?

  

Traceability in a professional way-What are the differences between BRTM and RTM?



Traceability Matrix is created in different phases of software development cycle.  BRTM is created during the initialization or planning phase of project life cycle. BRTM, Business Requirement Traceability Matrix, as its name suggest, it is the first traceability document created by Business Analyst to compare the Requirements against the Solutions/HLD or it can be reverse comparison document to compare requirements against the business objectives.  BRTM is considered high level traceability document because this documents provide higher level comparison as opposed to RTM. RTM, Requirement Traceability Matrix are normally created by System Analyst using the BRTM which was already created by Business Analyst. In most cases, BRTM or RTM are not considered the required project documents, however, any Business Analyst or System analyst can improve the quality by implementing it as the reference document to the project deliverable that they are obliged to create.

BRTM simply compares requirements against business objectives or High Level design. However, RTM is used to compare requirement against detail system level requirements, Design elements and Test Cases. RTM is detailed version of BRTM in simple terms.


My Other Blogs:
Traceability in a professional way-Traceability Matrix and its uses

Traceability in a professional way-Traceability Matrix can be bidirectional

Traceability in a professional way-How to create a BRTM and RTM?

Traceability in professional way- BRTM/RTM risk mitigation

Traceability in a Professional Way- Traceability Matrix and its Uses

  
Traceability in a professional way-Traceability Matrix and its uses

Traceability matrix is used to track requirements to any measurable objects in the software development process. Normally, we use traceability matrix to link requirements to use cases to process flow and requirements to process flow and requirements to business objectives. Requirements can be linked to design, specs or test cases. This mapping technique is useful to make sure that there is a complete coverage of requirement until the testing. However the most useful one that few know of is the linking requirements to the test cases and process flow. When the process flow is complete than we can have a comparison between the requirements and process flow and then we can easily identify the missing requirements. Another profound way of linking the requirements to validate is the reverse linking where we map the requirements with the business objectives or project plan. This way we can measure the value of requirements against the business objective and identify the relevant requirements. For the requirements which hold no value against the business objectives can be eliminated. In other hand, if we are unable to find all the requirements for the business objective than that means we have identified the missing requirement. In this case, the requirements should be added to your requirement document.


My Other Blogs:
Traceability in a professional way-Traceability Matrix and its uses

Traceability in a professional way-What are the differences between BRTM and RTM?

Traceability in a professional way-Traceability Matrix can be bidirectional

Traceability in a professional way-How to create a BRTM and RTM?

Traceability in professional way- BRTM/RTM risk mitigation

Tuesday, March 6, 2012

How to Perform Gap Analysis and Create Gap Documents

  

Gap Analysis- Professional Way


Gap analysis is the technique to identify the area of improvement in any process ranging from Business to technology.  The areas of improvement doesn’t necessarily mean any new enhancement, it is either about finding a gap between what is expected and what is really done. Gap analysis is not a tool for IT or Engineering but it can also be used to implement any business processes or strategies that are implicit to be improving soon.
Gap analysis doesn’t have to have any specific template or any standard model however, any artifact which reflects the differences between what is now and what it should really be in an organized way. This gap analysis technique is being used by almost all the businesses without knowing what this approach is really called. The beauty of Strategically Gap analysis is that it is not a certificate or any affiliate or compliance document rather is it a traceability strategy to improve the process with a perfect monitoring system.
Now, as we now understand what is gap analysis, what is left to understand is where really this analysis comes into play during Business Analysis. Well, there is no distinct time when this should be done but the good thing is that we can work on gap analysis as soon as we have two things to compare against. The first thing is the current state and the next thing is the future or expected state of the improvement. Take a situation when a Business Analyst work as an Enterprise BA and he is working on a Project plan. Now, as the project plan gets extended into high level requirement document then this a perfect time when you will have both current state and the future state. An Enterprise BA will then compare that Project Plan with the Higher Level requirements, which is also called gap analysis and try to find out what are the gaps that BA missed to include in the requirements. This is a chance for all Business Analysts to protect their responsibility and they themselves; just what they need to do is to create GAP Documents proactively. Not to mention that 75% projects fail due to wrong or missing requirements. No one can really take that responsibility to mislead any project.
In short, Gap analysis is an analytical and strategical process to identify the missing details or gaps in a document or process when we have both current and future state identified. It doesn’t have to be only the project documents for Gap Analysis nor it only have to be done by Business Analyst. Anyone who wants to proactively monitor and improve the process/system/policies or even the corporate strategies and cultures can use this ultimate technique to keep you into right track.



Efficient Way of Performing Gap Analysis:

With the advancement in the technology, especially with Information Technology, companies now start looking outside of their confined traditional knowledge library for the best practices and Job aids to improve their quality of product and culture. Gap analysis is a tool for those managers and CEOs who want to stay on the top of success.  If a gap analysis is done only one time then it makes very easier to monitor any new changes or improvements. Gap analysis is an In-process document and it is never considered a complete document until the whole project is either completed or terminated.
Let’s create a basic yet effective Gap Document for our Gap Analysis. We will attempt to identify the Gap between Current and Future State (assuming current and future states are both known to us). Open an excel file and start creating columns as steps below:
1.    Identify the Current State or As-Is process/state: Name the first column as “Current State “ and start listing all the current state functionalities or processes or anything that you want to perform gap analysis on.
2.    Identify the future state or To-Be process/State: Name the Second Column as “Future State” and start listing the future states corresponding to Current states. If there is no future state then mention “N/A” in the corresponding row. In care we do not know the name of future sate or simply the future state is unknown to us then mention “Unknown”.
Note- Lets take an example as I am creating a Business Requirement Document and I want to make sure that I listed out all the requirements. The best way to identify the missing requirement is by performing a quick gap analysis but how? Now after completing above two steps you can create a third column as “Identified as Requirement”. If you identified that enhancement in functionality as a requirement then mention “YES” in the corresponding row if not then say “NO” and this “NO” is the problem now. It is a GAP for this situation.
3.    Gap Exists? The third column can be named as “Gap Exists?” When current state and future state doesn’t perfectly match up then Gap Exists= “Yes”. In our example, when future state is unknown or N/A for us then that means there is a gap.
4.    Fourth Column as “Gap Description”: Use the fourth column to describe the Gap in detail. For the Gap which exits as Unknown, we can describe it as this gap exists due to unknown future state of corresponding current state. This gap should be resolved after the identification of future state is completed. You can even provide the Name of contact person and gap resolution strategies here in this column.
5.    Fifth Column- “Gap Resolution”: Column 5th, 6th and 7th are dedicated to Gap Resolution. As we already found Gaps, now we need to resolve them. In this column mention the detail how the Gap was resolved.  Provide all the information as possible.
6.    Column Six- “Gap Resolved By”: It is always good to mention the source in documents. Here in this column the name of person or source who resolved the Gap.
7.    Column Seven- “Gap Resolved Date”: Mention the date when the Gap was resolved.
8.    Column Eight – “Comments/Attachments”: Mention additional detail which you missed to include before.
There columns are not the standards. You can use it whichever way you want to, there are no standards or Gap Analysis Columns. These columns are used here because they are the best fields I could find to compare the Current and Future State, a simple illustration. You can add other columns like: Dependencies, Risk, Priority and so one as needed by your situation.
Flow Diagram of Basic Gap Analysis (stated above) should look like as image below:







Some Quick Tips on Gap Analysis:

1.    Color coding: Use color “Red” as the Gap Exists =”Yes” and Green for “No”. It will make it easier to read, understand or to demonstrate it to another person.
2.     Use Excel file – It is not limited to excel file, but excel is very effective tool for creating tables and comparing each cell.
3.    Use a Tab as “Version/History”: When you completed first gap analysis give it a version 1.0 and for next analysis version it as 1.1 or 2.0. Provide Date and Description of each version.
4.    Use a Tab “Supporting Documents”: Provide links or attachments in this tab with description of all the documents or sources that were used to create this gap document.
Gap Analysis is a general tool to monitor higher level functionality, especially used by Business Team; however, it has some limitations. One known limitation worth mentioning here is that it is nearly impossible to monitor a project which has thousands of small improvements and also when these improvements are broken down into many phases. In other words, we can only use a Gap analysis in Higher Level or for small part of a huge project. Mostly, gap analysis is done in a different way and named differently when it has to deal with system level details. Most of the times, we call it Traceability Matrix or Mapping Documents. These documents use some concepts of Gap Analysis but they are not considered as an Authentic Gap Documents. They are system level Docs or reference docs for system specs. I will make sure to post another blog on Traceability Matrix and Mapping Documents.

Feel free to add comments and suggestions! 

Subscribe to: Posts ( Atom )