Skip to main content

Tag: Planning

Project Manager and Business Analyst In Tandem for Success

Written by Sergey Korban on . Posted in Articles. 3 Comments on Project Manager and Business Analyst In Tandem for Success

I’ve been working in project management and business analysis domains for many years. The projects I’ve been engaged in cover regulatory compliance, business process improvements, software development, ERP implementation and ITIL adherence, just to name a few.

Heated discussions about relationships between a project manager (PM) and a business analyst (BA) are often focused on their non-aligning sides rather than on their mutual efforts to ensure project success.

I tend to think about PMs and BAs working together in projects as two hands carrying a baby. Here is my view on the PM-BA tandem and how it comes together to make a project successful.

 How It Works

I’ve been involved in multiple projects for the last two decades. The projects were of different scales and nature. However, there is one common element in all of them:  a project manager and a business analyst are the two sides of the same coin. Their skills and joined efforts make a project successful and deliver good value to the business. I would like to demonstrate how a PM and a BA could work on a project, and explore each project phase in more detail. Please note that project phases and the documentation involved follow PRINCE2®.

Project Start Up

PM and BA work with project stakeholders throughout the entire project lifecycle. Before the project starts, a PM deals with business stakeholders to identify the business need at a high level. The outcome of this interaction is a Project Initiation document. This document outlines the business need, the impact of the current state on the business, the desired target state, project complexity, estimated project duration and expected benefits.

 ba-pm-article-diagram

 PM-BA: Collaboration Model

Project Initiation

The PM engages the BA to help with project scoping and definition of the business need, expected project outcome (deliverables) and project acceptance criteria.

While the PM works on drafting a project plan, the BA develops a BA plan outlining BA deliverables, communication patterns with stakeholders, requirements management approach and estimation of effort. The BA agrees the BA plan and Requirements Management plan with the PM.

Once the plans are agreed, the BA works closely with the project stakeholders on clarifying the business need, specifying high level business requirements, conducting stakeholder analysis, identifying risks, assumptions and constraints, as well as tolerances to a solution. The BA determines solution scope, high level requirements, solution approach, reusable and new components to be used in the final solution. The BA works closely with the PM to align solution scope with project scope. The BA informs the PM about all identified and potential risks.

The PM maintains the risk register and develops mitigation strategies for the identified risks.

The joined efforts result in two key documents: Project Vision and Solution Vision. The former contains the problem statement, desired outcome statement, acceptance criteria for deliverables, stakeholder analysis, business context, assumptions, constraints and scoping definitions (in scope/out of scope).

The latter describes the problem statement, solution statement, provides a solution overview, stakeholder summary (RASCI), determines “to be” capabilities and business context, defines what is in and what is out of solution scope.

These two documents support the Business Case document in medium and large projects, supporting project sponsor’s decision-making on whether to go ahead with the project.

The PM and BA work jointly on developing a WBS to ensure that the solution can be assembled in a way that enables cost efficiency and adherence to project time and resource constraints.

Project Execution

This phase flags even more close collaboration between PM and BA. They work together in requirements workshops to prioritise and validate requirements. They conduct workshops with vendors of components to the solution (where applicable).

Changes to solution scope lead to changes in project scope so the PM applies change management process to ensure that only justified changes will be accepted. The PM maintains the change request register throughout the project.

BA’s reporting on progress in turn supports the PM’s reporting on project progress to the project sponsor and other interested parties.

The PM supports the BA in communication with solution architects, software developers and other engaged third parties with regards to solution validation activities. The same is true when it comes to user acceptance testing. The PM’s support is invaluable here.  The duo works hard to ensure that solution acceptance criteria will be met within the predefined tolerances. The BA facilitates solution implementation to ensure a smooth transition to the “business as usual” mode.

Project Closure

