Author: Elizabeth Larson

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is a consultant and advisor for Watermark Learning/Project Management Academy, and has over 35 years of experience in project management and business analysis. Elizabeth’s speaking history includes keynotes and presentations for national and international conferences on five continents. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 6 grandsons and 1 granddaughter.

A Project Manager’s Guide to Requirements Modeling

Written by Elizabeth Larson on March 17, 2015. Posted in Articles. 5 Comments on A Project Manager’s Guide to Requirements Modeling

We often get asked how project managers (PMs) justify allowing enough time to model requirements on their projects. These PMs complain that although they agree that requirements modeling has huge benefits, they have a hard time justifying the amount of time it takes. This article opens a series on requirements modeling with the emphasis on why PMs should care about modeling requirements. Each article looks at a single model, the benefits of that model to the project, the questions PMs need to ask related to that model, and how much the PM needs to understand in order to manage the requirements modeling activities.

What is a model? A model is a representation of reality, like a model car, airplane prototype, or graphical design (e.g., a CAD drawing) of a house. As they relate to requirements, models usually consist of text, graphical representations, or both. Most models have both diagrams and textual components. Text can be sentences (user stories), tables, matrixes, or lists, but words are the primary component. Diagrams (process models and use case diagrams to name a few) are usually visual methods of representing requirements. In software development there are several complementary models that help elicit requirements.

Models can be developed using a variety of techniques, including facilitated workshops, one-on-ones, prototyping, and others. An advantage of graphical models is that they can reduce the ambiguity when only text is used. We will review a number of different models in subsequent articles. Each modeling technique helps ask the clarifying questions needed to uncover hidden requirements. These techniques are interdependent and each is usually completed iteratively throughout the completion of requirements activities.

Why Model Requirements? In this series, we explore the relationship between requirements elicitation and requirements modeling, elicitation being about asking the right questions. We know that for our projects to succeed and for us to get the information we need to build our end-product, we need good requirements. To get good requirements, we need to ask the right questions. We need to ask both high-level consultative questions to determine the true business need, as well as questions about the features, characteristics, and functionality needed for the end product. We need to go beyond the “who, what when, where, and why” questions which, although helpful to start us out, rarely get to the detail we need. We’ll explore how modeling helps uncover requirements related to these product features and functions in each of the articles in this series.

In addition, there is risk associated with not getting good requirements. Reports like PMI’s 2014 Pulse of the Profession¹ points to the need for getting our requirements right and the high costs associated with not doing so. The Standish Group’s Chaos reports consistently point out the need for stakeholder involvement to get good requirements.²

Iterative elicitation and modeling. We can’t start out modeling requirements without some understanding of the end-product. Therefore, we need to ask enough questions to be able to develop an initial model of the requirements. Once we have a picture, or model, we can start to see the gaps in the requirements, gaps that will almost assuredly lead to additional questions. We call this process of asking questions and modeling requirements Iterative Elicitation and Modeling. Below is a figure illustrating this relationship between elicitation and modeling. It shows that modeling helps us to ask the right questions, questions we most likely wouldn’t think to ask. Asking questions, then, enables us to model the requirements. Modeling requirements, in turn, allows us to ask further questions and ultimately deliver the product that our stakeholders are expecting.

Figure 1 Iterative Elicitation and Modeling

What does this mean for project managers? Some project managers are directly involved in these requirements activities, and some are not. In either case, we have found that it is not uncommon for project managers to underestimate the complexity of business analysis work including elicitation and modeling. We think it important for project managers to understand the risk of not taking the time to use models to elicit requirements. Regardless of the role doing the work (project manager, business analyst, designer, developer, or whomever), and regardless of the project approach (Waterfall or Agile), the work needs to get done. It might get done by the development team during each iteration on an Agile project, or it might get done during the business analysis phase(s) or a more traditional project, but details of the end product are necessary in order to provide a product that will work for the stakeholders and be one that they want to use. In all cases, this work takes time and needs to be accounted for as the project manager plans the project.

