Skip to main content

The Business Analyst and Project Manager Rolled into One!

Terry Longo’s Monthly Blog

During two of the three recent Project Summit / Business Analysis World conferences, I had the privilege of moderating a roundtable discussion whose topic was “The Dual Role of Project Manager and Business Analyst: Is it Possible?” It is, of course, no surprise that it is not only possible, but very common. (In my informal polls of audiences at my presentations, it seems that roughly 10-30% of the people in the audience are playing both roles).

The underlying question of course is “Can it be done well, and what are the benefits, costs, and risks?” And, in light of our intensifying efforts to professionalize the business analyst role, this question is vital, for it has significant implications for the organization relative to:

  • Job definitions 
  • Career paths for people aspiring to or in PM- or BA-related roles 
  • The manner in which stakeholders engage with requirements teams and solutions teams 
  • The nature and rigor of the requirements-related language present in the organization’s culture 
  • The design of processes, policies, and tools underpinning PM and BA activities 
  • The practitioner’s ability to distinguish between requirements-related change and risk and project-related change and risk

As far as the factors that make it workable with acceptable results, the two I hear about most are: 

  1. Small projects 
  2. The absence of compliance-related documentation requirements. This is interesting, since being in a compliance environment demands so much in the way of documentation of project and requirements activities, that it can be overwhelming for one person.

The questions in my mind now are (a) if there are other factors in favor of the dual role assignment, what are they, and (b) if there are no advantages on larger projects, why are we (the collective we, of course) doing it to ourselves?

Much of the answer lies somewhere in the current recognition of the role of the Business Analysis Center of Excellence, a part of the charter of which would be to understand more deeply the dynamics of the dual role, and only support it where it is justifiable in terms of risks and benefits.

Without that risk/benefit view, it seems to be, well, risky.

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through or at [email protected]

The Thin Line Between SME and PM

It isn’t uncommon for Subject Matter Experts (SME) to run or lead projects. In fact this tends to occur when the sponsor’s focus is on the conten, of the project. They often don’t really see the value of a separate PM role.

While it is vital to have a subject matter expert or analyst on a project, (as PMs should not be responsible for developing solutions) there are some subtle yet potentially costly risks associated with putting that individual in a dual SME/PM role.

It is human nature to focus our attention and efforts in our areas of expertise and, more often than not, this is what occurs. An SME is more likely to focus their attention on the details around the solution and to then go through the motions when it comes to the PM component of their role. This includes throwing together a project plan, because this is expected of the PM side of their role.

In my time, I have come across many SME built project plans and they contain some consistent findings. One is that the project plan always seems to end on the targeted project completion date, but the critical path cannot be calculated. This is usually because there are few if any dependencies built in. Instead the Start No Earlier Than (I call it the SNET) constraint is abused throughout the plan, obscuring the total slack.

So what? Well, while the solution may approximate perfection, the estimated time, effort and costs are unknown and likely based on a faulty work back plan. The project plan is simply window dressing, there simply to satisfy the sponsor and stakeholders’ need to see things appear to wrap up on time.

What results is often a project that overruns its scheduled time due to poor planning. Key resources, that may also cost dollars (IT resources or consultants), either disperse to other previously committed projects or must charge the extra time against the project, increasing the budget and lowering the return on investment.

In many cases this part of the job is severely neglected in favor of developing solutions. The other risk is that having an SME who is also responsible for the PM function is akin to having the fox watching the chicken coop. The PM role naturally provides the devil’s advocate to question the validity and assess the overall impact to the project’s success when change requests are introduced.

Scope creep cannot be properly managed without having an unbiased second opinion and a true assessment of the impact on the overall plan. This again leads to the perfect solution that will likely meet none of the requirements of the triple constraint. If getting to market on time is a key requirement, you need to have someone whose focus will remain on getting to market on time. SMEs are excellent at what they do which is why they perform this role. Their participation is vital to the project’s success. Excellence and perfection are the undying goals of a SME and rightly so. This is why they are at the table.

