Skip to main content

Tag: Planning

Avoiding Conflict between the PM and BA. Part 2.

Planning Business Analysis Work

When I first read the BABOK® Guide, my initial reaction was, “What are they thinking?!” With my PM hat perched squarely on my head, my reaction was “but… but this is PM work!” In my mind I imagined all kinds of conflict occurring as the BA took on more and more of the PM role. After all, as a PM I had done such traditional project management tasks as creating work breakdown structures, activity lists, estimating,  scheduling, and now a body of knowledge was saying that the BA was supposed to do this work? I could see heads butting already.

When I joined the BABOK committee about a year later and raised these concerns, I was asked an insightful question: “Elizabeth,” one of the committee members asked, “as a PM did you come up with all the deliverables, tasks, and estimates for everyone on the project?” Ah, BAs sure do ask good questions! I remembered that as a PM I had gone to many team members, in particular technical SMEs, the developers, our full-time business SME on the project, and others to get their deliverables, tasks, estimates, and availability. But it had never occurred to me to involve the BA. With that one question the light bulb came on. The image of locked horns disappeared. In its place I saw a PM (me) with the weight of too much project planning on her shoulders suddenly stand up straight and unencumbered. How much easier my life as a PM would have been if for the business analysis work, I had taken the information from the BA and rolled it into the overall project. What a relief it would have been to get the business analysis input from the person who knew the most about business analysis!

With the light bulb came a few related insights:

  1. Planning doesn’t mean doing all the work yourself, so PMs don’t have to complete all the planning processes listed in the PMBOK® Guide themselves. PMs need to ensure that all the work appropriate to the project is done, but that does not mean that the work in Section 5.1, Collect Requirements, for example, must be completed by the PM.
  2. BAs are closer to the business analysis effort, so input from BAs is apt to be more complete and correct. When competent BAs are on the project, PMs do not need to micromanage business analysis. There’s enough for PMs to do, so getting out of the way during business analysis will likely reduce the PM’s stress. PMs, so focused on delivering on time and within budget, need to realize that PMs and BAs working collaboratively get more done, so the project has a better chance of completing sooner.
  3. On large projects, both the PM and BA have full-time work doing project management and business analysis respectively. If either is saddled with doing the work of the other, both will be overburdened, increasing everyone’s pressure and stress levels. Under such circumstances, resolving the inevitable territorial conflict will be that much more difficult and take that much more time, delaying the project even further.

So my advice, PMs, is to let the BAs do business analysis work, which includes business analysis planning. My advice, BAs, if confronted with a PM who wants to plan for the entire project, is to keep asking those insightful questions!


Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

Why Visualize Requirements?

How many times have you been in a meeting discussing a set of requirements, a methodology, or a project plan etc and someone has gotten up from their chair and said “where’s the whiteboard let me draw what I mean”?

I can tell you for me it has been plenty!!!!

Whilst requirements specifications are a great way to document the detailed information related to a new or existing product’s functionality we all live in a time poor society and few of us have the time to trawl through large documents and extract the information we need and then start the seemingly endless e-mail threads to discuss the individual use cases associated with each requirement consisting of many messages that start and end with “what did you mean by X?”, ” I meant X and Y but I think you thought I meant Z!” Instead why don’t we adhere to the adage of a picture tells a thousand words and instead of page after page of documents create a visual representation of those requirements – hopefully communicating a thousand words in a single picture.

However, what we must remember is that visualization of requirements can vary in its meaning. For example, some people may view requirements visualization in the same context as simulation diagrams, whilst others interpret visualization to mean simple use case diagrams or business process flows typically created in a MS Visio type tool. For me, all of these usage contexts can represent visualization, so instead of trying to classify visualization into one genre I thinking it is best to view it on a scale with simple flows at one end and high end simulations at the other – and the user selects which method is most appropriate for them at any given time. For example, if you are trying to show how a user will move through an application to make a purchase then using MS Visio to define process flows may be enough. However, if you are trying to envisage how a new UI (User Interface) may look then mockups and more rich content visualizations would serve you better. Whichever method is selected there are a number of benefits that come from visualization these include:

  • Flexibility and Usability – flow diagrams can be easier to navigate helping to find content
  • Mistakes can be easier to identify in a visualization
  • Easier to identify potential parallelisms between requirements and business processes
  • Easier to spot missing Use Cases in business process
  • Increase understanding of the requirements themselves
  • Increase understanding of the dependencies between requirements
  • Visualization of business flows can provide a first bridge to Business Process Models or SOA repositories

Now that we have explored some of the benefits of visualization the question now becomes when should it be used? Should we visualize every requirements we write or just some and if we are going to be selective which requirements should we chose?