So how do PMs justify taking time to model requirements? First, it is essential for project managers to recognize the importance of asking the right questions during elicitation. Next, PMs need to understand that if they don’t model the requirements, they will probably not be able to ask the right questions. Then PMs need to put time into their plans for these iterative elicitation and modeling activities. Finally, they need to articulate the importance of taking the time to do this work and the risk of not doing so when they think they don’t have the time.

Don’t forget to leave your comments below.

[1] PMI’s Pulse of the Profession In-Depth Report on Requirements Management http://www.pmi.org/~/media/PDF/Knowledge%20Center/PMI-Pulse-Requirements-Management-In-Depth-Report.ashx
[2]The Standish Group, http://www.standishgroup.com/sample_research

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 three books: The Practitioner’s Guide to Requirements Management, CBAP Certification Study Guide, and The Influencing Formula. She has also co-authored chapters published in four separate books.

Elizabeth was a lead author on the PMBOK® Guide – Fourth and Fifth Editions, PMI’s Business Analysis for Practitioners – A Practice Guide, and the BABOK® Guide 2.0, as well as an expert reviewer on BABBOK® Guide 3.0.

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 is a frequent speaker at Business Analysis and Project Management national conferences and IIBA® and PMI® chapters around the world. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored three books, The Influencing Formula, CBAP Certification Study Guide, and Practitioners’ Guide to Requirements Management.

What the 2015 Trends Mean For Business Analysis and Project Management

Written by Elizabeth Larson on February 11, 2015. Posted in Articles. 4 Comments on What the 2015 Trends Mean For Business Analysis and Project Management

In January we wrote an article like we do every year about the upcoming trends in business analysis and project management. In this article we want to discuss what these trends mean for practitioners of business analysis. Below are the seven trends we discussed in last month’s article and a short description of each.

Table 1 Seven Trends

Original 7 Trends	Short Description
Distributed leadership	Leadership will become more distributed and will be increasingly as much about tapping into the leadership of those around us as it is about a single visionary, decision-maker, and communicator.
Design	Organizations who start providing “logical” or “conceptual” design outputs as part of building apps and business processes will shrink the gap between business needs and functioning products and create better products faster.
Schizophrenic approach to certification	Both the trend to become certified and the trend to reject certifications will play out in 2015. With the increased popularity in MOOCs (Massive Open Online Courses), counterbalanced with the rise in the number of PMs interested in business analysis means that many practitioners will want certifications, while others will question their value.
Innovation and entrepreneurship	To go beyond mere process improvement, organizations will need to become more entrepreneurial. Innovation centers and hubs are on the increase, and companies are investing in their own incubators away from their main operations to help spur the creative process.
Changing culture through Agile team training	Agile training will be geared toward entire teams rather than individuals. Agile is going to drive organizations to seek more effective ways to generate a change in project practice. NOTE: we’ve expanded this trend to address the need to change organizational culture quickly. This is the focus of today’s article.
Balance in project governance	Organizations will continue to struggle to find balance between the extremes of project chaos and centralized project governance. Ultimately some projects will require more governance and some less.
Making Agile work for organizations	We predict that organizations will find a way to make Agile work for them by becoming more purposeful in how they choose to adopt it.

Helping organizations change – quickly. We believe that organizations are crying for new ways of doing things and that simply saying that they want to offer new products or services means ramifications greater than running a press release or having the CEO or agency head announce the decision. Many operational areas will often be impacted. People will have to learn new business processes, use new software, often buy new hardware, and sometimes report to new managers. They will have to learn how to sell, reorder, merchandise, and/or support the product or service. Often most challenging, though, is its acceptance, which requires changing the organizational culture.

Project managers will need to understand that the project’s focus has to be more than on implementing the new solution. Business analysis practitioners will need to help the organizations prepare for the change. They will need to work with affected operational areas to help them understand what the change means for them, the difference between their current world and how it will be different going forward. BAs and PMs have talked for decades about how slow it is to change organizational culture. We have used the analogy of trying to move a big cruise ship around in the ocean. Yet organizations need to find a way to change the culture more quickly.

Those who survive and thrive will have to be culture changers or contribute not just to helping organizations change, but helping them change more quickly. To help us understand this important concept, we have taken our 2015 trends and categorized them areas needed to enable change quickly. Those four categories are:

Distributed power. The first has to do with Power, the ability to impose our will—to get people to do what we want them to do. There are many ways people use power. We might threaten a punishment, offer a reward, or overwhelm them with what we know. We can use our authority, that positional power that comes from our place in the organization. (Well, some people can, typically not BAs or PMs). We can use all those forms of power, but none of them is affective as using our leadership skills, the power that we have within us to communicate our vision, to offer direction, and to have others follow us.

Distributed power means that organizations will have to accept that relying on positional power, in other words authority, will slow them down. The idea of power and decision-making in the hands of executives, directors, managers, or supervisors, or any one individual will cause delays. Going forward we expect that different people will take leadership roles at different times. Any individual might step up in a given situation, but not all situations. We’re saying that not only does leadership need to be distributed and more local, but power does as well. This might include, for example, the ability to reward people. Getting things done quickly will rely on decentralized project governance and self-organizing teams.
To use an Agile example, the scrum master might sometimes act as a leader. But if they do, it’s not based on their role, but on their ability to communicate with the team and the organization to remove impediments and resolve problems.

Practical solutions. Being innovative does not mean throwing out everything an organization does and starting over. Innovative solutions need to work. Organizations need to be able to implement them into their organizational cultures. Generally speaking, organizations are moving away from centralized project practices, one size fits all approaches in favor of choosing approaches best suited to each project. Top-down hierarchical communication is disappearing. Why? Because it takes too long to get anything done that way. Meetings need to be run more flexibly. Going fast are the old days of tight agendas where the meeting “leader” (usually us) controlled everything. Today’s meetings tend to be more informal, with neutral facilitators rather than meeting leaders, with participants scribing as needed, and where decisions are made more quickly.

Business analysis work is needed regardless of the project type. A rose by any other name is still a rose and business analysis is business analysis even if we call it systems analysis, business systems analysis, conceptual design, etc. We’re still doing business analysis when we manage requirements, do business systems analysis, design, logical or conceptual design, when we go about getting the detail needed, and whether or not it is done by BA, PM, designer/developer, part of the development team or someone else. And this work will not go away, regardless of the trend in development methodologies

Influencing without authority. Those who can’t influence will not add value and if they don’t add value, they will not succeed. Being innovative will require being able to influence those who don’t work for us. We will need to be collaborative and work through others to help organizations succeed.

The table below lists the seven trends and shows their relationship to the four categories. Each trend falls into multiple categories and each category contains multiple trends.

7 Trends	Distributed Power	Focus on the Practical	More Business Analysis Work, Less BA Role	Influencing Without Authority
Distributed leadership	X	X	X	X
Design		X	X
Schizophrenic approach to certification				X
Innovation and entrepreneurship	X	X	X	X
Culture changers needed	X	X	X	X
Balance in project governance	X			X
Anything agile	X	X	X	X

Summary. The key to being successful in business analysis and project management is to understand that business analysis is not going away, but how we do it is changing. To be successful we will have to offer quick, practical solutions. If our current job is to elicit and document requirements, it will decrease in value. If we’re project coordinators or schedulers, our jobs will also decrease in value. We need to get out of the business analysis and project management assembly lines. We need to spot opportunities and use our influencing skills to encourage organizational change needed to take advantage of those opportunities

So here’s the bottom line –we will have tons of freedom to be creative to do the right thing for the organization. It’s going to be easier for those of us who want to make a difference in our organizations and in the larger professional community to be able to do so. And this is very, very good news indeed!!

Don’t forget to leave your comments below.

About the Authors:

2015 Trends in Business Analysis and Project Management

Written by Elizabeth Larson on January 13, 2015. Posted in Articles. 9 Comments on 2015 Trends in Business Analysis and Project Management

Each year we like to reflect on what’s happened in the business analysis, project management, and Agile professions and make our predictions for the upcoming year.

To summarize the trends we saw in 2014:

Continued excitement about Agile projects with more informal communications and documentation and use of modeling tools to get from high-level user stories to detail needed to estimate and build them
Focus on Design
Cloud computing
Greater interest in business analysis by project managers.

Below are the seven new trends we see in the Project Management and Business Analysis fields for 2015.