A PM’s role is to ensure that ALL of the objectives of the sponsor are being addressed, stakeholder expectations are managed, and that there is a high quality, regularly revisited plan in place along with the proper checkpoints and processes to address the unknown unknowns that tend to crop up at inopportune times.

Not all projects require a PM. As a rule of thumb, if the number of stakeholders and team members is small, the scope of the project is limited to one department (not an enterprise wide project) and time and cost is not an issue, you may be able to manage with a SME/PM. Once the scope of the project grows beyond this, your risks increase significantly unless you have a qualified and experienced project manager running your project.

The PM’s view of the project is much broader than the SME’s and project success means keeping your eye on all the moving parts of the project, including the solution.

Sean Best, PMP is a project management consultant and managing director of CRM Project Management Consulting. His 14+ years of project management experience includes work in the banking, payment processing, telecommunications and software industries. He can be reached at [email protected]

The Case for Establishing an Internal Business Analysis Certification

With the growing importance being placed on professional certification like the Project Management Professional (PMP) and the Certified Business Analyst Professional (CBAP), setting up an internal business analysis training program, in partnership with an Endorsed Education Provider (EEP) of the International Institute of Business Analysis (IIBA) might make sense for many companies.

The result would be a designation that would combine the best practices of the business analysis profession with the specific organization’s corporate strategy, business domain model and project management lifecycle. This is possible through a single certification process established internally in an organization.

An internal certification program for business analysis should be a joint effort between a company’s training department and its established BA Center of Excellence.

Objectives of an Internal BA Certification Program

There are many goals to be achieved by establishing an internal BA certification program:

  • Raise the performance standards for business analysts within the company. 
  • Educate BA staff about proven best practices amongst the company’s various departments. 
  • Align industry standards with the company’s standard project management lifecycle and system development lifecycle methodologies. Thus, management doesn’t have to worry about their company’s BA staff utilizing analysis techniques and methodology standards that their company may not recognize. 
  • Additionally, such a BA certification would align IIBA best practices and methodology standards with the company-wide BA procedures and audit practices. 
  • Provide a training outlet within the company for BAs to gain PDUs (professional development units) with the IIBA (or other professional organizations) as well as CECs (continuing education credits) with academic institutions. This is accomplished by partnering with a vendor approved by the IIBA, which will ensure that the majority, if not all of a company’s BA staff, will receive the same quality training.

Training Vendor Partnership

Partnering with a training vendor is critical to the overall success of an internal certification program for the following reasons: 

  • BA staff from different departments will receive the same quality training and tools. 
  • BA staff will be seeking external training opportunities as a last resort. 
  • Most training vendors provide a discount for a group of class registrations from the same company. As an added measure of ROI (Return On Investment), partnering with a training vendor will save the company training costs.

Internal Certification Structure

An internal certification program should be structured with key educational design factors in mind: 

  • To be certified, candidates would be required to pass an examination with questions based on the core knowledge areas of business analysis as well as experience/scenario based short essays. This would be a single examination encompassing all the core knowledge areas that make up the BA profession, in addition to the company’s standard project management lifecycle and system development lifecycle methodologies. 
  • Candidates would be required to complete a minimum number of annual volunteering/activity hours with the company’s BA Center of Excellence and/or their local IIBA Chapter (in case only one exists.) 
  • Candidates would be required to complete a set number of courses (or be waived by passing knowledge/skills assessment for each course). An ideal outline of BA courses would include the following:
    Course Outline Mandatory for BA Career Levels
    1) Corporate Strategy and Business Domain  BA-1, BA-II
    2) Advanced Knowledge of the Business  BA-II, BA-III, Senior BA
    3) Introduction to Business Analysis  BA-I
    4) Overview of the Organizational  SDLC BA-I, BA-II (optional)
    5) System Design Concepts  BA-I, BA-II
    6) Essentials of Risk Management and Validation  BA-I, BA-II, BA-III
    7) Business Process Modeling  BA-I, BA-II, BA-III, Senior BA
    8) Business Requirements Elicitation and Management BA-I, BA-II, BA-III, Senior BA
    9) Advanced Business Analysis BA-III, Senior BA (optional)

  • Provide an outline of optional courses in business analysis for non-BA staff interested in business analysis or who perform occasional BA roles, such as project managers, developers and testers.

