Author: Elizabeth Larson

Elizabeth Larson, has been the CEO for Watermark Learning as well as a consultant and advisor for Educate 360. She has over 35 years of experience in project management and business analysis. 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 the several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, and spending time with her 6 grandsons and 1 granddaughter.

Is Your Organization Agile-Ready? Part 2

Written by Elizabeth Larson on November 2, 2010. Posted in Articles.

Last month’s blog was the first in a series about organizational readiness-ready, that is, to provide resources necessary to succeed in an agile environment. We asked these four questions on our Agile organizational readiness checklist:

Will your organization provide a dedicated product owner for each scrum team?
Will your organization provide dedicated team members?
Does your organization support time-boxing each iteration?
Does your organizational culture support just-in-time requirements?

This month we’re going to look at Agile organizational readiness from the perspective of false expectations for some organizations that have decided to implement Agile methods.

Does your organization support “cowboy” development?

Some organizations adopt what they call an “agile methodology” as an excuse to eliminate discipline, commitment, and ownership. They have the mistaken belief that a lack of discipline equates to getting the work completed sooner. In some organizations senior leadership decides to adopt “Agile” without understanding what it entails and the commitment that is required to make it work effectively. The term “Agile” becomes an excuse for adopting a chaotic, free-for-all environment. Management in these organizations can boast that they’re “doing Agile,” but might not be aware of the frustration such a chaotic environment causes the team.

Does your organization expect that eliminating the role of the BA will eliminate documentation?

