Skip to main content

Tag: Business Analysis

Strategy Spotlight: 9 Steps to Take You From Strategic Plan to Implementation

Creating an Execution/Implementation Culture is all about getting things done through people. To do that, you need to get your senior team on the same page in their thinking about management vs. leadership and how it relates to empowering people to get things done.

One of the ways to do this is to work through the process from strategic planning to tactical implementation. As part of your planning process, consider these nine key items to get your senior management team rowing in the same direction.

1. Define Strategy

If you have strategic items that the senior team must deliver, review them. Get them down to 3 to 5 strategic agenda items and into words that can be remembered by you and your people.

2. Set Initiatives

Start the process of defining your key initiatives that relate to the strategic agenda items. Depending on the size of the organization, these may be referred to as enterprise or program items. No matter which term you use, create strategic initiatives that serve as umbrellas for actual project work.

3. Establish Elements

Establish the big chunks of work that must be done. Work statements should always start with a verb and be action-charged. These are the key elements and are referred to as statements of work. They are not tasks. You should only have 3 to 5 key elements at the end of this step.

4. Create Measurable Outcomes

To create measurable outcomes, use the SMART (specific, measurable, attainable, realistic, time-bound) or CAR (challenge, action, result expected) models. When writing measurable outcome statements, make sure they are no more than three sentences. The longer and more detailed the information the greater chance you will lose your key stakeholders.

Related Article: 7 Steps to Kick-Start Your Strategic Planning Process

5. Enable Champions

Every initiative should have a champion. Champions are leaders who use vision and influence to get things done through people. A Champion is not the same as being a manager. Managers are operational and get things done through authority. It is important that Champion be empowered to work across the organization and functional lines to lead and support the strategic initiatives, required outcomes and work elements to ensure success.

6. Agree on Timelines

All initiatives should have timelines. There should be an overall timeline for each strategic initiative and separate timelines for work elements. Discuss and agree upon timelines. Not everything has to happen at once.

7. Assign Leaders

Work gets done by leveraging resources. In this case, the resources are defined as people. At this level, the Initiative Champion seeks Project Leaders within the functional business areas to rise and take responsibility for organizing people to get the chunks of work completed. The project leaders must break down the chunks of work, gathering additional resources and creating micro-timelines to meet key milestones.

8. Forecast Costs

The Initiative Champions working with Operational Managers and Project Leaders should work together to define the true costs associated with the strategic initiatives and the associated work. Some initiatives will be operational, and others will be clear projects.

9. Establish Alignment

There should always be an alignment stream associated with your strategic initiatives. The alignment stream should include objectives for creating a common language for communications, establishing awareness and activation abilities, and building collaboration skills.

Not everything happens at once. The senior team will make mistakes. They may become overwhelmed with what needs to be done. Maybe timelines aren’t fully discussed and agreed upon. An execution culture is cross-functional and self-directed. It’s not a clear-cut process. People need a path to follow. As the senior team, give them one.

Question: In what way are you engaging others in your strategic and tactical planning efforts to ensure you achieve successful implementation?

The Innovative Enterprise Business Analyst

The Business Analysis discipline is transforming itself in response to the 21st century realities: the Internet of everything is everywhere; change is the only constant, digital, social and mobile spheres have converged; every company needs to be a technology company; competitive advantage is always at risk; software is embedded in virtually every product and service; technology advances are fast and furious and unrelenting. In the midst of these challenges, we strive to reduce costs, do more with less, provide customer value, improve decision making, produce innovations, and advance internal capabilities.

In response to these challenges and to remain competitive, companies are continuously innovating to transform themselves and remain on the leading edge. EBAs are rising to the occasion to foster creativity and produce innovative products and services. Project-related requirements management skills are still needed. However, realizing that creativity is the #1 skill required to succeed in the 21st century, EBAs are continuously exploring their role in fostering collaboration and creativity. EBAs have discovered that deliberate design principles can be used to accelerate innovation of products and services. It is the EBA who is driving the convergence of the key disciplines required by organizations today: business, technology, and design. BAs everywhere are striving to:

  1. Discover the magic of design thinking, and how it is being used in progressive organizations to develop breakthrough solutions to complex business problems.
  2. Examine creativity-inducing tools and techniques used by facilitators everywhere for problem solving and decision making.
  3. Consider how to augment structured facilitation techniques with investigation, experimentation, and creativity-inducing activities.
  4. Learn how to reinvent their team facilitation model often to keep teams engaged in the innovation process, whether working on incremental enhancements or breakthrough technology.
  5. Partner with the PM to work together to insure projects are launched to bring about innovative solutions, value to the customer, and wealth to the bottom line. Make decisions are made with the customer in mind. Seek out changes that add creativity and innovation to the solution design.