Having the project deliverables accepted by the business, the PM works on closing the project. The BA facilitates the project closure by providing feedback for the post-implementation review. The BA reports on how well the solution met the business requirements. They jointly work on the Lessons Learned log to ensure that all valuable information has been captured for further use in future projects.

The BA hands over artifacts such as business requirements, functional requirements, use cases, non-functional requirements and solution technical specification to the business. These artifacts form a basis for business documentation on how to use the solution.

When the project has been formally closed, the BA files all approved BA artifacts in a central repository.

Pain Point

From observing over the years how different PMs tackle their projects, I would like to highlight some things that can trigger a blaming attitude.

A bossy attitude to a BA, a lack of understanding of the business domain, skipping important project background where the rotation of PMs takes place, “managing” customer expectations without involving the BA, expectations of having the final solution requirements identified by the BA after a single requirements elicitation iteration with project stakeholders – all these elements create a foundation for blame for not delivering on time and under budget.

Conclusion

The complexity of modern projects has increased to a great degree. Changes to business processes are coupled with changes to business applications, IT infrastructure, and interfaces with the company’s environment. The PMs and BAs are required to be more productive in projects of different nature. My experience gained from over 35 projects confirms that to deal with the changing demands and make projects successful, the BA and PM should work in tandem pushing towards the finish line.

Shared responsibilities, mutual respect and support combined with collaborative attitude pave a way to project success.

Don’t forget to leave your comments below.

Sergey Korban has been in the IT industry for over 25 years and has hands on experience in business analysis, project management and software development management. He is passionate about making businesses more effective. You can find more of his articles on the Aotea Studios blog  

Ten Reasons to Trash your Risk Management Plan

Written by George Bridges on . Posted in Articles. 4 Comments on Ten Reasons to Trash your Risk Management Plan

GB_Feature_WebDo you have a Risk Management Plan (RMP)? If you do not, then this article is not for you. If you are managing a project of any size and you have not developed a Risk Management Plan, then your project is most likely already in trouble.

If your answer is yes, then you may want to continue reading this article. Many people talk about and also attempt to develop a Risk Management Plan but either give up on it or place the effort in the low-priority to-do list. Others have a risk plan that does not actually provide the guidance and value that is needed to be effective.

Because the maker of the RMP did not give it the attention it deserves, it is usually thrown together without any real in-depth research, just to say that it was done. Like the son that was told to clean his room. When his mother checked it, the room was cleaned. But she later discovered that everything was piled high in the closet, out of sight and out of mind. It is important for the project manager and team to view the plan as something that can provide lifelong project value. All too often, project teams develop a Risk Management Plan because everyone says they should. It may be part of a methodology or a requirement within a Project Management Office (PMO) and is given cursory attention, something like punching a ticket or checking something on a list. Or they may have just passed the Project Management Professional (PMP) exam and know they need to have an RMP. So they do one! Why? To report that they have one and they can now tick that off of their checklist.

So, if you have an RMP, I give you my top ten reasons why you should trash that plan. Take a look at these and reflect on them.

Risk management is one of the nine knowledge areas of the Project Management Body of Knowledge (PMBOK®). Every management template includes an area to provide information about risk. Several books and articles have been written on the subject of risk management. Here are a few good books on risk management that you may want to read or add to your library:

  • Risk Management, Rita Mulcahy
  • The Practice Standards for Risk Management, PMI
  • Project Management a Systems Approach, Harold Kerzner

From a global perspective, more organizations are putting emphasis on risk management to assist in reducing the number of reported project failures. A well-developed Risk Management Plan should mitigate the risk for project failure.

For example, listed in the table below are the results of a poll from our project management website, allPM.com. In that poll, we asked for the top five documents needed for project success.

GB_Table_1_web2

As shown in the table above: The Risk Management Plan and Log is one of the top five documents needed for project success. Having a Risk Management Plan for your project is not optional; it is a necessity for the overall project success. The guideline and methodology we recommend for risk management is derived from the Project Management Body of Knowledge (PMBOK). In this article, we discuss some of the concepts regarding the creation and management of a Risk Management Plan.

