Skip to main content

Tag: Business Analysis

The Courage to Scribe – 42’s Trusted Advisor

Larson May15ArticleRecently I saw the movie “42,” based on the true story of Jackie Robinson, who in 1947 bravely fought custom, bigotry, and violent hostility to become the first African American to play major league baseball. His courage came from his inner strength which allowed him to withstand with dignity the cruel behavior from fans, other team managers and players, and at first some of his own teammates.

As I watched the movie, I was equally taken with the story of Robinson’s “scribe,” Wendell Smith. Also an African American, Smith bravely fought many of the same obstacles as Robinson, but not as visibly, to become a respected sports writer who in 1994 was posthumously inducted into Baseball’s Hall of Fame.

Wendell Smith introduces himself to Robinson early in the movie as Robinson’s “Boswell,” a reference to James Boswell, the biographer of the 18th-century writer, Samuel Johnson. In his Life of Johnson, Boswell chronicles his conversations with Johnson written on their travels together. Like Boswell, Smith chronicles his travels with Robinson. The movie describes the relationship between these two black men struggling to do what each does so well; Robinson to play baseball and Smith to depict the fight to be able to play the game.

From the beginning, Smith establishes his role not only as “scribe,” but also as trusted advisor. He warns Robinson about the difficulties facing the baseball player. He describes probable situations and provides advice on how Robinson should respond. In preparation for those difficulties, Smith gives Robinson an abundance of advice not related to playing baseball, but how to react to the physical and verbal abuse he is likely to encounter. As is common with decision-makers when confronted with advice, Robinson often views the advice as well-intentioned but ill-conceived, so he often pleasantly ignores it, usually to his detriment.

Sometimes, however, Robinson reacts hostilely. Smith, who has also suffered race-related indignities throughout his career, reminds Robinson of the courage needed to succeed. As the trusted advisor, he encourages Robinson to use his strong moral character to avoid reacting violently to violence.

From HBO’s Game of Thrones, to Sam Gamgee in the Lord of the Rings trilogy, trusted advisors literally and figuratively take their life in their hands when providing advice that is clearly in the best interest of the decision-maker, but equally unsought and unwanted. Their advice is often neglected at best. At worst, decision-makers react with anger, or in the case of tyrants, even death. Yet despite the physical and/or emotional danger, trusted advisors do not often get much recognition. Writing about Smith, a Los Angeles Times post poignantly reminds us that “As Jackie Robinson was making history, Wendell Smith wrote it. Many fans remember Robinson and his struggle, but few remember Smith, who sat in the stands typing on a manual typewriter writing about integration on the field, while being barred from the press box because he was black.”

So what does all this have to do with the BA both as scribe and trusted advisor?

As with Smith, shunted off to the stands, we scribes are often shunted off to the back of the room. In virtual sessions, scribes are often forgotten and not even introduced. After the workshops, participants tend to remember who facilitated and participated, but not who scribed. Yet we scribes are, after all, the ones who have the greatest opportunity to create structure from chaos. Scribing requires us to actively listen, absorb, synthesize a great deal of information, and structure elicitation results, such as requirements, issues, workarounds, decisions, etc., into documentation that can be easily read, understood, and confirmed.

As scribes who are also trusted advisors, we often courageously go out on a limb by articulating the need for the role of scribe in organizations which don’t see the need, working with the project manager to account for scribing tasks in the project, and ensuring that the elicitation activity results are documented ethically. In addition, we need to speak up and be heard when remaining silent could jeopardize the accuracy of the documentation. As trusted advisors, then, we need to work behind the scenes to ensure that the organization provides strong, experienced skilled scribes.

Secondly and importantly, we may not feel like we’re in the center of requirement activities, but we really are. What will be remembered is dependent on the job we do scribing. Just as Smith “accompanied Robinson throughout his first major league season, creating his image, reporting his words and crusading for his rights,” we scribes accompany the facilitator, make sense of often rambling and contradictory discussions, while “crusading” always for the right thing for the project and for the organization.