I have written a lot about complexity. Complexity has a direct correlation to innovation. Complexity is everywhere: in our business practices, in our business partnerships, in our digital strategy, in our data and information management, in our projects, and in our effort to achieve business/technology optimization. CIOs are struggling to be able to not only manage, but to capitalize on complexity to bring about the innovations that result in competitive advantage.
The good news about complexity is that it breeds creativity. Complex systems are dynamic, always changing to adapt to transformations in the environment. Complex systems fluctuate between states of equilibrium, which leads to paralysis and ultimately death, to chaos, which leads dysfunction. It is important for EBAs to realize that the most creative, productive state is on the edge of chaos to make innovative decisions to adapt to changes and learnings.


So because EBAs care about creativity and innovation, they care about complexity. EBAs think holistically and therefore they realize that the average lifespan of a company listed in the S&P 500 index of leading US companies has decreased by more than 50 years in the last century, from 67 years in the 1920s to just 15 years today (Professor Richard Foster, Yale University ). What this means is that companies today must innovate to survive. Companies are complex systems, always adapting to changes in the economic, political, competitive and technological fluctuations. Therefore, project teams need to be adaptive, sometimes operating on the edge of chaos, to conceive of the most creative, innovative solutions. The days of the predominance of projects to enhance business-as-usual are ending, being replaced by transformational innovation. As EBAs work with the best minds in the company to design their transformation, they employ sophisticated design-centered creativity techniques to drive innovation.

Related Article: The Transformational Enterprise Business Analyst


Everyone is creative. Creativity is a skill that can be learned. The 21st century EBA is well positioned and quite proficient at bringing groups of experts together to conceive, test, refine and implement innovative solutions. The key is to get the right people in the room and create a safe environment.

“The skill of generating innovations is largely the skill of putting old things together in a new way, or looking at a familiar idea from a novel perspective, or using what we know already to understand something new. Annie Murphy Paul, author, journalist, consultant and speaker who helps people understand how we learn and how we can do it better. (Her latest book, How to Be Brilliant, is forthcoming from Crown)

The EBA employs traditional and transformational practices to bring about innovation. Some of these practices are common place, some very new to the project scene. EBAs are accomplished facilitators. Skilled facilitation fosters creativity. Creativity-inducing tools and techniques make use of:

  • Structured, problem-solving and decision-making methods, which primarily prompts activity in the left brain, and then
  • Cleverly augmenting them with creativity through investigation, experimentation, and a little bit of chaos, using mostly the right brain.

Structured Decision Making and Problem Solving

Problem solving can take many forms; but if you try to solve your problem without any structure, you may end up with a bigger problem. Businesses are familiar with and often use various problem solving structures, all of which all have similar components.


Creativity-Inducing Facilitation

EBAs understand that it is their responsibility to create that ‘edge of chaos’ environment among a small group of experts to arrive at the most innovative solution before launching a transformational project. The key is to make decisions quickly, test and experiment to continually improve the concept, and work iteratively in order to adapt to learnings and changes.
The process goes something like this – first create then innovate.

1. Create: divergent thinking

  • Generate Ideas
  • Combine, Refine
  • Invent, Originate, Imagine!

2. Innovate: convergent thinking

  • Analyze
  • Refine
  • Experiment
  • Decide!

Divergent Thinking: Create

Use divergent thinking to create. Identify as many options as possible. Think “outside the organization” not just outside the box. Accept all options. Look for unusual possibilities, patterns, and combinations. Combine like ideas, build on each other’s ideas. Encourage participants to challenge each other, experiment, get crazy, be chaotic, and get in the creative zone.

There are many idea generation techniques; brainstorming and Idea Mapping are the most prevalent; brainstorming to identify as many ideas as possible; Idea Mapping to visualize the innovation. But beware. Sometimes brainstorming makes us think we are innovating when we really are just minimally changing the status quo. Sometimes it helps to get out of your environment. Insist on transformational innovation. One team told me they did their best work on a sailboat!