Here are some ideas for creating and maintaining a good Risk Management Plan (RMP). You should start developing your Risk Management Plan during the early feasibility study. The RMP should be elaborated during the business case development process. Highlights of the RMP should be included in the development of the project description document and the project charter. The final RMP should be a part of the overall Project Management Plan.

A good Risk Management Plan and execution of that plan requires most of the team members to be involved. Collectively, the team will identify, analyze and develop the components of the Risk Management Plan.

A good outline of the PMBOK’s Risk Management Plan structure is shown in Figure 1.

GB_Table_2_web

I recommend a risk management plan be developed and acted on throughout the life of the project.

Here are the Top Ten Reasons to Trash Your Risk Management Plan

1. You should trash your RMP if you have not spent enough time or effort in developing the plan.

2. You should trash your RMP if your project is large and complex and you only spent a few hours developing the plan.

3. You should trash your RMP if the right people were not involved in creating the plan.

The project team can have the most brilliant people involved. However, if you missed a key stakeholder when identifying risk, you may have overlooked a key element in the plan that will cause the project to fail.

4. You should trash your RMP if the plan has been on the shelf for more than ten days.

A good plan must be reviewed on a regular basis. A Risk Management Plan should be reviewed every week and be a permanent part of every project management status meeting.

5. You should trash your RMP if you never talk about risk in your project meetings.

Every Project Manager (PM) should make it a part of their daily and weekly schedule to talk about risk. You cannot ignore this subject; the stakes are too high.

6. You should trash your RMP if your management only thinks of risk in terms of losing money.

Risk can be thought of as positive and negative. Management may need to be educated on the positive risk and how they can be managed.

7. You should trash your RMP if you have not done an exhaustive identification of all possible risks.

Rita Mulcahy, in her book, states that you should ID hundreds of risks in the early stage of your project. Not all risks will be part of the plan, but the exercise of finding and documenting as many as possible can benefit your project.

8. You should trash your RMP if you don’t know who to talk to about a risk.

There is a people side of risk management that we cannot ignore. Subject Matter Expert (SME), stakeholder and sponsors must engage in the conversation about risk.

Risk, issues and problems are discussed in the same context.

Risk and issues are different; they should be tracked and managed separately.

9. You should trash your RMP if a budget to handle risk is not established.

Your risk plan should be supported by a budget for risk response and contingencies. As PM, you limit your risk budget issues during the course of the project. The budget needs to be settled early in the project.

10. You should trash your RMP if you don’t know when to use quantitative methods to access the risk.

Risk Management may not include a quantitative analysis. Only in special circumstances will you need to invest the time and money in doing a quantitative analysis of your risk.

Summary

Are you doing risk management or are you just going through the motions? Risk management is just one of those things to do in your busy project environment. You know you need to do it right, but the urgency and priorities of other areas of the project do not allow you to allocate the time and resources to manage your risk properly. Therefore, you may want to trash your RMP and seriously do what’s necessary to manage the RMP correctly. I realize that it is hard to break away from day-to-day priorities. But if the RMP is done correctly, it will add value to your project. In the words of Nike, “Just Do It.” You will enjoy its benefits.

Don’t forget to leave your comments below.

George Bridges is a Director of Business Analysis with more than 25 years of experience in business systems analysis, business process modeling, operations research and Information Technology. George teaches business analysis and project management to hundreds of seminar and class participants every year. He has participated in the analysis and development of business systems for major corporations, such as Ford Motor Company, Unisys Corporations, and for a large church in the Metropolitan Detroit.

References:
1 – Risk Management – Tricks of the Trade for Project Managers, Rita Mulcahy, 2003
2 – The Practice Standard for Risk Management, PMI
3 – Project Management – A Systems Approach, Dr. Harold Kerzner