Don’t forget to leave your comments below.

Bill Plaschke, http://www.latimes.com/sports/baseball/mlb/dodgers/la-sp-0414-plaschke-20130414,0,3199706.column, April 14, 2013, viewed on April 14, 2013.

2013 Trends in Business Analysis and Project Management

Larson FeatureArticle Jan23The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2013. This year we want to concentrate on trends for 2013 relating to an emphasis on competencies.

As people become skilled and certified, their base knowledge and abilities are in place. PM, BA, CSM, and BPM practitioners also need to apply their tangible skills to solving problems and helping our organizations achieve their objectives. For example, let’s say Jane knows how to model business processes and how to improve them. But, she may not always get time from stakeholders to understand their process, or establish trust with them to learn the root causes of process problems. She may also run into sharp disagreements about how a new process should be designed or conflicting priorities for what to improve first.

All of these common situations require various “competency” skills, which are often referred to as “soft skills.” We prefer the term “competencies” instead. The trend we’re seeing is that developing so-called “hard” skills isn’t enough. Organizations are now seeing the need to improve their workers’ behavioral-oriented competency skills at the same time.

So here are some competency trends that we see.

  1. Project professionals need to provide advice, not pushback. Several years ago organizations told us that they wanted PMs and BAs to be able to push back when their stakeholders asked for new requirements. Some of these organizations are now seeing that pushing back is one way to avoid being an order-taker, but it is less effective than providing well-analyzed advice. Our prediction is that more organizations will want PMs and BAs to be trusted advisors (sometimes called trusted partners).
  2. Organizations want scribes, not note-takers. LarsonJan22 Img1Although highly valued in ancient societies, today’s scribes are not always held in high esteem. Many organizations view them as nothing more than note takers, and what’s worse, that’s exactly how many view themselves. The trend that we are starting to see is the recognition that effective scribing is important to the quality of the requirements as well as the project itself. To be an effective scribe, project professionals need to use competencies, such as critical thinking to separate the important from the trivial, the ability to absorb and synthesize a great deal of information and make sense of it, and the ability to present the results in a meaningful way. We are seeing more organizations requiring these skills, particularly of their BAs.
  3. Organizations are beginning to recognize that agile projects require the ability to influence stakeholders.All roles on an Agile/scrum project, in particular the scrum master, the product owner, and the BA, need competencies related to being able to influence. We see some organizations beginning to recognize that each of these roles is distinct (e.g. rather than having the BA be either the product owner or one more member of the delivery team) and each needs to influence in different ways:
    1. Scrum masters: need to influence a variety of organizational stakeholders, many of who will have more authority than they. Scrum masters need to remove project roadblocks, which requires influencing sponsors and other executives, financial analysts, vendors, etc.
    2. Product owners need to influence other business stakeholders regarding the decisions they make as product owners. Whether prioritizing user stories or reviewing the product increment at the end of an iteration, product owners will need to be effective influencers. More organizations are starting to recognize that although product owners need to make business decisions about the product, they need to get buy-in from others affected by the product. Effective influencing is one of the best ways to achieve this buy-in.
    3. Business analysts need to influence just about everyone on an agile project. We are seeing product owners starting to recognize and appreciate the BA’s advice on prioritizing requirements, including impacts, dependencies, risks, etc. Scrum masters are starting to appreciate the BA’s advice on the myriad of issues that relate to requirements, testers on testing the requirements, and vendors on implementing software, to name a few. Again we’re seeing the dawning of this recognition in some organizations.

  4. Organizations are recognizing the cost of virtual teams
    LarsonJan22 Img2The communication overhead of working with offshore resources is getting acknowledged and accounted for more than in the past. Writing requirements for people onsite with whom there is the opportunity for face-to-face communication, as well as shared language and culture, is a leaner process than when writing requirements for people offsite. The cost savings of working with offsite/offshore resources has always been part of the equation for resourcing projects, but the cost overhead of working with offsite/offshore resources hasn’t always been as transparent. It can take many times longer to write requirements for offsite resources. Project professionals are becoming more diligent about identifying the costs incurred to deal with the time zone, language, and cultural differences.

  5. Productivity and speed require the use of disparate and uncoordinated social media and collaboration tools
    Until fairly recently, organizations wanted consistency. Consistency in their processes, consistency in their hardware, and consistency in the tools that were purchased to help productivity. The profusion of social media, collaboration, and communication tools continues. We are seeing that team members, particularly virtual, are making use of more and varied applications than ever and not always in a coordinated way. Do team members want a virtual bulletin board? Google it and myriad options come up – many free with few or no decisions required to install. It’s all very fluid. The integration of some of these things happens without even so much as a request. GoToMeeting just appears on a tab in GoogleTalk, for example. Nice. The continued pervasiveness of these apps in an increasingly distributed work environment is driving less standardized toolsets. You use what’s needed at the time, and if you need something you don’t have, click here. It’s free. It’s easy. Job done.

  6. Consensus is giving way to “productive conflict.”
    To the extent that the notion of consensus still implies (however erroneously) that everyone gets what they want, organizations are tiring of it. The idea of “productive conflict” holds more appeal. It’s not that organizations are losing interest in consensus, per se, but there is more emphasis on what comes out of the process than the process itself. And productive conflict may not run the risk of getting stuck, as so often happens when groups are trying to get consensus. Does this suggest that there may be some who aren’t in agreement? Maybe. But the trend we’re seeing is more organizations willing to pay that price in order to move forward.