Once multiple ideas have been generated, step back and build on like ideas, refine, improve. Then visualize brainstormed ideas using a colorful diagram. Build rich pictures. Great visualization techniques use both the right and left brain, clarify thinking, save time, foster ability to organize, communicate, remember, and innovate.


Convergent Thinking: Decide

It is possible that the group is having so much fun that it wants to keep experimenting and creating. But at some point, the EBA needs to determine the moment to decide on the approach to take to move the company forward. First, refine and prioritize the list of ideas. Then determine the feasibility of all high-priority options. Analyze the feasible options, and then decide on the most feasible, least cost, fastest time to market, and most customer-centric ideas. For the most feasible options get physical and visualize by building prototype, mockups, models, story boards, stick figures.

Remember, all facilitation is consensus building. Take the time you need to be truly collaborative, participative, unifying and synergistic. The most important factor is to get the right people in the room. People who are of varying expertise, who love to work collaboratively in ambiguous environments to arrive at places that are unknown and promising.


The EBA fulfills many strategic roles, essentially putting her finger in the dike for the many areas that have been woefully inadequate in organizations today, from business relationship manager to internal strategic consultant to innovator. Design-driven companies outperform the S&P 500. By 228% over ten years! The most innovative companies in the world share one thing in common. They use design as an integrative resource to innovate more efficiently and successfully. Yet many businesses don’t make it a priority to invest in design – often because the value of design is hard to measure and define as a business strategy. So, EBAs are filling the gap and bringing design principles into their business requirements and solution design processes.

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.” —Tim Brown, president and CEO of award-winning global design firm that takes a human-centered, design-based approach to helping organizations in the public and private sectors innovate and grow and member of the Mayo Clinic Innovation Advisory Council.

So what’s the big deal about design thinking? It combines empathy for the context of a problem, creativity in the generation of insights and solutions, and rationality in analyzing and fitting various solutions to the company’s context (Tom and Dave Kelley, in their book Creative Confidence) . Design thinking is converging disciplines to meet 21st century challenges. When driving innovation in the face of complexity, design thinking unites three essential disciplines: technology, business, and art. It focuses fiercely on customer value.
For the first time in the history of business management strategies, we are embracing principles of art and design. Design thinking…a methodology that imbues the full spectrum of innovation… a management strategy…a system that uses the designer’s sensibility and methods to match:

  • Peoples’ needs, with
  • What is technologically feasible, and what
  • A viable business can convert into consumer value and market opportunity.

It is the EBA role that is picking up the mantel and driving innovation through design principles. Fundamental design principles include the following:

  • Empathy
  • Collaboration
  • Diverse points of view
  • Integrative thinking
  • Cross-functional teams
  • Iteration, Invention
  • People-centered
  • Deep user insights
  • Visualization
  • Solve wicked problems
  • Creativity
  • Efficiency, Efficacy

Design Thinking – a Customer-Centered approach to Innovation

Design thinking is a human-centered innovation process that includes the basic elements that the EBA has in her toolbox. It is the EBA who is most primed to bring design-thinking methods to the business innovation process.


The Genius of Design Thinking

The genius of design thinking is that it integrates innovation, a deep understanding of the customer experience, and business transformation. “Intuition counts heavily, experimentation happens fast, failures along the way are embraced as learning, business strategy is integrated, and more relevant solutions are produced.”

End Notes
  1. Can a company live forever? Kim Gittleson BBC News, New York, 19 January 2012.
  2. The Secret Skill Behind Being An Innovator, Mar 26, 2014. ; 
  6. Inspiration Lab,
  8. Design Thinking: Integrating Innovation, Customer Experience, and Brand Value, Thomas Lockwood, Design Management Institute

Your Backlog Might Be Broken If…Part 1

How does your team build and manage their backlog? Is your current process working well or does your backlog need a reboot?

One of the most overlooked factors of team success or failure is the health the backlog. Success or failure often hinges on the amount of love and attention an organization gives to their queue of needs, features, feedback, bugs, and enhancements.

I am concerned that teams and organizations continue to focus too much on getting items developed faster vs. developing the right items—the items that add the most value to the organization. Traditional and Agile teams alike are experiencing these challenges.