Would You Hire a Project Manager or a Business Analyst?

Written by Greg Geracie on . Posted in Articles. 3 Comments on Would You Hire a Project Manager or a Business Analyst?

Jan_25_Feature_Fotolia_28094822_XSIf You Had to Choose, Would You Add a Project Manager or a Business Analyst to Your Team?

This was one of several questions posed to a cross-functional panel of industry experts encompassing the product management, project management, and business analysis professions at Project Summit and Business Analyst World Chicago. The resulting dialog shed light on several topics that underlie current practices.

The panelists were George Bridges (GB), Director of Business Analysis at the International Institute of Learning, Greg Geracie (GG), President of Actuation Consulting, Frank Kowalkowski (FK), President of Knowledge Consultants, and Neal McWhorter (NM), President of Strategic Value Partners. The panel discussion was moderated by noted project management author Steven Starke.

Moderator (Steven Starke): Greg, let’s begin with you. If you had to choose between adding a project manager or a business analyst, which would you choose and why?

GG – As a product management professional and a frequent project sponsor, I tend to take a broader view of this decision. A good analogy might be an orchestra. Within the orchestra the business analyst would be a violinist creating wonderful music. However, the project manager would be the conductor. The business analyst is an important individual contributor while the project manager is in a leadership role within the context of the project team.

So, I’d lean toward selecting a project manager because project managers can ensure that whatever value is created by the team gets to market. The business analyst role can create a lot of value, but if the value never gets to market it’s like the proverbial tree falling in the woods – no one is around to hear it.

Moderator: George, which would you choose?

GB – I‘d choose the business analyst. This is a shift in the way I’ve traditionally thought about this issue. I’ve always believed that the project manager could manage the project and make sure they have subject matter experts and all the resources they need to complete the project. However, after listening to Dr. W. Edwards Deming’s presentation “Management’s Five Deadly Diseases,” my concept of the business analyst has changed.

I now believe that business analysis skills and assets reside in the analyst’s knowledge of the business. They need to be conversant about the business at every level of the organization, and this includes formal and informal communication with the executive management team. This is not to say that the project manager is not conversant; but the business analyst should know the strategic business objectives of the company. Business analysts with this knowledge create value for the organization and can justify those decisions to senior management. These are the main reasons I’d choose a business analyst.

FK – Steve, I’d like to add to George’s comments. I’d start with a business analyst because the first issue the team would face is problem solving. Once you get to a solution or a set of solutions, the project manager role comes into full play for effective planning and a cost/benefit analysis of alternatives. If the limit is one full-time person, I might consider having a contract business analyst followed by a contract project manager. Alternatively, one could hire the business analyst full time and add a contract project manager because they’re more readily available than a contract business analyst.

NM – As someone who has spent years helping organization build up their business analysis capabilities, I’m sorry to say that I’d have to choose a project manager. The rationale is pretty simple. With a project manager I have a pretty clear value proposition. I’m looking for an individual who knows how to identify and track issues and risks, can track resources and work dependencies to schedule effectively, and who can monitor time, cost, and quality to quickly identify when a project isn’t where it’s expected to be.

With a business analyst, I really don’t know what I’m getting. I might end up with someone who is little more than a scribe or someone who takes charge of delivering a holistic business solution. The skills and techniques could range from an expert facilitator to a subject matter expert to a process analyst to someone who is little more than a technical writer. While any particular individual could bring a valuable skill-set, the current grab-bag-like assortment of business analysts really makes it difficult to believe that the role means much as it stands right now.

Business analysts have the potential to deliver great value but right now they’re a pig in a poke.

Moderator: So it seems our panel is evenly split between adding a business analyst or a project manager. Since that’s the case, let’s find out what each of you perceive as the value of a business analyst.