Don’t forget to leave your comments below.

Andrea Brockmeier, PMP is the Client Solutions Director for Project Management at Watermark Learning. She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

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.

Terms, Terms, Terms. Clarifying Some Business Analysis and Project Management Terms

In order to clarify some basic concepts of business analysis and project management, we need to distinguish between terms that seem similar but are not. Below are some foundational terms and distinctions.

1. Project Management focuses on the work and methods to create new products. The Guide to the Project Management Body of Knowledge (PMBOK® Guide – Fourth Edition) defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”[1]

2. Process Management concentrates on the workflow and systems that recreate the products that sustain an organization.

3. Products. Throughout this article, we’ll refer to the end result of the project as the product. It can be a product, service, or any key deliverable that is produced as a result of the project. A few examples of products include a new bridge, a new methodology, landscaping, a project management office, a new car, a feasibility study, an HOV lane added to a freeway, a recommendation, a new or changed process, a new banking service, a new website, creation of a new agency, and a new marketing campaign.

4. Product Management uses processes and knowledge to manage product development, support, and marketing of the product. In this article, we cover the part of product management that occurs prior to deploying, selling, and supporting the end product. We focus on the work needed to define the requirements of the end product, to ensure that those requirements are built into the product and tested, and to ensure that the end product meets those requirements. Product managers exist in some organizations as the driving force behind new product development. They often define the high-level product requirements. In such organizations, this product manager often fills the role of project sponsor. See Table 1.1 for a summary.

Characteristic Projects Product
Requirements
Processes
Ownership Sponsor Sponsor Sponsor
Keeper or
custodian
Project manager Business analyst Business process analyst
Planning Project management plan Requirements management plan Documented processes
Execution Performing project
execution
Performing BA activities Performing the process steps
Closeout Project close and lessons learned Closeout of phase(s) & lessons learned Improved processes
Aligns with organizational vision and strategy? Must Must Must

 

Project, Process, and Product Requirement Characteristics

Projects are initiated in a variety of different ways, such as new government regulations, competitive market forces, and requests to enhance existing products. In other words, someone in the organization requests a new or changed product.

The person who initiates the request is called the sponsor. We’ll explain the full sponsor role later, but for now let’s think of the sponsor as the person who obtains the funds for the project and makes key business decisions.

