Tag: Use Cases

The 6 Essential Project Management Books

Written by Toland Lawrence on August 8, 2018. Posted in Articles. 8 Comments on The 6 Essential Project Management Books

Whether you are managing your first project, or have been doing it for years, you’re always looking to improve your skills with the best project management books.

While there is nothing like learning from experience, taking the hard-won advice from experts in the field will save you from making countless avoidable errors. But with so many project management books out there, it’s hard to know which are actually useful.

I’ve searched the internet, read through Amazon reviews, and asked other project managers to find the best project management books on the market.

Based on the research, here are the 6 essential reads for project managers.

1. Alpha Project Manager by Andy Crowe

Based on his survey of 860 project managers, Andy Crowe breaks down all the key traits that make the best project managers achieve more. His research debunks common knowledge about what it takes to succeed as a project manager. For example, his survey found that the best project managers send fewer emails per day and spend less time in meetings than their less-successful counterparts.

What makes this analysis stand out is that fact that they also surveyed 4,398 clients, team members, and senior management that worked with these project managers. As a result, the findings reflect a comprehensive view of the project manager’s performance, and not subject to biases of many self-reported surveys.

If you are ambitious and looking for strategies to propel you up the corporate ladder, this book has a lot of great insights.

2. The Five Dysfunctions of a Team by Patrick Lencioni

Good project management isn’t just about what strategies and tools you use. It’s also about the people. That’s the focus of Patrick Lecnioni’s compelling book.

Through an engaging fable about a troubled Silicon Valley company, he uses the power of storytelling to highlight five common areas where teams fail. This book is a quick read filled with helpful insights that you can take and implement on your team right away. If you want to get better at improving team dynamics, this one will be a great asset.

3. A Guide to the Project Management Body of Knowledge by the Project Management Institute

This book (known as PMBOK) is considered absolutely essential for anyone studying for the Project Management Professional (PMP) certification exam, an important industry-recognized certification. Project Management Institute (PMI), who is responsible for setting industry standards, write each edition of this text.

Yes, this book is academic and dense (over 600 pages!), but it is one of the most comprehensive guides out there. Definitely recommend it for anyone who wants to take the PMP exam or deepen their project management knowledge.

Advertisement
[widget id=”custom_html-68″]

4. Getting Things Done by David Allen

This is one of the most influential business and personal productivity books ever written. The Getting Things Done (GTD) method emphasizes the importance of getting your tasks out of your head and breaking them down into an organized system. When you do this, it frees up your mind to think creatively and make better decisions. The book is filled with practical guidance on how to set up task lists and structures that help you feel less stressed and more organized.

For all project managers overwhelmed by stress, the book has the answers you need.

5. Strategic Project Management Made Simple: Practical Tools for Leaders and Teams by Terry Schmidt

This book is a practical guide to turning ideas and goals into coherent, actionable plans. The author suggests that there are 4 critical questions that a project manager must answer to build a strong project plan:

What are we trying to accomplish and why?
How will we measure success?
What other conditions must exist?
How do we get there?

This mental framework ensures that you have considered all important aspects of a project before you get started. If you are looking for a more strategic approach to project management, check this book out!

6. Good to Great: Why Some Companies Make the Leap and Others Don’t by Jim Collins

This is a classic business book that should be on anyone’s bookshelf. Jim Collins and his team did an in-depth analysis of 28 companies and discovered what were the key determinants that led to significant improvements in performance. Although not specific to project management, this substantive analysis into how companies made real improvements in performance has lessons you can apply in any context.

If you are looking to improve your leadership skills, this book is the one for you.

Honorable mentions

While they didn’t make our top 6, here are some other great books you may want to explore:

Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure by Todd Williams
Project Management for the Unofficial Project Manager by Kory Kogan
When: The Scientific Secrets of Perfect Timing by Daniel K Pink
The Power of Habit: Why We Do What We Do in Life and Business by Charles Duhigg