NM – This question gets right to the root of the problem with the business analyst’s role. In many organizations, this role is considered that of a “translator,” “facilitator,” or “requirements document creator.” None of these terms has a direct link to business value. So the business analyst’s role is a hard sell. In some organizations Agile is a direct attack on the business analyst role because this kind of intermediary role is seen as overhead or – even worse –as a drag.

If I were a business analysis practice lead, I would be really working hard to define the specific business value that my group delivered and align my people to that. I think the best place to start is to focus on three roles for the business analyst: designing the technology-focused aspect of a product, creating technology-based capabilities that enable new products or significant changes to operational processes, and optimizing operational processes.

Unfortunately I don’t see a lot of organizations aligning their business analysis practices to this kind of value proposition.

GB –The business analyst should understand the business need, business capabilities, and range of available options and provide a robust justification for the proposed solutions. For me, there are several elements that define the business analyst’s value. First, they help define, manage, and control the scope of the product or solution. Second, as a dedicated resource, they communicate the urgency, value, benefit, and risk of the proposed solution. Third, they clearly elicit, analyze, document, and manage the project’s requirements. They also define the problem, get buy-in from stakeholders and the project team, and define and communicate the business solution.

GG – Like George, I believe the true value of a business analyst is their ability to correctly research business problems and develop solutions that address needs. When appropriately aligned with organizational goals, business analysts can create a tremendous amount of value. However, I think their full value gets diluted when they’re solely focused on internal initiatives. I believe business analysts could be aligned with product managers very effectively. This would further expand the scope of a business analyst’s responsibility outside of the organization and further increase the value of the role.

Moderator: Let’s move on to the project management role. I’m interested in hearing your thoughts about the value of a project manager. Who would like to go first?  

FK – I’ll go first. This one is pretty clear cut from my perspective. Project managers play the governance role of an asset steward. They’re responsible for keeping resource usage on track for a given initiative of the enterprise. As such, they take a proposed solution, develop the cost/benefit (or other type of value analysis), prepare a plan, monitor adherence to plan, take care of deviations, and minimize the impact of problems during implementation.

NM – I’d agree with the others and just add that the project manager can have a relatively wide range of value. There’s the traditional time, cost, and delivery tracking that is part of any project. But there’s a lot more to this role than simply tracking progress. A project manager adds real value when they can fully embrace their initiative’s goals. When this happens the project manager can help direct issue resolution towards outcomes that make well thought out trade-offs and prevent a project from being delayed and from straying from its objectives.

Moderator: George, what’s your take?

GB – The value of the project manager to the organization is their ability to effectively manage the competing demands of time, cost, scope, resources, risk, and quality. These six competing demands — along with customer satisfaction — are the basis for managing the success of any project. The project manager has to manage the inevitable tradeoffs associated with these competing demands throughout the project. Project managers coordinate all of the contributors to the project to deliver value to internal and external stakeholders.

PART 2 –

Moderator:  Now that we’ve framed how each of you perceives the value of project management, what is the biggest issue with the project management role today? Greg, how about going first?

GG – Sure, Steve. I think the greatest issue project managers face today is the possibility of being viewed as overhead. I’ve never felt this way, but I know that this is a risk in some organizations. This is particularly true of project managers that don’t effectively link the goals of the project to the company’s business objectives. Project managers really need to focus on correctly defining this linkage and ensuring that their projects demonstrate value to the organization.

Tied to this issue is the fact that too many projects don’t actually add value, are never cancelled, and sputter on consuming valuable resources when everyone involved in the project knows it’s a wild goose chase. It’s one of the most difficult aspects of a project manager’s job in my opinion – akin to telling the emperor that he has no clothes as the saying goes. But frankly, project managers must find creative ways to tackle these types of challenges.

Moderator: Frank, I take it you want to go next?