So you can see, establishing an internal BA certification would be of great benefit to many corporations and forward-thinking organizations, regardless of size. This would ensure that the organization has the near perfect talent pool of BA skills and knowledge from both industry-wide and internal corporate points of view. Thus, an organization’s BA staff can more realistically balance internal project weaknesses and strengths with external market threats and opportunities.

Youssif Ansara is an IT Business Consultant who has worked with various industries including oil and petrochemicals and health care insurance, as well as entrepreneurship in the education sector. He gained his expertise from his involvement with technical business analysis and human resource management, both in the United States and abroad. He is an avid advocate of usability testing in both the public and private sectors to ensure that their systems are widely accessible. He does this by conducting accessibility assessments and public speaking about Section 508 of the Rehabilitation Act as amended by the U.S. Congress in 1998 to ensure that electronic and information technology can be accessible to people with disabilities. Youssif Ansara, can be contacted at [email protected]

© Youssif Ansara, 2007

The Money Is All in the Stupid Stuff

Building on our case study from my last blog – to analyze stakeholder needs for a National and Global Identity System – let me show you what I mean about the money.

Here is a list of stakeholders who might have an interest in such a system – pretty straightforward, stupid stuff, often produced early in a project and never questioned:


Credit Card Companies
On-Line Sellers
Disney (takes fingerprints, did you know?).
More along the same lines…

Law Enforcement
National Security
Internal Revenue
Labor Department
Unemployment Agency
More along the same lines…

Now for a quiz:

  1. What might be wrong with the above list?
  2. What might it cost to ignore the errors/omissions/assumptions, if any?
  3. What concepts or categories might help with analyzing this list, regardless of any problems so far?
  4. If you, as a BA, can even begin to address such questions, what is your earning potential?

Potential answers will be discussed next month, and incorporated into the case study. The best reader response will be acknowledged next month (send a picture with your response!) and will undoubtedly receive a large raise in the near future, just for rising above the pack!

Hint in the meantime:
This is not a multiple-choice question exercise with trivial answers – it is a truly difficult and nefarious case to analyze, with every pitfall you can imagine. Don’t be afraid to question anything; we are building a REAL case study here. The best reader response might even turn out to be the best next questions to ask!

Five Tips for Infusing Business Analysis Into Projects

In business today, any project is ultimately measured by one thing: return on investment. There are dozens of metrics to be measured along the way, from budget and deadline to scope and stakeholder satisfaction. However, at the end of the day, ROI trumps all.

Remember the movie Titanic? It overshot its budget by a nautical mile and took much longer to make than originally scheduled. However, a lifeboat full of Oscars later, the movie grossed about a billion dollars around the world.

Unfortunately, with your current projects, you probably won’t be able to lean on Leonardo DiCaprio to drive profits. That’s why, from a business standpoint, it makes sense to give your projects the best chance of success from the very beginning of the project life cycle. In other words, don’t sink your chances at profitability before you even leave the harbor. Metaphorically speaking, of course.

The best way to do this is to mix business analysis into your project management efforts. For years, professionals have been realizing that the infusion of business analysis can dramatically improve the likelihood of project success. Business analysis is essential for establishing project requirements, ensuring that your stakeholders are on board and eliminating the countless hours of rework that can wreak havoc on your budgets and timelines.

To help guide you in the integration of business analysis into your project mix, I’ve listed five key tips. From requirements gathering to communication to validation, think of it as your crash course in the value of business analysis. Each tip can be mapped back to the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK)

1. Ensure That Requirements Support Your Overall Business Needs

Having a list of business requirements is certainly an integral part of your long journey toward project success. However, before celebrating, you need to be absolutely certain that those requirements support your organization’s overall business objectives.

For example, if a company is looking to increase the efficiency of its call center by 20% over the next 12 months, it must first determine whether the requirements for achieving that goal fall within the business needs in terms of benefit and cost. If the requirements call for too much time and money to be spent, then the validity of the project should be called into question.