Poor backlog management yields inefficient and ineffective projects/iterations/sprints/releases, and ultimately less value delivered overall. If you neglect your backlog and let it wander off, unattended, into the crowded project circus, it will dart to and fro distracted by every bright shiny object. Your team’s sense of direction will suffer, objectives will be murky, requirements will churn and value will be lost.

Successful teams give their backlog lots of TLC. They approach their backlog with strategic purpose—continuously reevaluating what’s most important and shifting it to the front of the queue. The items in the queue shift and evolve, but the overall goals and objectives are clear, the process is transparent, and teams gain efficiency.

Strong backlog management practices:

  • Keep teams focused
  • Deliver value quickly
  • Inspire innovation and creativity
  • Mitigate negative risk

It can be quite difficult for organizations to assess objectively the health of their backlog management processes and even more difficult to implement changes. These processes are often unwritten and entrenched years of evolving organizational politics, culture, and values. But admitting you have a problem is always the first step, so I’ve identified a few indicators that might shine a light on your broken backlog. Read and ponder the first two indicators this month and I’ll give you a few more to think about in Part 2 next month!

Related Article: 7 Habits of Highly Effective Business Analysts

Your backlog might be broken if…it is not prioritized.

How does your backlog get prioritized? What criteria are used? A healthy backlog delivers only the right work at the right time to the team. The most important things need to slide to the top and should be prioritized by value to the organization.

Prioritizing the backlog in traditional and Agile environments entails elicitation, analysis, and decision-making. As BAs and PMs, we may be the one facilitating this process, or as Product Owners we may own the decisions on the priorities. Either way, it’s our job to keep the development stream clean! Only items that yield true value to the organization should flow into development. We use tried and true analysis and elicitation techniques to ensure that each item is understood from an end-user and organizational perspective so it can be effectively prioritized.

If you are like many organizations your backlog may be 100s if not 1000s of items long. That seems impossible to prioritize! So, how do you deal with a backlog that is simply too long? Here are a few ideas:

  • Make sure the backlog is not just something the technical team is managing; it needs to be aligned with the business. The right business drivers should guide the backlog prioritization.
  • The top 10 (or about 10) items should be known and rank prioritized by value
  • When an item hits the top 10, elaborate additional details and requirements
  • The rest of the backlog can be grouped into like categories. Please do not categorize them by technical application, component or task, but rather by feature, process, or something of tangible business value that is understandable to the business decision makers.
  • Revisit the top 10 as often as needed to always have a top 10 in place.
  • Track the time something has been in the backlog…. seriously consider deleting/archiving the item if it remains in the backlog and not making the top 10 for six months (or whatever timeframe seems appropriate).
  • Make sure everyone knows the top 10 ranked priorities and get everyone focused on #1!

Warning: If your team seems to be using FIFO (first in first out) or SWGG (squeaky wheel gets the grease) processes for backlog management, the team is at high risk for not delivering value and spending the organizations resources appropriately.

Your backlog might be broken if…it is inside out.

Does your backlog focus inside out (technology and technical tasks) or outside in (user and business point of view)?

Backlog items should be written from the user or business perspective, NOT from the perspective of the team or the technology components. A piece of technology, all by itself, does not typically provide value to the user, especially in our complex integrated environments.

To prioritize the backlog we need to understand the value each item provides by writing our backlog items in ways that express the value to the organization, end customer or end user.

When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience. If your backlog items have names like “code profile page” or “write SQL for DB call” or “map data for credit card validation,” your backlog might be broken.

Backlog items should express the WHO, WHAT, and WHY, in terms that the end customer understands and can be prioritized by business leaders.

Some ideas to transition poorly written backlog items:

Item 1: Add a SAVE button at the bottom of the screen.

Rewritten: Give the customers the ability to save an order mid-stream while entering all of the order data so that they do not risk losing information already entered if they step away or get interrupted while entering.

Item 2: Upgrade the database to the new version

Rewritten: For customers to be able to enter orders after Oct 1st, 2015 we need to upgrade the database to the new version so that the version works on the operating system.

Item 3: Code the server file to add the new volume properties

Rewritten: To serve our expanding customer volumes we need to update the server file to accommodate more users at one time.

Is your backlog broken?