What is Agile Iterative Approach and where is it used?

Written by Fred Wilson on June 27, 2018. Posted in Articles. 2 Comments on What is Agile Iterative Approach and where is it used?

To keep up with the market demand, the fast-evolving scenarios of the digital business have placed mounting pressure on CIOs, to deliver equally fast software development.

According to Gartner, growing number of IT organizations are opting for Agile development to speed up project deliveries and illustrate business value.

The 12th Annual State of Agile report found that one of the top five reported reasons for adopting Agile methodologies, was accelerated software delivery, increasing to 75% in 2018. Whereas Iterative Planning, with an 88% increase, was the second most employed Agile Technique in 2018.

What Is Agile Iterative Development?

Agile methods of software development are most commonly described as iterative and incremental development. Iterative strategy is the cornerstone of Agile practices, most prominent of which are SCRUM, DSDM and FDD. The general idea is to split the development of the software into sequences of repeated cycles (iterations). Each iteration is issued a fixed-length of time known as a timebox. A single timebox typically lasts 2-4 weeks. [1]

The Agile Iterative Model is perhaps best explained by Craig Larman in his book Agile and Iterative Development – A Manager’s Guide.[2] Larman explains that the model functions on an ADTC Wheel (Analysis, Design, Code, Test). This is to say that each iteration cycle incorporates the Analysis of the plan, the Design, its Code and simultaneously the Test. The ADTC wheel is more technically referred to as the PDCA (Plan, Design, Check, Adjust) cycle. The agile team implements the PDCA cycle on each iteration separately in the following manner:

P (Plan) – Iteration Planning. In this event, the team collaborates to discuss the objectives for the next iteration. It also summarizes the work done and determines the team backlog required for the next iteration.

D (Design) – Iteration Execution. This is the ‘do’ step where the development of the software, its design and coding takes place. If it’s a second or third iteration, then functionality testing is also conducted. The team collects user stories and prepares for the next step, that is Iteration Review.

C (Check) – Iteration Review. Also known as the ‘check’ step, Iteration Review is carried out with the Product Owner. The team shows the tested deliverable to the Product Owner, who then reviews the completed work and ascertains whether all criteria have been met.

A (Adjust) – Iteration Retrospect. In this event, the team evaluates the entire process of the iteration from the first step. It essentially works on any improvements that are gathered in previous iterations. New problems are identified along with their causes. Before the team starts the next cycle again, team backlog is refined for future reference. [3]

Advertisement
[widget id=”custom_html-68″]

The iterations are repeated for optimizations and improvisations and, the lessons learned from previous cycles are applied in the next cycle. Until a fully functional software is ready to hit the market.

Benefits of Agile Iterative development

Agile Iterative development was created as a more flexible alternative to the otherwise traditionally rigid method of Waterfall.

The waterfall method is a linear approach that proceeds sequentially from one phase to next, without allowing the development to return back to the previous step. Goes without saying, the waterfall method causes impending repercussions, that include but are not limited to: increased development costs, prolonged software delivery and additional resource input. [4]

Sudhakar Gorti, CIO for Environmental Data Resources agrees, “One of the major benefits of agile over waterfall is that you see a deliverable on an iterative basis and the Product Owner can decide to make changes to the product backlog”.

Customer Involvement – Agile Iterative development encourages user contribution. After each iterative cycle, customer feedback is obtained, and the product is then subjected to necessary changes based on that feedback. This aspect brings adaptability into the project’s framework.

Favors Evolution – The planning in agile iterative development process is a continuous feat, that allows space for evolving ideas, instead of an extensive planning that only precedes execution and testing in waterfall.

Risk Assessment – Agile iteration allows risk identification and mitigation early on in the development to avoid speed bumps later down the timeline.

Rapid Delivery – The work is divided into small cycles, allowing team members to dedicate their focus and deliver on time. Moreover, testing is conducted simultaneous to coding and design in every iteration, which greatly reduces the time needed to achieve completion. [5]