Making Agile work for organizations. As the Agile bandwagon continues to grow, some organizations, previously reluctant to jump aboard, are running to catch up. Sometimes, though, Agile is implemented without much thought to unintended consequences of not having enough organizational commitment when adopting Agile. Although such things as not having dedicated teams, a dedicated business product owner, or extending time boxes to fit more work into an iteration sometimes works, there are often related issues, such as:
1. 1. Team burnout
  2. Less work being implemented
  3. Unmet customer expectations
We predict that organizations will find a way to make Agile work for them by becoming more purposeful in how they choose to adopt it. As a related trend, we think that some of the Agile purists will become more flexible, softening the “my way or the highway” approach in favor of one that is more collaborative. It means that organizations will have to articulate the business problem they are trying to solve by adopting Agile. In addition, those coaches who are accustomed to dictating what must be done will need to seek more organizational input.
Distributed leadership. Leadership will become more distributed and will be increasingly as much about tapping into the leadership of those around us as it is about a single visionary, decision-maker, and communicator. This idea isn’t new, but as organizations and project teams struggle with the adoption of Agile, coming to terms with what it means to be a self-organizing team will highlight the value of everyone stepping up to the role of leader.
In addition, the idea of leading for the purpose of developing relationships is going to be the focus of team building. Leadership is more than getting people to perform for the benefit of the bottom line. It’s about the people and connecting with them. Leaders are selected, recognized, and evaluated for their ability to sincerely tap into the human experiences their people represent. The intrinsic value of understanding others in order to establish meaningful relationships among team members, particularly those who are often physically distant, will be emphasized.
Innovation and entrepreneurship on the rise, and morphing. One can’t help but see books, articles, and blog posts about innovation these days. Not only our own industry outlets, but other media seem to have discovered the innovation “bug.” Many organizations will innovate through process improvement, and in some cases there is not much difference.
To go beyond mere process improvement, organizations will need to become more entrepreneurial. Innovation centers and hubs are on the increase, and companies are investing in their own incubators away from their main operations to help spur the creative process. Smaller, more isolated teams of “intrapreneurs” will provide the kind of “disruptive” break-throughs needed for true innovation and market leadership to take place. Savvy business analysts and project managers will step up to take on these entrepreneurial roles in organizations.
Business analysis as design work. As we mentioned in last year’s trends, the upcoming release of the BABOK Guide version 3.0 will awaken the “inner designer” in people doing business analysis work. There has long existed a gap between requirements and physical design. Organizations who start providing “logical design” outputs as part of building apps and business processes will shrink that gap and create better products faster. They will realize less rework by using standard models such as business process maps, use case models, prototypes and wireframes, state-transition, and sequence diagrams to name a few.
We have been promoting “logical modeling” for years and have been surprised that many organizations have not supported the design capabilities of business analysis. We see hope in the new BABOK and predict that organizations will at least consider changing their development processes to encompass more logical design. Smart companies will actually embrace the new design paradigm.
Struggle between centralized and distributed project governance. Organizations will continue to struggle to find balance between the extremes of project chaos and centralized project governance. We predict that in the near future organizations will continue to adopt an “all or none” approach to project governance. We see the era of centralized project governance, such as PMOs and Centers of Excellence, giving way to a more distributed governance, with some organizations letting individual project teams decide how much governance to employ. However, we know that when organizations move to one extreme to solve their problems, others are created. We predict that in the future organizations will take a more balanced approach and apply more governance for certain types of projects and less for others.
Schizophrenic approach to BA and PM credentials. We predict that both the trend to become certified and the trend to reject certifications will play out in 2015. With the increased popularity in MOOCs (Massive Open Online Courses), some from prestigious universities like Harvard and University of Michigan, learning about new topics and acquiring new skills at a low or no cost will appeal to many BAs, PMs and their organizations. To the extent that these new learning channels provide “just-in-time training,” they will reinforce the notion among some BAs and PMs that certifications and professional designations like PMP and CBAP are not an indication of competency and therefore not worth having.
At the same time, however, many PMs, BAs, and their organizations around the globe recognize that these credentials show knowledge gained and are an example of the initiative and hard work needed to get certified. We have seen large numbers of BAs eagerly awaiting the release of IIBA’s BABOK v.3, and many others are racing to be certified under the current release before the exam changes. In the PM space, we have seen a rise in the number of PMs interested in business analysis. PMI’s PBA as well as their ACP certifications are generating lots of interest that we think will continue to grow. Finally, there seems to be no slowing of interest in Agile certifications such as the CSM.
Team-based Agile training. Agile training will be geared toward entire teams rather than individuals. Agile is going to drive organizations to seek more effective ways to generate a change in project practice. The notion of sending an individual to training to become the internal evangelist is too much for a single person to do when it comes to the far-reaching culture changes required to implement A. Plugging into existing processes, tools, and infrastructure after traditional PM training is entirely different than expecting someone to come back from training and single-handedly explain and implement the why, what, and how of Agile. Expect more interest in generating internal momentum for change by sending teams to training who learn the why and how of self-organization. Training for entire intact teams is how organizations will get out of the gate and it’s more likely to be augmented by coaching and a follow-up with on-site presence to help as organizations figure out how to make Agile work for them.