FK – Absolutely. I think the biggest issue relates to the type of problems project managers deal with. They’re more skilled at implementing a solution than solving business problems. This often depends on the industry. I’m actively involved with a lot of construction projects, and the project management role in these efforts is critical; construction projects require program offices with many project managers. In this setting, the central issues are consistency of project manager performance, skill level, and experience level. Many of the project managers that I see in that industry are Project Management Institute (PMI) certified.

In the computer applications systems space, I think project managers lack a good feel for the reality of gathering requirements and what’s needed to successfully manage product development projects. The technology field is less mature than the construction industry, and the skill level you’re managing is much higher than you typically find on a large construction project. So the issue is one of dealing with educated professionals.

NM – I’d add to Frank’s comments and say that the biggest issue for project managers today is that they are often little more than a project’s bookkeeper. For a project manager to create some larger value to organizations, they have to play a larger role in evaluating issues and risks. The project manager must evaluate issues for impact and resolve them, if possible. If this isn’t possible, the project manager must create a decision framework for quick resolution. If the issue is outside of the control of the project, then it’s a risk and the project manager needs to quickly identify and escalate this while they begin to develop risk mitigation plans. This is much more proactive role than most project managers are taking today.

Moderator: Let’s circle back to the business analyst. What’s the biggest issue with the role of the business analyst today?

GB – The biggest issue with this role is that it’s perceived as a new profession and isn’t as understood as it should be. The generally accepted practices are new to everyone and most of the enterprises see this role overlapping with the project manager and the system analyst. Business analysts are often not given enough time and resources to effectively do their job. The biggest challenge is simply gaining acceptance and anchoring the role effectively in the organization. Business analysts need the space to do their jobs effectively so they can contribute solutions that will meet company objectives and strategies.

GG – Although the International Institute of Business Analysis (IIBA) has done a good job of defining the skill set a business analyst needs, I think the biggest problem is that the role and responsibilities vary so widely among organizations. The act of business analysis is a component of almost any job inside an organization and I believe the roles of a business analyst should be more segmented. Thoughtful segmentation would give more clarity to all involved — from practitioners to hiring managers.

FK – Greg and I view this question similarly. I see the biggest issue as the definition of the role. The term business analyst is very general. There are many types of analysis, analysts, and analytics. The word analysis defines the domain or subject area that is of interest — like process analysis or financial ratio analysis. An analyst is the person who does the analysis — like the process analyst. And analytics are the algorithms you need to draw a conclusion from the analysis — like calculations. Our organization has listed more than 50 types of analysis that a business analyst might do and maybe 75 or 100 types of analysis. You can put the words analysis, analyst, or analytics after any one of the possible subject areas.

I also see another issue related to modeling. Many of today’s problems require different types of modeling such as decision structures, feedback models, dynamic models, management, and discipline models. I find that business analysts are good at interviewing and drawing diagrams, but not as effective at analyzing the problem. I think this reflects the current emphasis on business analysts doing application systems requirements and not really focusing on solving business problems.

Moderator: I’d like to conclude by asking each of you to look into the future. What does your crystal ball tell you about the business analysis or project management professions?

GG – I’m seeing greater emphasis on clarifying the role of business analysts. From the product management perspective, I can envision more emphasis on the product manager and business analyst relationship. I’ve always been a bit puzzled by the business analyst and project manager relationship, although I understand how it evolved. I think the common thread of creating value is a more natural linkage between the business analyst and the product manager, and I can envision a future where this becomes a preferred career path for a subset of the business analyst community.

GB – I see more project managers adding the business analyst skill set to their professional development by taking certification courses and training in business analysis. Some project managers may take on business analysis as a full-time profession. The same is true for senior business analysts. They may seek project management certification and take on project management full time. The roles will become more clearly defined and professionals will flock to the role that best meets their personal, professional, and organizational needs.

Some project managers will set aside their project management skills to learn the business and begin working in executive positions and provide business analysis to the organization. I see business analysis establishing their own department, where they’re not tied to IT or a particular business function. They will establish a business analyst Center of Excellence and offer independent objective solutions to the organization.