Where is Agile Iterative Development Employed?

Agile Iterative approach is best suited for projects or businesses that are part of an ever-evolving scope. Projects that do not have a defined set of requirements intended for a defined set of time. For such cases, Agile iterative approach helps minimize the cost and resources needed each time an unforeseen change occurs. [6]

nTask, a new, smarter task management software was created using SCRUM methodology. SCRUM enables independent team work using the ADCT wheel, for which various nTask teams worked collaboratively in two-week sprints (iterations). Since the scope of nTask is continuously evolving, and additions are made on a weekly basis, the iterative approach enables the nTask development to switch back and forth for optimizations.

Brad Murphy, CEO of Agile consultancy Gear Stream, believes that Agile Iterative approach is now extensively serviceable in zones other than software development.

He explains how Digital Marketing can benefit from the iterative approach by using the element of frequent delivery to collect customer feedback. Fastly solicited feedback can directly aid in improving subsequent iterations to attract larger traffic. [7]

According to the investigations of The Deloitte Center for Government Insights, 80% of major federal IT projects termed themselves to be “agile iterative” in 2017. One reason for this rise was easily accounted by the reduction in time taken to complete a project in harmony with the total cost of the project. [8]

Another report from Deloitte in 2015 reveals banks like Barclays have also begun utilizing iterative approaches such as SCRUM on more than 20% of their internal audits. Barclays conceded to benefiting from SCRUM in areas such as risk management and planning.

Agile I.A is not limited to IT organizations and financial firms only. Walmart, one of the world’s largest retailer also employs the use of Agile I.A for internal audits. One of their many successes post-agile induction included time saving in comparison to traditional audit approach. [9]

Ricky Barr, managing director Internal Audit, United Airlines, sums his experience of employing Deloitte’s Agile Internal Audit as “a faster audit-cycle-time via time-boxed iterations”.

Up until 8 years ago, many corporations such as Gartner’s vast majority of clients still used traditional waterfall methods for application development. But with demonstrable benefits of Agile over the years, that ranged from increased business value to strong organizational impact, the Agile community has expanded from start-ups to Global brands like that of IBM and Cisco.

References
1. https://www.linkedin.com/pulse/agile-iterative-incremental-waterfall-manish-thakkar
2. https://www.amazon.com/gp/product/0131111558?ie=UTF8&tag=alaridsblo-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131111558
3. https://www.scaledagileframework.com/iterations/
4. https://www.cio.com/article/3048535/leadership-management/how-to-get-agile-to-work-at-your-company.html
5. https://www.linkedin.com/pulse/why-consider-agile-project-management-manish-thakkar?articleId=6119346380818440192#comments-6119346380818440192&trk=prof-post
6. https://www.upwork.com/hiring/development/agile-vs-waterfall/
7. https://blogs.gartner.com/jake-sorofman/agile-isnt-just-for-geeks-anymore/
8. https://www2.deloitte.com/insights/us/en/industry/public-sector/agile-in-government-by-the-numbers.html
9. https://www2.deloitte.com/content/dam/Deloitte/uk/Documents/finance/deloitte-uk-putting-agile-ia-into-action.pdf

A PM’s Guide to Use Cases – Part 3: Use Case Narratives

Written by Elizabeth Larson on December 8, 2015. Posted in Articles. 6 Comments on A PM’s Guide to Use Cases – Part 3: Use Case Narratives

As promised, this is the fifth article in our modeling series and the third on use cases. We’ll start with a short summary of the main concepts covered previously.

Summary of previous articles