Once the request has been approved, a project manager can be assigned to manage the project. Projects result in changed processes for an individual or group of individuals large or small. For example, a new bridge results in new traffic patterns and new processes for those taking the bridge. Landscaping requires processes to maintain it; the HOV lane requires new laws and new processes for use by drivers. A new computer system results in new processes for the end-user. Therefore, stakeholders affected by projects, processes, and products all need to be identified and kept informed of the project status. Figure 1 below shows the interrelationship of projects, processes, and products.
larson-Ba_12_shrunk

Figure 1: Projects, Processes and Product Requirements Interaction

Life Cycles, Phases, and Methodologies

Project Life Cycle. A project life cycle takes the project from its inception to its conclusion. In other words, each project is alive. It is conceived, born, it matures, and finally ends. Products have their own life cycles. Typically, product life cycles last longer than project life cycles, because in general the product outlasts the project. However, in the example of a lengthy feasibility study whose product is a recommendation, the life cycle of the project can last longer than the end product. Project life cycles are composed of one or more project phases.

Project Phase. The project phase,as described above, usually marks a milestone, at which point a deliverable is usually produced, reviewed, and approved. The business analysis phase(s), then, produces a set of requirements (features and functions) that must be reviewed and approved.

The names of the project phases do not have to be the same for each project. One organization may have projects in different divisions or business units or agencies, all of whom can have different phase names. Nor are there a set number of phases required for each project. For example, the number of business analysis phases for a software development project can vary, depending on the approach taken to business analysis and the phase-to-phase relationship used. The business analysis effort can occur during one project phase or over the course of many project phases. For example, iterative development of software projects occurs over several project phases, as could the piloting of new business processes. For a complete discussion of lifecycles and phases, please refer to the PMBOK® Guide – Fourth Edition, section 2.1.2.

Methodology. This prescribes how to get through the project life cycle, including the business analysis phase(s). It usually includes processes, procedures, forms, and templates for completing the project or project phase. Each project phase could, but does not have to, follow the same methodology. There are methodologies for completing business analysis, project management, product development, and testing to name a few.

Iterations, Increments, and Releases

These terms have created a great deal of confusion over the last several years. In the blog Don’t Know What I Want But I Know How to Get It, Jeff Patton uses art, movies, and pop music to explain the difference between “iterating and incrementing.”[2]

In a PowerPoint presentation, Managing Increments and Iterations with “V-W” Staging, Alistair Cockburn distinguishes iterations and increments by referring to increments as “build, deliver, learn, build, deliver, learn,” and iterations as “build, examine, learn, rebuild, ship.”[3] For another short differentiation, see Kevlin Henney’s article from December, 2007.[4]

Incremental development implies that new features and functions are added with each increment. For example, software can be developed using a plan-driven approach, with increments or new functionality added incrementally. Incremental business analysis implies that requirements are defined for an increment, and new requirements are added for each increment. Again, releasing in increments is appropriate for both plan-driven and change-driven approaches.

Iterative development implies planned rework. We expect the product requirements to evolve and change, so that change is viewed as part of the development process, not as a defect. Each iteration evaluates what has been built, and the product is rebuilt as needed. Iteration implies planned rework, because not only do we expect requirements to evolve, but there is a process to handle changes iteratively. Change-driven business analysis combines incremental and iterative requirements definition.

Product and Solution

Although the industry sometimes treats these two terms synonymously, we will use the term “product” for the end result of the project, and the term “solution” to mean the implementation of the requirements. The solution is a term used to describe a set of key deliverables that when taken together solve the business problem for which the project is undertaken.

Here are some examples.

  • The productof a project is a new marketing campaign. One solutionmight be to hire a consulting firm to produce the campaign. Another solutionmight be to have the advertising department develop it.
  • The productof a project is a new piece of software. One solutionmight be to build the software. Another solutionmight be to buy it from a vendor. Yet another solutionincludes new software, new hardware, and new processes.
  • The product of a project is a new order replenishment system. One solution might be the software, hardware, new and changed processes, and a recommendation on whether or not the organization is ready for the change. The requirements describe the features, functions, and capability of the new system. The deliverables (work products) from business analysis include a business requirements document, a recommendation on new hardware, a model of the future processes, and a recommendation on a new organizational structure for the affected business units. The order replenishment system alone will not solve the business problem, so the solution has to include more than just the system. This solution may involve many projects, each of which will have products.