Don’t forget to leave your comments below.

About the Authors:

Andrea Brockmeier, PMP, CSM, PMI-ACP, 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.

2014 Trends in Business Analysis and Project Management

Written by Elizabeth Larson on March 5, 2014. Posted in Articles. 3 Comments on 2014 Trends in Business Analysis and Project Management

anderson FeatureArticle June19 The close of one year tends to encourage us to reflect on what has occurred in business analysis and project management during the past year and think about future trends. To summarize the trends we saw in 2013, the need for project managers and business analysts to be trusted advisors and to influence stakeholders, whether on an Agile or more traditional project, has not disappeared. The same can be said for the demands to balance distributed teams’ needs for efficient and effective communication tools with organizations’ needs for consistency and security.

Below are the seven new trends we see in the Project Management and Business Analysis fields for 2014.

1. Continued frothing-at-the-mouth enthusiasm for anything “Agile.”

The “Agile” bandwagon hardly seems to be abating. Whether organizations have really adopted agile, or they have stuck their toe into the shallow end of the “Scrum-but” pool, appetites for big, waterfall-type projects have diminished all around. This concept is further reinforced in the PMBOK® Guide – 5th Edition, released a year ago, which identifies phase-to-phase relationship and project life cycle options that account for waterfall, agile, and everything in between. So even for the PMs who haven’t had exposure to a real agile environment, there is more comfort with the idea that many of the tools and techniques that have served them well in the past can be applied on all types of projects.

PMs will increasingly find it an easy sell to break projects into subprojects or smaller projects, whatever the project life cycle and approach. They know too well the cost of trying to define and control many large projects, and they know their stakeholders would rather see smaller deliverables sooner. It’s not agile, per se, but more, smaller projects will resonate strongly with stakeholders as they define what project success really means to them.

The BA world is equally rabid about Agile, seeing the release in 2013 of the Agile Extension to the BABOK® Guide, ver. 2. Version 3.0 of the BABOK due out in 2014 will have an Agile Perspective, and we won’t be surprised if IIBA produces an “Agile Practitioner” sub-certification akin to the PMI-ACP certification from PMI.

2. Use cases will enjoy a resurgence, particularly on Agile projects.

Five years ago we wrote that we expected “Slightly less reliance on use cases and more movement towards user stories.” While many traditional projects have favored the use case technique these past five years, it is only recently that we have noticed an upsurge in the interest in and questions about use cases on Agile projects. And no wonder use cases are gaining traction. User stories, the most common format for writing Agile requirements, are usually created at a high-level of detail. In order for the delivery team to estimate the story during sprint planning and then build the story, it often has to be elaborated in more detail. This elaboration, called grooming the product backlog, provides enough detail about the story so the team can move forward. This is not an attempt to elicit all the requirements up front, but rather to minimize delays caused by poorly defined requirements.