Here are the highlights of the requirements modeling articles written to date:

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 to develop the end product (solution). Modeling helps uncover requirements related to these product features and functions. Asking questions enables us to model the requirements. Modeling requirements, in turn, uncovers gaps that lead to further questions and ultimately helps us deliver the product that our stakeholders want and expect. See previous article at: http://www.projecttimes.com/elizabeth-larson/a-project-managers-guide-to-requirements-modeling.html
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, graphics representations, or both. See http://www.projecttimes.com/elizabeth-larson/a-project-managers-guide-to-requirements-modeling.html
As PMs we might not do business analysis work ourselves, but we need to ensure that work is done. So it’s important for us to be able to have enough understanding of these models to ask the right project questions of the resources who will be doing the elicitation and modeling. Refer to http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-requirements-modeling-part-2-concurrent-requirements-modeling.html
There are different categories of requirements, including data and process. Use cases describe a third category—interaction. When we use any kind of user interface, such as a mobile phone app or enter any information into any screen or web page, we are interacting with the “system.” Use cases describe this interaction between us (actors) and the system. See http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-use-cases-part-1-what-is-a-use-case-and-why-should-pms-care.html
In other words, a use case describes the conversation back and forth between actors and a system. The system contains all the work we want to do on the project, and a use case diagram is useful in helping us determine this scope of work as it relates to the final product. Actors always interact directly with the system, but are always outside the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers. http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-use-cases-part-1-what-is-a-use-case-and-why-should-pms-care.html
Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding scope and the use case narrative is invaluable for getting the detail needed to build the product or service. Although used primarily in software development, use cases are also helpful when creating processes and developing equipment. They work wherever there is interaction between people and what those people need to do. Refer to: http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-use-cases-part-1-what-is-a-use-case-and-why-should-pms-care.html
Use case models contain the use case diagram that we described in the last article and a textual description of each use case shown on the diagram. We have described the diagram in great detail in the last two articles. Here we will describe the purpose of the use case narrative, the five questions these narratives help answer, and how invaluable this information is to both the business stakeholders and development team.

Use Case Narratives

The use case diagram shows the use cases, which are the features contained in the system. Each use case is shown as an oval and named as a-process with a verb to describe the action, such as Request Item or Ship Item. Use case narratives describe the process steps inside each use case. The narratives are needed because while it is great to see the features at a glance, no one really understands what these process names mean until we describe the detailed steps. If we told a developer to build a feature and all we gave them was the name “Request Item,” they would have to ask tons of questions and/or make lots of assumptions about how people would interact with the system when they wanted to request items from a website. We have found that those developers who actually read them love these narratives because they save so much time.

Below is an example of a use case narrative that describes the process steps involved in reserving an item in inventory in an Order system. To create the narrative we include the following:

A number and name that identify the use case. These are often assigned according to the organization’s standards, templates, and/or requirements processes.
The pre-and post-conditions describe the scope of each use case. Since each use case begins and ends, we need to tell it where to begin and when to end.
A matrix with what the actor does and how the system responds to each actor request.
Primary, alternate, and exception flows, which we explain below.

Below is an example of a use case narrative. The numbers on the use case narrative correspond to five important questions that use case narratives answer and which are listed below the narrative example.

Figure 1 – Example of a Use Case Narrative

At what point is the use case ready to begin? That is, what has to occur before the use case process can begin? Our example is about what the system does to reserve an item in inventory after it has been requested by a customer. When does this use case begin? Is the customer already logged in? Can they reserve items without being identified as a customer? These are business rules that have to be answered by stakeholders. Is the system available? Which user interface (screen/web page) are they on? The use case pre-condition answers this important question and if it is not known when the developers start working on it, they will struggle and lose time arguing about it.
When is the use case complete? In other words, when is done “done?” What do we mean by complete? That’s another tricky question to answer. The use case narrative answers this question in the post-condition(s). The post-condition(s) together with the pre-condition set the boundaries of the use case. Again using our example, is the use case done when the item is shipped to the customer? When the item information is sent to the warehouse for packing and shipping? We don’t know and we should not assume. If the use case is about reserving items in inventory, shipping the item to the customer is clearly out of scope for this use case, although in scope for a different use case, one relating to shipments.
What is the most common way of getting from the beginning of the use case to the end? That is, from the pre- to the post-condition. This is our primary path, sometimes known as the happy path. Let’s have a quick peek at the happy path. We always start with the actor action and always end with the system response, or how the system responds to the actor request. The system response lists all the process steps in response to an actor action until another actor, if any, triggers another response from the system. These steps continue until the post-condition is reached.
What other ways can we get from the beginning to the end? These are our alternate paths. We’ll reach our post-condition, but not in the most routine way. That is, we’ll take a different route. Sometimes we return to the main path, sometimes not. In the above example, we return to the primary path.
What might prevent us from reaching our post-conditions? These are our exceptions. Exceptions take us off the path entirely and terminate the use case.