In my opinion there are a number of questions we can ask ourselves which can help to determine when to and when not to visualize. These include (and there are many more):

  • Type of development method – we need to ask ourselves the question do requirements visualizations fit in with the need for more agile and rapid requirements definition or will they add more time to the development process?
  • Complexity of the requirement – if a requirement has too many sub requirements will this create a “spiders web” diagram which may overcomplicate the definition of the requirement?
  • Type of requirement – should we visualize the user story only and define the functional requirements associated with this user story as text or do we want to visualize all requirements?
  • Risk level of the requirements – should only high priority or high risk requirements be candidates for visualization?

It is important to note that I am not saying that requirements visualization is a “panacea” for enabling effective business and IT communication but what it will do is act as a good facilitator to help initiate a better degree of communication and understanding between the two parties.

So now the decision is yours. Why not try visualizing requirements and feed back to the group how things go.


Genefa Murphy works and blogs with Hewlett-Packard where she is Product Manager for Requirements Management. This article first appeared in HP Communities.

© Copyright 2009 Hewlett-Packard Development Company, L.P.

The New Role of the Business Analyst and The Strategic Implications

The new role of the BA is far more strategic in both the organizational sense as well as at the project level. In fact, I would go as far as to say that the BA, when appropriately leveraged, represents a liaison between business, project and customer teams. This shift in responsibilities identifies two areas that need to be addressed by any organization seeking to expand this role:

  • The organizational structure must support the actions of a “strategic” BA position. 
  • The BA candidate must have wide skill sets, encompassing many general management competencies.

As organizations shift to become “projectized,” the roles and responsibilities that have supported projects within a traditional matrix structure must shift as well. Over the years we have seen organizations struggle with the following challenges related to shifts in both structure and culture: 

  • Broken or disjointed cross-functional communication channels. 
  • Uncertainty around roles and responsibilities within the project structure and beyond. 
  • Quality concerns at the point of project delivery. 
  • Skewed scope statements and, thus, implementation plans due to early-stage breakdown. 
  • Overall loss of productivity on project teams due to lack of continuity and methods.

The items noted above are tell-tale signs that several strategic components of a best practice project management environment are missing. In the past, we addressed the discussion around project office and methodology; the topic of BA is an integral component to bring both of those items to life in the real world.

Forward looking or best in class organizations have aggressively embraced the concept of the BA role. What sets them apart from the old school thinking associated with this job title is the escalation and expansion of the roles, definition and responsibilities. Not too many years ago, a BA may have been confined to a very technical role within an IT environment working on specifications, functionality and even some quality and testing related to one or more project life cycles. Today we are seeing BA positions filled from across the organization and expect that this trend will continue, as it should.

Let’s address these points in the context of how they can be leveraged to meet the challenges:

Broken or disjointed cross-functional communication channels

A BA should be in front of any project communication produced, from the point of team inception to the close-out phase. This interaction does not mean that the BA takes on the role of project manager (although we have seen organizations combine the two roles), as it is not effective on larger and longer term initiatives. Our experience shows that an independent BA position can help to promote better communication, align protocol and help the project manager to extend his/her reach into the project teams.

Uncertainty around roles and responsibilities within the project structure and beyond

The BA functions as a tour guide through the project plan ensuring that all of the moving pieces are touching at the right points. We call these critical communication points and they can be built around time, budget or deliverable expectations. The BA will be assigned a protocol map within the project structure to enable better access to expectations, and provide for a proactive way to reach team members.

Quality concerns at the point of project delivery

In reality, the BA is monitoring quality points through the project life cycle, thus producing a quality product at the close of the project. Very much like the thinking around proactive quality control, the BA is in front of each deliverable and monitors the progress against the project plan. This allows for immediate communication between the project manager, customer and associated teams.

Skewed scope statements and thus implementation plans due to early stage breakdown

The planning stages of a project are obviously critical to the implementation plan and ultimate quality. A BA should be assigned early in the process and work hand in hand with the project manager to ensure the highest level of intimacy with the plan. Just as important, they need to have a direct connection to the internal and external customers in order to ensure collaboration and proactive attention to emerging issues.

Overall loss of productivity on project teams due to lack of continuity and methods

A strategic BA assists the project manager and PMO with the execution of best practice within an organization’s project management structure. The BA has a unique opportunity to guide the process through an existing methodology and essentially help the project to operate in better alignment. This is accomplished by having a dedicated individual who is consistently working against the deliverables and is not distracted by the operations management associated with the project manager’s job.

By taking the above steps you have begun the shift toward the organizational structure needed to take advantage of the BA position. With that said, we still have one more change to make in order to secure success.