Many Agile teams are beginning to realize that an effective tool for this grooming is the use case, which provides critical information, such as when the user story begins, when “done is done,” and what criteria have to be met to be accepted by the product owner. They are also seeing the importance of the use case narrative in describing decisions and paths that ultimately lead to the navigation, edits, and messages required for software user interfaces. Sure, teams can obtain this information by impromptu conversations with the product owner, but many Agile teams are starting to realize that the use case structure is ideal for getting the user story done more quickly and completely.

3. Business Analysis Focus on Design.

A trend that will continue into 2014 is the notion that business analysis work involves design. Much of the BA’s work includes fashioning solutions, so it is natural to think of this as design work. To some extent the discussion is semantic, in that business analysis has long included design work but using different terms, like “to-be requirements” and “logical design.”

In developing the 3rd edition of the BABOK® Guide, due to be released in 2014, The IIBA® has given “Design” an equal place at the business analysis table. It describes design as “a usable representation of a solution.” (See the article on the IIBA web site.) The technical community may take issue with business analysts doing “design” work, but one thing is clear: the BA community is laying claim to part of the design space and we’re not looking back. Look for an article from us on this topic soon.

4. Increased use of the “cloud” and the need for business analysis in choosing cloud solutions.

Cloud computing will continue to have an allure of the promise to reduce investment in infrastructure and operations. However, it’s been a tense year for those monitoring data security and privacy. Organizations may be increasingly “angsty” about organizational and project information being stored “out there,” but the reality of needing to make information easily available to distributed team members is going to continue to trump those concerns for the coming year as project managers and teams increase use of the cloud for storing and sharing project data.

However, we believe that because of security concerns, organizations’ willingness to analyze their security requirements and to align those requirements to the potential cloud solution’s security features will grow, translating into the need for more analysis of overall requirements prior to investing in new cloud solutions. The growth of cloud technology has created a plethora of options for organizations, so in order to maximize the investment and achieve the greatest value, organizations will use business analysis to evaluate prospective cloud solutions.

5. Less email, more connecting.

The lack of employee engagement is a hot topic these days, and the costs are as significant for the projects in those organizations as they are for the organizations at large. Furthermore, many, if not most, projects use geographically distributed team members, making the obstacles to engagement considerable. We expect that project managers and business analysts are going to spend more planned time in the coming year making an effort to connect with stakeholders, including team members. Fortunately, the number of synchronous communication tools (audio and video) continues to grow, which will increasingly render email a less desirable medium. For those without access to new tools, this may be the year that picking up the phone finds new favor among team members. Overall, those who can let go of the perceived need to document every conversation will reawaken to the intrinsic benefits of communicating with higher-context media other than email which uses only the asynchronous exchange of written words.

6. Business analysis will focus on communicating first and documenting second.

More organizations are realizing that the business analyst brings more value to the organization when they have exceptional skills to listen, observe, question, and probe for the real needs rather than simply producing documentation. As we noted last year, these skills must also include the ability to influence stakeholders in order to get the participation needed for understanding and acceptance of the recommended solution. Further, they must be able to communicate the results of the analysis back to the stakeholders in a way that promotes understanding and gains acceptances and buy-in. We predict that more organizations will jump on the need for “just enough” documentation, realizing that great communication targeted to the group or individual will go much farther than a 500-page requirements document.

7. Project managers will focus on requirements management.

In 2009 we predicted: “There will be a greater emphasis on requirements in Project Management.” This focus has mushroomed during these past five years, in part because PMI has shown a greater interest in requirements activities. The continued expansion of the Collect Requirements section in the PMBOK Guide®– 5th edition, as well as the creation of the PMI Requirements Community of Practice with its numerous webinars and articles on requirements management, has encouraged project managers to become immersed in requirements activities. We anticipate that we will see a new Requirements Management certification from PMI. After all, since PMI has completed a role delineation study, can a related exam be far behind?