Summary

Making distinctions in terminology is important for both planning and execution of projects, and common language can help reduce misunderstanding and miscommunication. When everyone understands the underlying concepts of business analysis and project management and uses the same terminology, they can complete the work more productively and with less conflict.

Don’t forget to leave your comments below


Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).


Management Institute. A Guide to the Project Management Body of Knowledge, Fourth Edition (PMB[1] Project OK® Guide). Newton Square, Pennsylvania: Project Management Institute, 2008. p. 435.

Patton, Jeff. “Don’t know what I want, but I know how to get it.” Agile Product Design. 21 Jan. 2008. <http://www.agileproductdesign.com/blog/dont_know_what_i_want.html>.

Cockburn, Alistair, “Managing Increments and Iterations with ‘V-W’ Staging.” <http://alistair.cockburn.us/>.

Henney, Kevin. “Iterative and Incremental Development Explained.” Search Software Quality. 3 Dec. 2007. 29 Jan. 2009 <http://searchsoftwarequality.techtarget./news/article/0,289142,sid92_%20gci1284193,00.html>.

Trends in Business Analysis and Project Management to watch for in 2009

The close of the year tends to make one reflect on the past and ponder the future. Here we ponder some trends in the business analysis and project management fields for 2009. We invite you to read some of these trends and ponder for yourself our views about what project professionals can do about them.

  1. Convergence of PM and BA Roles. As the economy tightens, organizations will decrease their project budgets. But, they still need projects done, so look for organizations to try and combine the role of the BA and PM on projects. A recent survey on BA Times finds that an equal number of “project professionals” (our term to encompass both project managers and business analysts) feel that the PM and BA role will be combined on many projects in 2009. Project managers will be asked to do more requirements elicitation and analysis. Business analysts will be required to manage more projects. Oh, and by the way – you will need to do that in addition to your normal roles!

    What Project Professionals can do about it: If you are a project manager, sharpen your requirements elicitation and analysis skills. If you are a BA, learn how to plan and execute projects better, and to manage risks. The other advice we can give is “Concentrate on the work, not the worker.” No matter what your job title, make sure you know the tasks and outputs expected of you to help achieve project and business success.

  2. Greater Emphasis on Requirements in Project Management. The upcoming 4th edition of the PMBOK® (Project Management Body of Knowledge) is due to be released in 2009. The Project Scope Management Knowledge Area contains a new section 5.1 called “Collect Requirements” that was largely written by us (Elizabeth and Rich).  It contains a number of requirements elicitation techniques that project managers should be able to use to elicit requirements for projects. They are a subset of the techniques described in the Business Analysis Body of Knowledge (BABOK®), so BAs also need to be familiar with these. The section places an emphasis on the Requirements Management Plan and use of the Traceability Matrix for managing requirements and product scope.

    What Project Professionals can do about it: When the new PMBOK® Guide becomes available, make sure you obtain it and read the section on Collect Requirements. It’s not because we wrote much of it (well, we are proud of it!). Both PMs and BAs should be aware of what this widely-used and referenced guide says about requirements. The PMBOK® has heavily influenced the practice of project management the past several years, and the new edition promises to do the same. 

  3. Change in Requirements Approaches. We see a continued trend in business analysis techniques continuing into 2009. Here are some to consider:
    1. Slightly less reliance on use cases and movement towards user stories and scenario-based requirements. Use cases will still be used, especially with complex requirements with intricate interfaces or tricky infrastructure considerations.
    2. Less emphasis on requirements specifications, more emphasis on modeling, prototypes and diagrams. For many reasons, there is a trend away from only formal written requirements specifications. That doesn’t mean written requirements have no place, but it does mean the industry is using additional methods of documenting requirements. 
    3. More requirements management. To control scope and fulfill business needs, there will be continued increase in business analysis and requirements planning in 2009. We see more and more organizations using traceability to control and manage product scope. Both the upcoming PMBOK® and current BABOK® feature this technique and emphasize the use of a traceability matrix.
    What Project Professionals can do about it: Keep using use cases, but bear in mind there are other good requirements analysis techniques. Supplement your requirements specifications with models to document and help you better analyze requirements. Learn about other methods, such as user stories and use the technique most appropriate for the type of requirement you are analyzing. For example, do data modeling for refining your data requirements.

  4. Increased use of Agile Approach and Techniques. 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 as organizations adopt Agile techniques and the industry adopts commonly accepted practices. Agile itself is evolving to the needs of the industry. For example, the need for more planning has been recognized. For instance, the concept of “Scrum of Scrums” to coordinate Agile teams has surfaced. Another trend we’ve noticed is Agile teams incorporating traditional techniques like requirements workshops and more documentation.

    What Project Professionals can do about it: Like any new approach, make sure you learn the generally accepted practices, not just the way a consultant or a single “expert” advises. There are many self-proclaimed experts out there, and some shortcuts on planning and requirements are being taken and justified by being called “agile.” 

  5. BABOK® continuing to have an impact. The practice of business analysis is being positively influenced by the Business Analysis Body of Knowledge (BABOK®). The BABOK® Knowledge Areas of Enterprise Analysis are beginning to gel in organizations, as is the need to do requirements planning. We’re seeing more formality and standardization in the methods, say, of doing business cases, or using traceability to manage requirements. 

    Also, the various elicitation techniques in the BABOK® area are being more widely adopted. Interviews and requirements workshops are common forms of elicitation, but we feel the BABOK is influencing BAs to use additional techniques such as prototyping and interface analysis and to include them in their requirements planning.

    What Project Professionals can do about it: Download the BABOK® from the IIBA and start reviewing it. Use it as an input to recommending business analysis standards in your organization. Being some of the firsts CBAPs (Certified Business Analysis Professionals), we believe in and urge others to pursue certification in business analysis. It helps promote the profession of business analysis in general and helps you to solidify and integrate the tools and techniques in the BABOK®, and to “personalize” them to your organization. 

  6. Business Intelligence Continues to Grow. This area of information systems has been growing steadily and 2009 promises to have no letup. As BI tools and techniques improve and solid benefits are realized, organizations will invest more and more in this tactic. Since BI relies heavily on tools such as Business Objects or Cognos, the underlying business requirements can be easily overlooked in favor of what the tools can produce.

    What Project Professionals can do about it: Learn how to identify how BI can help your business perform better. BI applications should be actionable and project professionals should focus on true business requirements instead of particular tools. Learning to ask the right questions is key, and anticipating how clients will use their data, although challenging, is well worth the effort. 

  7. “The Economy, Stupid,” as a past political slogan said. A slumping economy tends to affect travel and training budgets, and this one is no exception. That translates into fewer trips to national conferences or travel to out-of-state training classes.

    What Project Professionals can do about it: Attend local conferences that you can drive to.  Many local chapters of PMI and now IIBA are launching Professional Development Days or PDDs. Watch for announcements to these and plan to attend. If you have a conference such as Project Summit/Business Analyst World in your town, take advantage of the opportunity and you will find excellent speakers and workshops there. Have you noticed the big increase in webinars as a way of exchanging information and interacting virtually without travelling? Watch for more of the same in 2009. We plan to offer regular webinars throughout 2009.

    Interestingly, national conferences like the PMI Global Congress North America attracted many foreign workers this year, from expanding economies such as Brazil and Russia. These growing countries will have larger travel budgets than some of their US counterparts. We also see continued rising international interest in PMI and IIBA.


Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at
http://www.watermarklearning.com/.