To better explain this example, let’s use the example of getting home from work—in this case by car. Let’s say that our pre-condition is that we have left our office building. Our post-condition is that our car is parked in our garage at home. Our routine way to get home is to drive on the interstate. Some days, however, the traffic is so bad that we take side roads. We still get to our post-condition, just in a different way. This path, then, is the alternate path. However, let’s say that we try to start the car and the car won’t start and has to be towed some place for repairs. That is an exception that prevents us from reaching the post-condition.

Test scenarios, acceptance criteria, and “Given-When-Then”

The three narrative flows are similar to test case scenarios. One of the advantages of taking the time to create use case narratives is that test scenarios will be pretty much complete as well. In addition, the post-condition(s) will help us determine the acceptance criteria. Finally, many Agile projects use a “given-when-then” format to help with testing. The use case narratives provide this information. The “given” is the pre-condition(s), the “when” are the actor actions, and the “then” are system responses. Let’s refer to our use case narrative example.

Given that the system is available, the customer is logged on, and that the customer has navigated to the page to enter line items, when the customer enters the item number, then the system verifies the number with a digit check verification, and so forth.

Summary

Use case narratives take time to create. However, it’s not creating the model that takes the most time. It’s the thought process about the interactions between actors and the system that take the most time. The time that it takes to think through these interaction steps is time that has to happen regardless of what format is used to document it. Use case narratives provide a structured way to get us through the thought process, helping us ask the necessary questions, and giving us complete interaction requirements, which are needed to build a solution that works for our stakeholders.

A PM’s Guide to Use Cases Part 2 – : Use Case Diagrams Explained

Written by Elizabeth Larson on November 10, 2015. Posted in Articles. 5 Comments on A PM’s Guide to Use Cases Part 2 – : Use Case Diagrams Explained

As promised, this is the third article in our modeling series and the second one on use cases. We had promised that in future articles we would show examples of use case diagrams, explain how to build them, and describe why we should create use case narratives. And yes, we’ll explain how use cases provide the same information as the Given—When–Then format. So here we go!

Summary of previous article

Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding scope and the use case narrative is invaluable for getting the detail needed to build the product or service. Although used primarily in software development, use cases are also helpful when creating processes and developing equipment. They work wherever there is interaction between people and what those people need to do.

Use case diagrams are one of several techniques we use to help with both the project and product scope. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten.

In the last article we said we would explain the terms reference in this example use case diagram.

Figure 1 – Use Case Example

Summary of Five Key Terms

In use case diagram example above, there are terms labeled with five numbers. Each one of these numbers represents five questions, the answers to which help us understand requirements, as well as create use cases.