To determine if requirements support the business needs, analysts can use one of the most central business analysis functions: enterprise analysis (EA). EA accesses an organization’s internal environment from multiple perspectives in order to gain a thorough understanding of the business as a whole, and identify how that business can meet its strategic objectives.

2. Clearly Understand the Requirements Gathering Process

Throughout the business community, it is widely agreed that about 50% of troubled projects are troubled because of poor requirements definition. So obviously, at the beginning of a project, it is vital to effectively gather all of the requirements needed for success. This is accomplished by relying once again on our old shipmate, enterprise analysis.

EA, when performed correctly, will help you go beyond simply understanding the as-is state of the business and clearly define your stakeholders. There are several business analysis practices that will aid you in this process:

  • RACI Charts offer a means for identifying different types of stakeholders – responsible, accountable, consult and inform – and offer strategies for dealing with each. 
  • User Profiles provide insight into the different classes of stakeholders and what their interaction will be with the intended solution. This ensures that all interested parties are included in the process. 
  • Stakeholder Questionnaires help narrow your pool of potential stakeholders to the true decision makers. Too often, business analysts, project managers and project sponsors discover in the middle of a project that they’ve left someone off the stakeholder list or included someone who doesn’t belong. Going backwards and bringing new stakeholders into the fold is time consuming and expensive.

3. Avoid Analysis Paralysis

Once you’ve successfully identified your stakeholders, you’re then tasked with choosing the most effective elicitation techniques. The key here is to be flexible and open enough to consider different techniques for different audiences. Techniques should be chosen based upon the different stages (vision, definition, analysis and decision) of solution development, the type of project, the size of the project and the experience of the team members involved.

At the Vision Stage, brainstorming and brain writing are effective. The Definition Stage is well supported by focus groups and joint-application-development sessions. During the Analysis Stage, gap analysis, root-cause analysis and force-field analysis are preferred. And, finally, during the Decision Stage, you should encourage multi-voting, criteria-based grids and impact/effort grids.

4. Deliver the Right Message to the Right People

The communication of your business requirements is nearly as important as the development of those requirements. To effectively communicate requirements to your stakeholders, you need to develop a communication plan that will determine who will communicate with your stakeholders, what they will say and when and how they will say it.

Of the who, what, when and how of your communication plan, you should pay particular attention to the who. Your designated communicator or communicators should obviously have solid business communication skills; however, you must think beyond that. Everyone has a different communication style, and it’s your responsibility to ensure that you’re communicating to your stakeholders the right way. This begins with determining whether you’ll be communicating with a homogenous or a heterogeneous group of stakeholders. If you find that you’re dealing with a homogenous group of C-level stakeholders, it’s best not to send your most meticulous thinker into the room. Chief executives tend to think in big-picture terms; bog them down in the details and you could be asking for conflict—particularity if you’re trying to prove the case against moving toward a proposed solution.

5. Validate the Business Needs

Once your project is complete, and after your team has enjoyed a happy hour, you’ve entered the solutions assessment and validation stage of your project. Your main objective here is to ensure that your finished product meets the initial agreed-upon requirements and that it has fulfilled its original purpose. For many projects, this process will be aided by simply adhering to regularity standards. However, for those projects that aren’t overseen by such standards, traceability matrixes are helpful because they create unique identifiers for each requirement that maps back to the original business need.

Also, traceability matrixes will help you make sure that no unnecessary requirements have crashed the party along the way. For example, if your goal was to build the world’s best sports car, you’ll be able to identify the incongruity of the towing hitch on the back bumper and, more importantly, recognize that it shouldn’t be there.

In Conclusion: Iceberg Avoidance

Any project you launch will face challenges, and the bigger your project gets, the rougher the waters will be. However, by following these basic tips and integrating business analysis into your projects from the very beginning, you’ll be much more prepared to identify all the icebergs in your path and keep your projects afloat from beginning to end.

Glenn R. Brûlé is Director of Client Solutions at ESI International ( and IIBA Director at Large. He has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis, Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries. These include financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.