FK – The future business analyst must be much more versatile in applying problem-solving skills and techniques to the business. If they don’t, another discipline – like auditing – will take over the task. Auditing is already doing operational analysis because automation has decreased their role. And auditing can justify taking over the role because they have risk analysis experience related to process execution. So I see risk ahead for business analysts.

The future of project management may be a little brighter as the skills and methods seem to be better defined and I don’t see any other discipline interested in taking over.

NM – For the business analysis profession, I think the key will be whether it creates a single definition of business analysis. Business analysts must show a more direct relationship to value, or they face increasing marginalization.

Instead of the big tent approach to business analysis, I think it makes a lot more sense to break the role into different designer functions: process, product, business rule, content, etc. Successful organizations will find that moving the business analyst toward design roles that are aligned with concrete business value will yield real benefits. Organizations that don’t follow this path will likely view the business analyst role as overhead.

 Dont’ forget to leave your comments below.

7 Trends in Business Analysis and Project Management to Watch for in 2012

Written by Elizabeth Larson on . Posted in Articles. 5 Comments on 7 Trends in Business Analysis and Project Management to Watch for in 2012

Graph_PresentationThe close of one year tends to make one reflect on what has occurred in the past year related to and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:

    Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.

    • Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
    • PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.
    • Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

      In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

    • PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.

      The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

    • The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:
      1. Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
      2. Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
      3. In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.
    • BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:
      1. Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
      2. Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
      3. Post-project follow-up. We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.
    • The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.
      1. Travel budgets. Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
      2. Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
      3. Collaboration tools have made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.
    •  “The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools. 

     Don’t forget to leave your comments below.

    About the Authors

    Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

    Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

    Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

    Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

    The Rights and Responsibilities of Project Managers

    Written by Kiron Bondale on . Posted in Articles. 3 Comments on The Rights and Responsibilities of Project Managers

    FEATUREJan11thIn many organizations, project managers are the Rodney Dangerfields – they don’t get no respect!  We regularly experience the tug-of-war relationship between project and functional managers, but the same challenges often occur between project managers and their team members.

    Issues with this dynamic frequently stem from confusion related to their respective roles, but they can also be caused by a lack of understanding of basic rights and responsibilities.

    While these should all be common sense, to try to address this root cause, a review of some “generic” project manager rights and responsibilities may help. 

    Responsibilities:

    • Help team members understand the vision and objectives for the project and how its outcomes could benefit the organization and them.
    • Define objective expectations for a team member about how status updates, issues and risks will be communicated.
    • Walk team members through key project management artifacts covering scope and schedule so they can better understand how their work products fit in to the overall delivery of the project.
    • Actively engage team members in the project by involving them in scope definition, activity effort estimation, risk identification and analysis and any other appropriate planning (and re-planning) activities.
    • Challenge (or remove) unnecessary administrative hurdles from the path of team members to help them be as productive as possible
    • Provide regular, objective performance feedback for the team members to their functional managers
    • Regularly update team members on overall project status including expected outcomes and any approved changes to project objectives or constraints
    • Review the role of the project manager with team members so that they understand what is and is not “in scope”

    Rights:

    • Team members should keep the project manager apprised of changes to their availability
    • As per the defined and communicated expectations, team members should provide the project manager with progress updates, and any other information that is key to successfully managing the project including identified changes to issues, risks or scope
    • If the team member has concerns or confusion about their assigned work, they should communicate this to the project manager and get their assistance to resolve these in a timely fashion
    • If part of the team member’s role is to disseminate project information to their functional area, they should do this and not hoard knowledge
    • If the team member has an issue with another individual on the project team, they should first attempt to resolve the conflict directly with that team member, and if that does not work, they should engage the project manager to assist

    As Josiah Stamp put it best “It is easy to dodge our responsibilities, but we cannot dodge the consequences of dodging our responsibilities.”

    Don’t forget to leave your comments below.