Don`t forget to leave your comments below.

About the Authors

Andrea Brockmeier is the Director of Training Services at Watermark Learning. She has over 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 is actively involved with the PMI® chapter in Minnesota where she has been a member of the certification team for many years. She has a master’s degree in cultural anthropology and is particularly interested in the dynamics of global, virtual teams.

Vicki James is the Director of Business Analysis for Watermark Learning. She is responsible for developing and maintaining Watermark Learning’s Business Analysis Training programs and serving as an instructor for both live in-person and virtual online classes. Vicki has more than 15 years’ experience in the public and private sectors as a project manager, business analyst, author, and independent industry consultant and trainer.

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.

Lessons Learned On Jury Duty Part 3 – Communicate the Plan and Provide Updates

Written by Elizabeth Larson on December 11, 2013. Posted in Articles. 7 Comments on Lessons Learned On Jury Duty Part 3 – Communicate the Plan and Provide Updates

This is the third and final part of a three-part series on the lessons learned from jury duty. In Part 1 I explored the analogy of potential jurors waiting for assignments to stakeholders waiting for their end product. In Part 2 I examined the importance of communicating the complete scope, and in Part 3 I will talk about the importance of communicating the plan. Communicate the plan and provide updates. What could be more obvious—right? Then why is it so hard?

Develop a realistic plan. I think many of us have been trained to develop a plan suitable to the project, but often our project management training is forgotten in the midst of impossible deadlines and unrealistic stakeholder expectations. Many of us are either overly optimistic (“oh this shouldn’t take too long”) or pessimistic (“let’s give them the worst case so we’ll look good”), when what most stakeholders want is for us to communicate what we know when we know it. Often our overly optimistic estimates come from too little detail in our scope and tasks. Our pessimistic estimates often happen when we assume every risk is likely to occur, so we build mitigating tasks into the schedule.

In my jury duty experience the courts had an abundance of optimism. We were constantly being told to return promptly at a given time, only to wait and wait some more. Sometimes we waited for hours. The worst day was when we were told to arrive at the courtroom at 9:00 in the morning where we waited until 10:30 and then told to take a break. We heard nothing until 11:45 when the court clerk told us to take a lunch break and to be back promptly at 1:00 PM. We were all back at 1:00 PM, but heard nothing until 2:00 PM, at which time the clerk told us that we would start in a half hour—a total of five and a half hours of waiting. From my viewpoint, it wasn’t the waiting that bothered me, but the lack of communication.

I’ve been lucky in that I’ve always found stakeholders to be reasonable. It seems to me that when I am not focused on process or methodology, when I communicate status, even when the news is bad, and when I offer alternatives, that sponsors and other stakeholders while not overjoyed, are understanding and appreciative of the communication.

Our best guess is better than no guess at all. Many of us are reluctant to provide dates to our business stakeholders. And there are many reasons for our reluctance, among others:

We are afraid our estimates will become commitments once they’re in the hands of our sponsors.
We don’t have enough information to estimate with any degree of accuracy.
We don’t have enough time to estimate with any degree of accuracy.

Although we often feel like we’re “flying blind,” or rushing to provide estimates based on little information, the fact is that we have more information available to us than our stakeholders have. Sure, we need to influence them to accept that estimates will change as we get more information. But our stakeholders look to us to advise them of the status and forecast of our project activities.

In my jury example, I did not expect the court clerk to provide us with accurate estimates, having realized long ago that the two words—accurate and estimate– shouldn’t be uttered in the same breath. Ideally, however, she would have provided us a time to convene and what to expect. For example, she might have said that we would convene at 9:00 AM and why it was important that we be ready, even if other court proceedings might preempt us. She might have told us that if there were delays, she would come and provide updates to us as soon as she could. She might also have told us that sometimes she would be involved in other cases that would delay her being able to get back to us. The more we knew about her job and its complexities, the more understanding we, the potential jurors, would have been.

How often should we communicate changes? How often should we provide updates? Whenever there is a significant change to what we previously said. When we provide updates, we are not contradicting ourselves. Rather, we are communicating what we know when we know it. But I have heard project professionals say, “Oh, I don’t want to overwhelm my stakeholders. I don’t want to give them too much information.” And I have heard stakeholders complain that they’re getting too much information. How do we know how much is just the right amount? Ask them, but ask them when planning the project—set expectations upfront. Let’s plan collaboratively with them. During the planning process let’s ask them their preferences for being updated. When we have to give unwelcome updates but also give advice on how best to proceed, we provide a really valuable service.

Don’t forget to leave your comments below.