What is our solution? Usually, projects begin with a business need (problem or opportunity) to be addressed, and that need is addressed by a solution. In the world of use cases, this solution becomes our system, and it contains all the work we want to do on the project related to the end product. In other words, the “system” on the use case diagram represents the product scope. In our example, the scope of the banking system includes features and functions that we want to include as part of the solution scope. Let’s keep in mind that the scope of the project is directly related to the scope of the product, so the more complex the solution, the larger the project scope.
Which stakeholders will interact with our system? Using use case lingo, the stakeholders using the system are designated as actors on our diagram. Actors are always outside the system but always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actor to actor interaction is not described by use cases and can be thought of as business processes, not use cases.
What other systems interact with our system? These are also actors since Actors can be people, other systems, time triggers, or event triggers. Actors, again, whether they are people or other systems, for example, can provide input to our system and receive outputs from the system. For example, a process is kicked off at a particular time, like month-end, it is a time actor. If it is triggered by an outside event, such as the outside temperature causing a change in the thermostat, it is an event actor.
How do these stakeholders want to use the system? These are our use cases, which describe how actors want to use the system. Use cases are high-level processes and are shown on the use case diagram as a process name surrounded by an oval shape. The use case name describes the process at a very high level. In our example diagram, we know that customers and internal banking stakeholders want to have the functionality to perform banking transactions. But unless we examine the steps involved in these processes, we will not be able to understand the real requirements related to the desired functionality. That is, we can see the birds-eye view of the functionality needed, but we will know nothing about each process itself. That is why use case diagrams ae wonderful for an understanding of product scope, but do not provide the detail we need to build the requested features.
Interfaces. The lines between actors and use cases, sometimes known as associations, allow actors to talk to the system and the system to talk back to the actors. For software, these represent user interfaces. User interfaces are screens used to allow data to be both input and displayed. The use case diagram, by showing these interfaces, provides a nice picture of work that needs to be done, since each line, or interface, means a screen or series of screens that needs to be built. Notice that the lines do not have any arrow tips. Interfaces do no show whether the data is input (comes from the actor) or is displayed (comes from the system). Arrows denote dependent relationships, which we will discuss in a future article.

Naming the actors and use cases

Actors. As obvious as it sounds, the user role or function, and not names of individuals are preferred for the actors in the use case. For example, use “Accounting” instead of “Erik.” Although we know that we should not use names, we sometimes forget because everyone knows “Erik.” But what happens after “Erik” has left the organization? Not everyone will remember what his function was.

Use Cases. Remember that use cases are processes. Accordingly we name our use cases as we would any other process, with a strong verb and a noun, that is, an action and an object of the action. Instead of naming the use case “Deposit Function” or “Deposits,” for example, we would label it “Make Deposit” or “Deposit Funds.”

Expect the use case diagram to change

Expect your diagram to change over time. Eliciting requirements, regardless of the model used to record the requirements, is an iterative process. Not only will requirements change, but details of the elicited requirements emerge as we know more. Therefore, it is helpful to use stickies for actors, use cases, and interfaces during elicitation until your diagram stabilizes. It is far less frustrating to move stickies than to redraw the entire diagram every time a change occurs. Similarly, do not spend energy trying to align actors with use cases. That alignment will change as the diagram changes. If is far easier to group actors after the diagram stabilizes. Also, there are tricks for simplifying the diagram when the model becomes complex and with the use of dependent relationships, which we’ll discuss in a future article.

In the next article, we will discuss the importance of a use case narrative and how to create one.

A PM’s Guide to Use Cases Part 1: What is a Use Case and Why Should PMs Care?

Written by Elizabeth Larson on May 22, 2015. Posted in Articles. 9 Comments on A PM’s Guide to Use Cases Part 1: What is a Use Case and Why Should PMs Care?

Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are–discussed, dissected, and the subject of many blogs. Aren’t they “old school” and not needed in today’s Agile world?

They are still needed and are, in our opinion, among the most useful tools/techniques practitioners have in their business analysis toolkit. Without going into the historyⁱ, use case models, both the diagram and the narrative text, provide a structured way to think about our work, work that we’ve always had to do in software development, but which has been simplified with use case models.

Although project managers who are not business analysis practitioners do not need to create use cases, they should know what use cases are, be familiar with key terms, and understand why they are important to getting the requirements right.

This series of articles will focus on these key points.

Why use cases?

Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding a project’s scope and the use case narrative is invaluable for getting the detail needed to build the product or service. And although used primarily in software development, use cases are also useful when creating processes and developing equipment. They work wherever there is an interaction between people and what those people need to do.

Terms, terms, and more terms