I have heard organizational leaders say something to the effect of “we’re going Agile so we no longer need a business analyst” or “don’t put a BA on this Agile project. BAs will just produce a mountain of unnecessary documentation.” They see business analysis as unnecessary work and the BA as a role whose only goal is to produce a massive requirements specification at the end of one long business analysis phase. In reality, the business analyst is a kind of management consultant, someone who acts “as a liaison among stakeholders ..to recommend solutions that enable organizations to reach their goals” (BABOK Guide ® Version 2.0. As wonderfully articulated by Kevin Brennan of the IIBA, organizations which undertake Agile projects still need help understanding their underlying business problems and figuring out the best ways to solve them. They still need projects to help them solve those problems. And they still need a role that will focus on the requirements of the end product (solution), ensuring that the end result of the project provides the expected business value. In other words, the role of the BA is not to produce documentation, but to help ensure that the end product and its associated requirements help the organization reach its goals. In that capacity, every BA is obligated to produce documentation as appropriate to the project at hand.

Does your organizations have realistic expectations of the Scrum Master?

Does your organization expect the technical team “leader?” to be the Scrum Master, providing technical expertise and direction to the delivery team? Having any formal lead role on the Scrum project is problematic. When teams are truly self-organizing as ideally they are on Scrum teams, leaders emerge, rather than being designated. In addition, any time that the Scrum Master spends focused on the technical aspects of the project and directing the delivery team is time not being spent on facilitating, removing roadblocks, calculating the resource capacity and burn down rate, and generally doing the work that Scrum Masters need to do. There is a reason why on some Agile projects the role is called “coach,” not leader. Finally, the Scrum Master who works as the technical lead is at risk of providing a more a technical rather than a business solution.
Does your organization expect the Product Owner to be the Scrum Master? The Product Owner (PO) is a critical role on an Agile project. It represents the business, making the business decisions required to move forward developing the end product. Last month we addressed the importance of having organizational commitment for a full-time PO because it is a full-time position. When the Scrum Master is doing PO work, the Scrum Master work is not getting done. And the decisions made run the risk of ignoring important technical considerations.
Does your organization expect the Scrum Master to play other roles such as business analyst? I attended a presentation recently promoting the idea of BA as Scrum Master. The central theme of the presentation was that because both Scrum Masters and business analysts are facilitators, the BA is in the best position to be the Scrum Master. I found the premise intriguing and well-intentioned, but misguided. The facilitation that is required of a Scrum Master is different from that of a BA. The former focuses on facilitating the team and its ceremonies, the latter facilitating requirements workshops among subject matter experts. And there is vastly more to both roles. It’s almost like saying that because an insurance agent, a bank teller, and a city ombudsman all interface with customers, that one could easily step into any of the other roles.
Does your organization expect the Scrum Master to play multiple roles? All but the smallest Agile projects deserve full-time Scrum Masters. Organizations which believe that they can get by “on the cheap” by combining roles on Agile projects may well suffer disappointment in the results that get produced. As on any other project, each will suffer.

There are many more areas that we could cover, but we’ll leave it for now in the hopes that you’ll add your own ideas and experiences to the topic.

Don’t forget to leave your comments below

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

Written by Elizabeth Larson on October 12, 2010. Posted in Articles.

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.

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>.

Is Your Organization Agile-Ready? Part 1.

Written by Elizabeth Larson on October 4, 2010. Posted in Articles.

Lately I’ve been getting questions from Agile seminar participants about how to apply Scrum to “real life,” as though these methods are “good in theory, but not at my company!” Some organizations may not be ready to adopt agile methods completely, so I encourage students to take an organizational readiness self-assessment to see if Agile in general and Scrum in particular is right for them. The questions on the self-assessment can be used to begin conversations as a way to raise issues that need to be resolved in organizations thinking about adopting Scrum.

Will your organization provide a dedicated product owner for each scrum team?

A key role on a Scrum effort is the product owner (PO). This is the role that represents the business community, particularly the project sponsor (sometimes called business owner or the stakeholder), and therefore is tasked with answering the business questions and making the business decisions. This is the go-to person for the requirements, for answers to the team’s questions about the features and functions that the business wants out of the end product. This is also the role that prioritizes the items on the product backlog. It seems to me that in the heat of the iteration or sprint, the team needs immediate access to the person making the business decisions. In order to complete the sprint in a short time-frame, such as two weeks, the team cannot wait for the PO to get back to them at their convenience. They cannot wait for the PO to check with other SMEs to come to consensus. The team needs immediate answers. Having a dedicated PO is critical to the success of a scrum team.

Will your organization provide dedicated team members?

Many organizations allocate resources to multiple projects. I often get the question “do the team members ever work on multiple projects in Agile?” When I answer that, in order to complete sprints every few weeks, it is necessary to have dedicated resources, I often get pushback. “Everyone at my organization,” I’m told, “has to work on multiple projects.” In some organizations the motto is “we’ve always done it that way” but we want you to do it faster, which we’re going to call Agile. But you need to continue to do things the old way.

There are huge advantages to having a dedicated team, such as time wasted trying to keep track of where we left off another project or dealing with team dynamics that are wildly different from one team to another. It is hard to create a self-organizing team when members float from one team to another. And team members who have been part of a high-performing, self-initiating, and self-motivated team, all of whom do whatever is needed to get the job done, rarely want to return to a more traditional team. This is particularly true when they have to jump back and forth between the two.

Does your organization support time boxing each iteration?

One of the most frequent questions I get asked is “are Agile time boxes fixed,” going on to explain that at their company the powers that be keep adding features that extend the number of days in the sprint. In these organizations the time boxes become fluid and it’s hard to plan what can get done during the sprint. In order for a team to establish its velocity, that is, how many user stories can get completed during a sprint, it is necessary to have a fixed number of days in each sprint. Organizations insisting on throwing additional features and extending the current sprint may not be ready to take full advantage of Agile projects.

Does your organizational culture support just-in-time requirements?

Organizations that have a one-process-fits-all set of business analysis processes might not be ready for an Agile environment, particularly when those processes have proven burdensome for some projects. I have worked with clients who have proudly showed me their new requirements process. Some of these companies do not differentiate between project types, approaches, and final product, so that the processes for developing software are the same as for new processes, and new product development, marketing campaigns, new bridges, etc., and processes for large projects are the same as for small ones. On the flip side, teams often struggle when organizations don’t recognize the importance of requirements, or the role of the business analyst, or why we need any requirements processes at all. In these companies, doing just-in-time requirements means moving straight to design.

Just-in-time requirements mean that requirements for upcoming sprints are defined completely before the beginning current sprint. One clear advantage is that when requirements are “groomed” or defined before each sprint, time is not wasted during the sprint trying to figure out what each user story means. The PO does not need to take time away from the Team to meet separately with other subject matter experts (SMEs) to uncover needs and expectations. That work has already been completed. As I’ve said in past blogs, who is better to groom the backlog than the BA?

Next month we’ll explore other questions that organizations can use to help them decide whether they are ready to make the necessary commitment to ensure the success of agile adoption.

Don’t forget to leave your comments below

Be Satisfied with what I Give You-It’s Better than what You Asked for

Written by Elizabeth Larson on September 7, 2010. Posted in Articles. 1 Comment on Be Satisfied with what I Give You-It’s Better than what You Asked for

My husband and I usually stay in hotels on vacation and sometimes our expectations, those unspecified requirements, are not met. This blog deals with two aspects of unmet expectations: unwanted features and making changes.

Unwanted Features

How many of us are universally delighted with every room assigned to us? Recently, despite asking for a quiet room with a king-size bed (my husband is 6’3″), we were assigned a room with a double bed facing a busy, noisy street. When we asked to change rooms, the front desk clerk sighed with disgust and said, “But we gave you a suite.” We didn’t ask for a suite. We asked for a quiet room with a king-sized bed. We got features we neither wanted nor asked for and didn’t get features that were important to us. Clearly in the clerk’s mind the suite was more valuable than the features we requested.

I suspect many of our sponsors and other stakeholders end up with features they don’t want without getting the features that are important to them. Years ago I was a banking officer implementing a new teller system. I provided my requirements during a series of meetings with IT. When the design was done I was presented with a series of “wouldn’t it be great if the system could do…” “Yes,” I responded, “it would be great as long as it allowed automated teller balancing.” “Well, no,” I was told. Tellers would still need to follow their current, cumbersome process.

More recently I spoke with an executive involved in a project where she had only one requirement-new information, currently captured, on a current report. When the requirements package was presented, the report was missing. When she questioned what happened to the report, she was told about all the wonderful features and functions the system would provide. But her report was still missing, despite assurances from the sponsor that it would be included.

I’m sympathetic to the business analysts and project managers who want nothing more than to provide outstanding customer service to their stakeholders. I totally encourage project professionals to recommend new direction, new features and functions, new processes, etc. as long as these recommendations include an analysis of the problem, a recommendation to solve the problem, and the benefit of solving it.

Where we get into trouble is by presenting solutions that the sponsor and other stakeholders don’t ask for. During business analysis we sometimes ask leading questions which are less questions and more presenting solutions to unidentified problems. Questions such as “Have you ever thought about…” or “Would you ever consider…” are examples. Even worse is when we think we know more than our stakeholders. We add features that we think are cool or even necessary and include them as requirements, without first checking with the business stakeholders to make sure the business values and is willing to pay for them.

Making Changes

My Uncle Bill used to tell us that no matter what type of hotel or where it was located, no matter how many of the hotel staff he talked to in advance of their arrival, Aunt Roslyn would look at the assigned hotel room, find it inadequate, and request a change of rooms. When we were younger, we always felt sorry for Uncle Bill. How patient, how long-suffering he was to put up with the inevitable bother of changing hotel rooms.

However, as we’ve aged, my husband and I find ourselves changing rooms more frequently. After the above-mentioned front-desk clerk tried unsuccessfully to convince us to stay in the suite, he told us respectfully but firmly that no other rooms were available and change was not possible. In desperation we agreed to pay a fortune to upgrade to get what we originally asked for. Nevertheless, the clerk appeared unhappy. Clearly, the change request was an anomaly and upset his process.

I suspect that many of our sponsors and other business stakeholders are reluctant to request changes because of our body language, because of a burdensome change process, or because they are used to being told “you can’t have that change. It’s out-of-scope.”

In looking back, it seems that we’ve been less likely to change rooms when we’ve taken a virtual tour of the hotel prior to booking a room. Unlike photos taken at just the right angle to make a tiny, bare room look cozy and comfortable, a virtual tour provides a broader perspective of the room in relationship to the rest of the hotel. Pictures provide a structure for us to help the stakeholders discover their requirements, and one of the best ways to provide pictures is prototyping. Unlike static screen shots or wire frames, prototypes that allow our business stakeholders to “use” the end product help elicit not only their requirements, but also those hidden expectations. Even when the prototypes are low tech rough drafts drawn in PowerPoint or on easel pads, they are an effective elicitation technique.

I’m not sure much will change on future vacations. But that’s OK. Few hotel clerks are as crabby as the one above. We have generally found them to be friendly and flexible, like most of the project professionals we worked with as well.

Don’t forget to leave your comments below

Five Rules for Project Success

Written by Elizabeth Larson on August 10, 2010. Posted in Articles. 1 Comment on Five Rules for Project Success

Based on the Children’s World Cup Soccer Rules

I am not a big sports fan. My husband is an avid fan of baseball and American football, but I usually go about my business despite the frequent exclamations of euphoria and despair that reverberate throughout the house during sporting events. But a recent visit with our grandsons raised my interest in one sport-soccer (football). Having recently played World Cup soccer with four grandsons aged 8-2, where the rules were emphatically if inconsistently enforced, I thought about how these children’s rules apply to projects. Given my lack of knowledge about the real World Cup rules, I don’t have the slightest inkling of whether these kids’ rules even come close to reality, but they seem to work. So, at the risk of overusing the myriad analogies relating to children’s play to projects, here are five Kids’ World Cup Rules for successful projects.

Rule #1: Define the goal and how to reach it. In our kids’ game the goal kept changing. That is, how a goal was achieved was fluid. If the ball was kicked inbounds but bounced off the pole it probably didn’t count as a goal. Sometimes a goal could be scored by kicking the ball under the table, sometimes by missing the table entirely. On our projects not only do we need to have clear, unchanging business and project objectives, but we need a clear plan for how to get there. If either the goal or the set of project management and business analysis processes vary too much, the players will be confused, frustrated, and ultimately unsuccessful.

Rule #2: Focusing too much on the goal at the expense of your opponent can get you a yellow card, which is like a strike in baseball. Three of them and you’re out, according to the Kids’ Rules. The grandsons loved marching around the field silently carrying a small yellow block when an infraction had occurred. In soccer we need to get the ball from our opponent in order to make a goal, but not by infringing on others. Many project managers focus on meeting the project objectives without paying enough attention to our “opponents,” those who are not supportive of the project. Perhaps the project goals and objectives are at odds with their own, perhaps they are uncomfortable with our project processes or they don’t like the sponsor or other stakeholders, perhaps the end result of the project means that they that they will have to learn new processes, no longer be experts, have to learn how to use new systems or products, or perhaps even lose their jobs. There are lots of reasons why some stakeholders may not want to support the project. However, it is vital to recognize the stakeholders who are our opponents and develop strategies to bring them on board.

Rule #3: The red card-means you’ve really messed up and you’re expelled from the game. Fortunately our grandsons were not cutthroat and red cards were not abundant. On projects expulsion can happen when trust has been broken. Sometimes we don’t even know that we’ve been expelled. But if we feel like a pariah, or if a lot of communication is going on behind our backs, or if our team seems less motivated, if subject matter experts (SMEs) start showing up late or missing meetings, we may have been expelled.

Rule #4: When we mess up unintentionally we might get a green card. A green card means a minor offense has been committed, but the play can proceed. In Kids’ Rules it means an unintentional offense. As grandparents and as project professionals we’re going to mess up, but if it’s unintentional, we will probably be forgiven. As a grandparent I usually got a green card for using my hands by mistake. However, when I used my hands several times in a row even though I didn’t mean to, patience wore thin, I was told “that’s not how you play the game,” and I was given a yellow card. On projects there will be times when we mess up, but as long as it’s unintentional and infrequent people will understand. But when we mess up the same way with the same stakeholders over and over, we are viewed as incompetent — a definite trust buster.

Rule #5: Don’t argue with the referee. You could end up with a red card. The referee is the referee. My grandsons were proud of Team USA who despite the bad call acted professionally and were good sports. On our projects the sponsor is the referee. We will probably disagree with our sponsor from time to time, but as we know the sponsor (referee) isn’t always right, but the sponsor is always the sponsor.

There are several other rules that apply, like what happens when we don’t have a referee (neutral facilitator) or when we don’t devote our entire attention to the game, but we’ll end here, wishing you fun with family and success with your projects.