Getting a Handle on the Project

Level
The project level is the lowest level of analysis and is where most of the
business analysis work at companies happens (because each enterprise has a
handful of organizations, many operational areas for each organization, and
many projects per operation area); Figure 2-1 earlier in the chapter shows
you
a graphical breakdown of this alignment. Therefore, the business analysis
profession is highly focused on the project area.
The people you deal with on a regular basis at this level include your solution
team members, your project managers, development staff (if you’re on a
software development project), and quality assurance analysts. On the
business side, you work with subject matter experts and users of the solution.
Understanding the people you work with on the project is important, so in
Chapters 3 and 11, we provide more information for conducting stakeholder
analysis.
Tackling activities at the project level
A project delivers a solution that’s meant to enable the operation area to
achieve its goals. For example, if a computer company wants to sell more
laptop computers and has made a decision to start selling them directly to
consumers rather than through retail stores, it needs to initiate a number of
projects in order to implement the new goal, such as creating a website where
customers can search for items, order products, and track their orders.
Because this level is where BAs do most of their work, the rest of the book
focuses on this level of analysis in great detail. For now, you should know
that although your team can take different project approaches to deliver your
project or solution (as we discuss in Chapter 11), the activities you perform at
this level remain the same:
Planning your analysis work for the project (see Chapter 11)
Scoping the project — understanding a business case, creating and
maintaining the requirements scope for a project (Chapters 9 and 10)
Eliciting and analyzing the business problem or opportunity and
understanding the true business need (Chapters 5 through 8)
Eliciting, analyzing, and communicating the solution requirements
(Chapters 12 and 13)
Verifying that the solution you’re building addresses the need and helps
the business reach its goals (Chapter 14)
Developing transition requirements — moving from planning into
implementing and understanding all that implementation entails (Chapter
15)
At first read of the preceding bullets, you may think that this book’s
organization doesn’t match up to the project activity chronology. But
there’s a method to our madness. Even though planning is the first thing
you do on a project, it requires a certain amount of foundational
understanding. As BA trainers, we actually teach our planning class late
in our curriculum because our students need to know all the techniques
available before they can plan.
Rising above project-level hurdles
Much like at the operational level, getting time from the key project-level
people you need is difficult. These folks are doing the work day in and day
out. They’re paid to work for the business, not to work on your project.
Although helping improve the current state of the business is part of their
jobs, getting the time you need out of them is tough if they’re behind on their
day-to-day work. To overcome this challenge, concentrate on collaborating
with your peers and building good relationships with your teammates. Find
out everyone’s strengths and determine as a team how to work well together.
Remind folks (including yourself) that on projects, everyone is part of a
larger team. Head to Chapter 11 for more on getting stakeholders involved.
You need to be aware of how your project fits into the bigger picture of the
business. As a business analyst, you’re in the perfect spot to see when a
project is no longer aligned with the higher goals of the enterprise. Don’t lose
the forest for the trees. Build spots into your project where you do a sanity
check — that is, you make sure the project is still aligned with operational,
organizational, and enterprise goals. These goals can change during the life
of
the project, so if you don’t periodically stop and check, you can drive
yourself (and everyone else) crazy when you realize later that you’ve just
completed a project that no longer adds any value to the company!