As you evaluate your backlog this month, ask yourself these important questions:

  • • How are our priorities really being determined?
  • • Are the items on our backlog written in a way that makes it easy to understand value and identify priorities?

Our backlog health check will continue next month when I share a few more “broken backlog” indicators in part two of this article!

There must be 50 Ways to Write a Great User Story

The user story is the center-point for the Agile business analyst to perform work. From the story, everything else can be facilitated, requirements definition and communication, development and QA tasks that will bring it to completion, tracking and reporting for the team, management, and even the customer, and even knowledge transfer for future team mates. All of this is possible with the well-written story.

During the time that I have worked as an Agile BA, I have seen stories used in a broad spectrum of manners, those that are completely cryptic in what their purpose is, those that read more like random defects recorded by IT and/or non-IT people, those that are largely dependent on tribal knowledge, and those that are concise, clear, and deliver all the important pieces to be truly useful to all the team, as well as non-scrum team stakeholders.

I recently decided that while the story can be used in numerous ways, a good story will have certain attributes. Check the list that follows and see if there are more ways to write a good story. In an Agile team, the flexibility will be built into it by doing what makes the most sense to your unique project and your unique team. The rigueur of waterfall methodologies will not limit the Agile BA to a strict set of requirements to fulfill in getting acceptance of the requirements documentation. It will also expand the BA’s capability to communicate across teams and simultaneously contribute to the library of project documentation.

Related Article: User Stories – You Don’t Have to be Agile to Use Them!

Keep in mind, as the owner of the user story, seek to communicate efficiently, and with clarity. Do not bury the meanings, purposes, objectives in verbiage that is not readily accessible to the spectrum of stakeholders that will be the consumers of the story. In depth technical details, and even details of business process information can be included in the story, but as a subtask requirement, or an image or attachment to the story. Keep your headline reader ready! This applies to Developers and other technical team members to the business customer and executives. Make your handprint on the story by offering clarity, versus one that furthers confusion.

How you write a great story is up to your own project and style, but make sure it has these qualities.

Here are a few ideas:

  1. A great headline reads like a story, not a puzzling technical paraphrase.
  2. A description that cuts to the chase and is readable by all scrum team members.
  3. Use story notes. If this is available, capture and describe aspects and details beyond the description.
  4. Capture the tasks involved for specifying the requirements, the work of the Developers, and the criteria for QA activities. My current team makes this quick to grasp with prefixes to indicate which team member is responsible, such as ‘DEV’, ‘QA’, etc.
  5. Clear acceptance points or criteria are written so that any business analyst can walk through the deliverable and give it a yes or no to pass for acceptance, or to pick up the workflow. It should be cross-team member ready.
  6. A workflow that makes common sense and uses verbiage that can be readily understood. This workflow should be visible to all users, and permissions granted only for those who are in the appropriate role to select that workflow step.
  7. The right screen shots should be attached, but only if needed.
  8. Attachments can serve as directly related to fulfillment of the story, and become a powerful reference tool in future use when investigating the history of a feature or whatever was important to the story. Meaningful and supporting attachments can also guide the knowledge transfer when new team members join.
  9. Comments should be direct, and to the point. This is all too often overused, for comments that do not need to be captured and reread. Valuable comments are readable, complete, and understandable. Any ‘next steps’ or action items that come out of a comment need to be clearly stated.
  10. Use the story points to track, communicate, and reflect the best estimating available from the team. A lot of skill goes into good estimating and the various team members have a lot to offer. Make sure that all voices are heard, especially from QA and UAT.
  11. Use your story to facilitate prioritization. Keep the ranking within the story itself. This can then be ready to use when reviewed, reported, analyzed for metrics. The PM, and the dashboards that can be created will thank you.
  12. More… employ the elements that will make it valuable to your team and efforts. Agile allows options, and as the BA, you can facilitate it.
  13. More as you can think of them!

All of these pieces work interdependently to define, communicate, and deliver requirements. The Agile BA is the one who ushers the story, facilitates the collection of story components, and gives it a consistent tone, style, and voice.

The Value of Business Analysis: Storytelling

One of the main duties of the IT Business Analyst, or Business Systems Analyst, is to document requirements for software development projects.  Many organizations believe this is the only role of the IT Business Analyst and utilize them only in this very narrow scope of duties.  Organizations that recognize the true strategic value that Business Analysts can bring to the organization will gain a competitive advantage in the marketplace. 