It is obvious that the BA role, as defined here, will require wider skill sets than the more traditional BA position, still driven from the IT departments of yester-year. To that point we have begun to see a trend where the BA position can spawn from either business or IT. This is an interesting point as it speaks volumes to an organization’s maturity around project management. Imagine, for just a moment, an organization that has no boundaries within in its functions and everyone on the team collaborates toward a common goal. I like to call this organizational desegregation and cultural morphing. As we begin the next phase of benchmarking the project management industry and clients, we are beginning to see this shift as a representative of the next wave of advancing thought in the project management space. It was not too many years ago that I published an article on the emerging role of the project manager as the CEO of his/her project. I am confident that the BA role will take a firmly positioned spot in the upper hierarchy of any world class project organization within the next few years.

In order to succeed the BA will need to have a competency profile that meets the following criteria: 

  • Excellent understanding of both business and technology within the project environment. 
  • Be a leader, communicator and professional. 
  • Understand the skills associated with internal consulting techniques. 
  • Be proficient in project management skills as well as a complete understanding of the internal process. 
  • Epitomize the essence of a collaborator and team player. 
  • Understand and be able to navigate through the organization’s politics and structure. 
  • Be able to manage without having authority via negotiation. 
  • Understand true stewardship-based service.

So, the BA role probably looks a little different than a traditional structure may have dictated. Yet, this is the trend and, I believe, will become the norm. As organizations look to enhance productivity and quality while reducing cost, they are finding this role to be extremely important. Additionally, project managers we spoke to during the research for this article all stated that having a BA on the team made their job easier, and allowing them to focus on deliverable based activity.

It is important to note that this type of structure is recommended for mid- to large-size projects, but on the smaller initiatives we found that these attributes were part of the project manager’s role.


Phil Ventresca is Founder, CEO and President of Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Phil has utilized his extensive background in management and consulting to lead AMS to its current status as a multi-million dollar enterprise with an international customer base. Phil has led the organization to recognize several strategic breakthroughs such as developing partnerships with distance education providers, software developers and publishers. Through these efforts, AMS has emerged as a leader in consulting, training and assessment services. He has also founded three other businesses which remain under his direction, PTV Equity Management, WIT Group and AMS Aviation. For more information regarding this topic Phil can be contacted at [email protected].

Test Plan

Last month I discussed the justification for testing.  Here are the minimum testing requirements of any organization.  If you are a client purchasing software or contracting for the development of software, then consider requesting proof that it actually works.

Acceptance Tests
Responsibility: Quality Control

  • QC develops acceptance tests for key system features
  • QC adds to the acceptance test suite as new features are implemented or customers contract for customizations

Unit Testing
Responsibility: Developers.

  • Developers write unit tests as an integrated part of the code base
  • In many cases the test code will be as large as the system of test

Release

  • A developer does not release code until
    • The code is written
    • All unit and acceptance tests pass.
    • All requirement and test case documents match and accurately reflect the actual code delivered.
  • Three Components of any Release 
    • Code Base 
    • Testing Base 
    • Documentation

Defect Resolution

  • Unit and acceptance tests are written to replicate any reported bugs. 
  • The entire test suite, including the new tests, is executed to ensure the bug has been      resolved and no new bugs have been introduced.

When is the BA’s Work Finally Finished?

The business analyst’s work is not finished when the requirements document is signed off. Although other experts are responsible for the project activities, the BA remains involved to ensure that decisions made have no adverse impact on the business stakeholders. As the project progresses, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the agreed solution will satisfy the requirements.

After the solution has been built, the BA collaborates with many people on activities such as testing, conversion, cutover, and training. Depending on the roles defined in an organization and the project, the BA may collaborate with the people who are responsible for these activities, or the BA may be the responsible person. In either case, the BA ensures that all of the right things happen.

Monitor Solution Design and Planning

As the technical team derives the solution design, the BA must learn enough about the implications of that design to ensure that it supports the requirements well. For example, the BA might:

  • Review user classes to ensure that all of the solution functions, uses, and end users have been accounted for.
  • Review the developers’ functions and feature list for completeness.
  • Map the documented requirements (both functional and Quality of Service) onto the elements of the system design to ensure complete coverage.

When the technical team defines their phasing plan (which identifies the order in which requirements will be addressed and functionalities designed and built) for incremental development, the BA must ensure that the plan supports the stakeholders’ needs. If the plan calls for features to be delivered in a certain order, the BA should ensure that the planned order and delivery dates will suit the business stakeholders. The BA should also ensure that the phasing plan provides opportunities for any needed prototyping or validation during the project.

Tracing the requirements to the design is a good way to ensure complete coverage, and it lays the foundation for maintaining traceability throughout the project. The traceability information must be captured and recorded as the designs are being done, as trying to derive the traceability after the fact is difficult, if not impossible.