A rose by another name, as we know, would probably smell the same, and use cases if called something else would serve the same purpose. Use cases are so named because they describe how people want to use their software or equipment.

However, it does sound a bit technical. It sounds like the kind of technique that a project manager could easily leave in the hands of more technical resources and forget about. And that would be too bad, because use cases help projects in many ways, as we’ll describe below.

Years ago Elizabeth gave a presentation on use cases. She remembers saying that despite how useful they were, if it had been up to her, she would have called them something else, something less technical and more accessible to business stakeholders. She remembers one upset participant who said that it was a good thing no one listened to her! That’s probably true, but it still seems to us that use case terms are a bit arcane for most PMs and business stakeholders. So here are the key terms explained:

Let’s begin with a working definition of what a use case is. We like to think of it as the conversation back and forth between actors and a system. Which is all well and good if we know what actors are and what the system is. Let us explain.

The system contains all the work we want to do on the project. We like to use the microwave as an example. As a microwave user when I heat up leftovers, for example, I am outside or external to what the microwave does, so I am not part of the systemⁱⁱ. I am an actor who interacts with the microwave system, telling it what I want done and getting heated leftovers as a result. Which brings us to actors.
Actors are always outside the system and always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers.

Let’s practice on a couple of examples. If actors are always external to the system and always interact directly with the system, in the following two examples, am I an actor?

Example 1. The system in this first example is an automated banking deposit application. I walk by a bank lobby on my way to work. One day I decide to take a cheque to deposit it in the bank. I stand in line with the deposit, and finally when it’s my turn I hand it to a teller who enters the transaction into the automated deposit system. Am I an actor?ⁱⁱⁱ
Example 2. The next time I have a cheque to deposit I don’t want to stand in line, or even go to an ATM to deposit the cheque. Instead I scan the check using my bank’s app on my smart phone. Am I an actor?

Why PMs Should Care About Use Case Diagrams

Below is an example of a use case diagram. We will explain all the pieces in our next article.

Figure 1 – Use Case Example

Use case diagrams are one of the several techniques we use to help with both the project and product scope. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten. The use case diagram has some key benefits:

It’s an easy way to engage business stakeholders. If we explain use cases using business terms, they can visualize what their system will include, helping get a big picture of the scope.
Because it’s a useful visual, our stakeholders are more inclined to be specific about their desired featured and functionality,
Use cases are almost universally appreciated by the development team, so that there is less time spent translating the business requirements into technical specifications.
Use cases become test cases with acceptance criteria. Whether the team prefers the “Given-When-Then format or the components of a use case, as odd as it sounds, the result is the same.

Stay tuned for future articles on use cases. We will show examples of use case diagrams, explain how to build them, describe why we should create use case narratives, and yes, we’ll explain how use cases provide the same information as the Given—When–Then format.

Don’t forget to leave your comments below.

References

i Elizabeth saw an Ivar Jacobson presentation on use cases about 10 years ago. Jacobson, of course, is one of the ‘three amigos” (with Grady Booch and James Rumbaugh) who founded Rational Software and the Unified Modeling Language. “I had been working with use case models for several years at the time of his presentation. If I remember right, one of the things I learned was that the idea for use cases was rattling around Jacobson’s mind since his work at Ericsson, many decades before this presentation.”
ii Theoretically the microwave system might include all interactions with the microwave, including our processes, but that does not make much sense. It is cleaner and simpler to think of ourselves as an actor interacting with the microwave system.
iii Be careful. We need to define what the system is. In the first example we said it was an automated banking deposit application. In this example I do not interact directly with the system as we’ve defined it, so I am not an actor. The teller, however, is an actor because they do. In the second example we have not defined the boundaries of the system so we do not know who the actors are. It is quite possible that a user scanning a check for deposit is an actor since they are interacting directly with a system. It is also possible that the system is the back end and the user does not interact directly with the system. These examples show the importance of defining the system in order to understand our scope.

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.