However, even if the organization defines the role of the Business Systems Analyst very narrowly to requirements documentation, those Systems Analysts can put the word “business” back into their role and show the organization the value they can bring to the table.  They can show management and the organization their value by going beyond documentation of requirements to telling the story of the project and its business solution.  Document the requirements of the project as management and the organization expects you to, but then package those requirements into a story that will tell anyone, even those unfamiliar, all about the project. So how do you start?

Business Case

The business case for the project defines the business problem that the sponsor wishes to have resolved.  It should define the benefits of the project and costs – thereby a cost-benefit-analysis, strategic alignment with organizational goals, business requirements, rough duration estimates, and if known at this time, alternative solutions.  The document is the one that the organizational project approval board reviews to approve and prioritize projects. These approved and prioritized projects make up the project portfolio that needs to be managed to deliver the maximum value and competitive advantage to the organization.  This is another value of business analysis, but that is a story for another day.

Define the True Business Need

Often, symptoms of the true business need or problem are included in the business case.  They are often statements of business stakeholders, what they experience in their work, or their pain points.  This is where the Business Analyst will ask “Why” to drive to the true business need.   Once you get to that true business need, you should also define the contributing conditions that are causing this business need.


It is true that the Project Manager defines and manages project scope, but the Business Analyst defines and manages solution scope.  Solution scope may be defined more narrowly, or more widely than project scope.  There may be multiple components to the solution to a project; each component will have the scope of that solution.  Solution scope may become wider than the project because the solution interacts with downstream systems.  When you tell the story of a project, you must mention the scope of the project and the solution.  These may be links to scope documentation, but should include more definition that is learned during the project.

Related Article: The Power of Story in Business Analysis

Requirements and Business Rules

Business rules are defined prior to project initiation.  Define stakeholder, solution, transition requirements and business rules during the discovery phase of the project.  These may be defined in multiple documents like a Business Requirements Document, Functional Requirements Document, System Design Specifications, or documents of other names.  Include any assumptions, constraints and dependencies related to those requirements.  Defining these requirements and business rules is the main duties of the Business Systems Analyst and should be included as the meat of the requirements package.

Business Glossary (Glossary of Terms)

An often missed part of a requirements package is a glossary of terms important to the project.  These are often business terms for the business unit(s) for which the project is to deliver a solution.  For product or software project, a technical team is assisting to deliver the solution to the business unit(s), and may not be familiar with the business terms of that business unit(s).  As noted in the introduction of this article, the requirements package should tell the story of the project to those unfamiliar with the project; therefore a business glossary is necessary to ensure your audience understands the package.


A picture is worth a thousand words.  They also help the audience consume and understand content much quicker than text.  This should start in the scope section with some type of scope diagram, such as a project functional decomposition or context diagram.  There are several business analysis techniques that deliver a picture or diagram to its audience; these include business model canvas, data flow diagrams, data modeling, decision modeling, mind mapping, organizational modeling, state diagrams, process flows, and prototyping to name a few. Any picture, model or diagram developed during the project should be included in the requirements package.

Use Cases

Use cases are an effective business analysis technique to understand the interaction between an actor, or actors, and a system.  Use cases can be used to highlight a specific process within the scope of the solution to help the audience understand the specifics and reasons for the process.

Lessons Learned

The project team learns a lot during the discovery phase of the project.  Some organizations may call this the analysis and design phase(s) of the project.  These lessons are usually learned after the creation of the business case and scope documents; and therefore, should be included in the requirements package.


Hopefully by now you are asking yourself “why would I create this one all-inclusive document in addition to all the other documentation created during a project?”  It may even sound to you like duplication of effort or documentation, and I hope you don’t dismiss it as such.  The value of creating this one package was outlined in the introduction to this article – to tell the story of the project.  It should tell someone unfamiliar with the project, or business unit(s) involved, all about the project, its purpose, scope, business problem, requirements, and solution. 

As a person unfamiliar with the project, how would you find out these things about the project?  How would you know what documents to read? In what order would you read these documents?  The requirements package wraps all this documentation into one neat package for easily readability and shows in the order that documentation of the project should be read in order to know what happened during the project.  This is how you tell the story of the project and increase your value as a business analyst to the organization.