Finally, as the solution is being designed and built, the BA may identify business process improvements that are unrelated to the solution that is being built that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Approved Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to be sure that those deliverables satisfy the requirements and can be used by the intended end users.

  • System testing looks at the final system to determine if the requirements have been satisfied.
  • System integration testing refers to testing the final solution to ensure that it can coexist and integrate with existing systems and databases. Many organizations have an independent testing group whose main responsibility is to prepare for and perform these tests. When that is the case, the BA will usually review the test plans and the test results, and at times, the BA may help with the testing. However, in organizations that don’t have testing groups the entire responsibility falls to the BA.
  • Operations testing involves testing the solution to ensure that it can be installed and run without an adverse effect on the other existing systems. If the computer operations group takes responsibility for this testing, then the BA will usually review the test plans and the test results. But if this testing is necessary and no one takes responsibility for it, then the entire responsibility for this testing falls to the BA.
  • Acceptance testing ensures that the business need and user’s needs have been fully satisfied. If the customer takes responsibility for this testing, then the BA will usually review the test plans and the test results. Otherwise, the entire responsibility for this testing falls to the BA.

Assess Other Solution Options

The BA should collaborate with a variety of people on the project as the solution is being put together. In all cases, expect the experts in each area to be making good choices. The BA’s role in the collaboration is merely to serve as the business stakeholders’ advocate and assure that their needs will ultimately be met.

Although the technical team takes the lead in evaluating and deciding on the technologies that could be employed to build the solution, the BA should remain involved. This is because every technical choice has the potential to cause limitations in the solution that will be noticeable to the users. So, the BA must learn enough about the effects of the team’s technical choices to ensure that they actually do support satisfying the requirements, and ultimately, the business needs.

When the plan involves purchasing or leasing (as opposed to developing internally) a solution, the BA may take the lead in choosing the solution. But even if someone else has primary responsibility for this, the BA will still remain closely involved. The BA ensures that any RFP (request for proposal) or RFQ (request for quote) accurately translates the requirements. The BA should also verify that the proposals received will fully meet the business need. And, when the solution is finally received, the BA ensures that it is adequately tested to be sure that is actually satisfies the requirements.

Support Implementation of the Solution

In some organizations, an operations team takes the lead in implementation, but often the BA is responsible. In either case, the BA must remain involved to ensure that implementation and any necessary conversion meets the needs of the users.

The BA ensures that any necessary installation planning is done, and that the appropriate technical experts review that plan for correctness. This could be as simple as ensuring there is enough disk space for the new software, or as complex as replacing entire computer systems with new ones.

Conversion is almost always an issue. Since the solution is most likely changing some attribute of the business process, there will probably be data conversion; there may also be other kinds of conversions to be done. Planning for these includes identifying the rules for handling the inevitable problems that will be found.

Finally, the plan to the final cutover to the solution must be well thought out. When should it happen? Will there be downtime involved? If so, how much is acceptable? An important, but often overlooked item is the “backout” plan. If the cutover fails, what must be done so the business can resume working with the old system? If there is significant data conversion or other changes, this can be a difficult problem.

Communicate the Solution Impacts

The responsibility for communicating the impact of the solution is assigned to different people in different organizations. In any case, the BA must still remain involved. Before the new solution is implemented, the BA should work with the business stakeholders to ensure that they are ready for it by:

  • Ensuring that everyone who needs to know about the implementation has the information they need, when they need it, before implementation
  • Setting the expectations of users and other stakeholders about how the change will affect them and the business process
  • Making sure that any needed training and help is available to the users in a timely manner

After the implementation is complete, the BA collaborates with the appropriate people to report on the implementation. This reporting provides pertinent information to all the parties who need to know that the implementation took place, and if there were problems. A key item is the business impact that the change had. Since the project was undertaken to improve a business process, the actual impact on the business process is of major concern.

Perform Post-Implementation Review and Assessment

The final validation occurs after rollout of the solution is complete. This activity, also known as “Lessons Learned,” is designed to help the organization learn from each project, supporting continuous process improvement.

You need to capture these successes, identify why they happened on this project, and determine what can be done on future projects to make them routine. The parts of this project that worked particularly well represent opportunities for future projects.

By the same token, if there were things in this project that were problematic, they also represent opportunities for improvement. You need to capture these issues, identify why they happened on this project, and determine what can be done on future projects to avoid them.

The Lessons Learned review is one of the most potent mechanisms for organizational learning and continuous improvement, as long as you actually use what you learned in future projects.

In Summary

Solution assessment includes all the activities that the BA collaborates in to ensure that the technical and other decisions being made by the development team result in meeting the needs of the business and users. These activities include design decisions, phasing for incremental development, maintaining the traceability matrix, choosing technologies, procuring solutions, and ensuring usability.

Copyright © Global Knowledge Training LLC. All rights reserved.


Jill Liles has been the Marketing Manager for Global Knowledge’s Business Analysis training courses for two years. Her background is in continuing education and non-profit marketing, and she graduated Summa Cum Laude from Peace College in Raleigh, NC.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.