Author: Derwyn Harris

Productivity-Killing Monsters of Requirements and Tips to Slay Them

As a Business Analyst or Project Manager, you are on the front lines of bringing products to market that build value for your business. If you’re like most BAs, however, you spend too much time reporting status, explaining context and tracking decisions. From listening to you over the years, we’ve started the list by identifying six of the biggest challenges—or monsters—that BAs and PMs face (see list, below) but many other monsters lurk out there, slowing down your project and throwing obstacles in your way.

monsters

Example Monsters

Swoop Monster

This executive monster comes to you at the last minute with critical feedback you asked for weeks ago. Right when you’re about to move forward, she’ll swoop in to mix things up; chances are, Swoop results in more work and less time to get it done.

Rework Monster

The Rework monster pops up months after you’ve made a decision and moved forward. He wants all the details, asking you to prove who decided what was decided, when and why. Guess what happens next? You get to redo something!

CYA Monster

The CYA monster has selective memory and doesn’t remember that conversation where you both agreed on a new direction. Do you have the backup necessary answer this monster’s detailed questions?

Missing Monster

This monster is an essential contributor to your project, with a long history on your team and an ironclad memory. This monster is great… until he suddenly disappears forever with all that intelligence.

Meh Monster

Your finished product lands with a resounding… “meh” from this monster. He was expecting x, y, and z, but you delivered q, r and s. All that work you did turns out to be based on mismatched expectations so the best you could deliver is disappointment.

Cog Monster

The Cog monster blocks you from knowing the whole project, treating you like a task rabbit. She thinks as long as you do your part, and every other cog does theirs, the whole product will hum. Cog monster doesn’t understand the importance of providing context so that everyone knows what is being built and why.

Tips to Slay These Monsters

  • Give management better visibility and a continuous feedback loop to address issues before it’s too late. Be transparent and open for feedback at all phases of the project, and have frequent check-ins to get reactions early. If your team and executive staff are in the same office, this is easier to accomplish.
  • Provide full context of every decision so everyone understands the scope of the project and why. Cog monsters need your help seeing the value of context in empowering people to do their best work. This applies upstream to your stakeholders and customers so they understand what they’re getting and it applies downstream to your design, development and QA teams so they know exactly what to build and to test properly.
  • Embrace changes intelligently by connecting the dots, quickly assessing the impact and communicating updates to the right people involved automatically. As you know, we can’t talk about requirements without talking about change!
  • Break large, complex projects into smaller manageable parts, and let people filter in on what’s relevant to them. Manage project scope item by item to get work done. People naturally work on a list of a few items at a time. It’s how our brains work and we’re more productive that way.
  • Be proactive. People have selective memories. We all remember what we want to hear. What stakeholders forget is the additional things they add along the way or that you’ve had to reprioritize features as the scope evolves over time. Make sure everyone approves of the trade-offs resulting from the decisions.
  • Collaborate. New tools for managing requirements and the product delivery process can house the conversations, comments and decisions in the same place where the work takes place. Context is captured, reviews are public and nothing stays in someone’s head. Rethink the document-driven, meeting-heavy process and shift to a more modern way of working

Don’t forget to leave your comments below.

The Five Most Important Technology Shifts in Business Analyst Tools

Over the past 15 years, major shifts in technology have made the work of the Business Analyst more efficient and have increased product-delivery success.

#1 Software Engineering

Building software differs significantly from building something like a car or a house—hence the rise of “software engineering.” In concert, process and methodology took on importance and gave rise to debates, refinement and adaptation, including books and articles such as “Mythical Man Month” and “No Silver Bullet“. Because BAs building software faced more choices in what they could do, the idea of “engineering” helped instill some process into less predictable environments and placed more emphasis on how we work as teams, how we plan and how we manage change.

#2 DOORS

As processes continued to evolve so did tools and technologies, particularly software. Word processing capabilities and legacy tools such as DOORS enabled teams to capture the planning and process involved in software engineering. The introduction of DOORS ushered in the current boom of requirements-management solutions available today. For the most part, the initial swath of RM tools helped BAs focus on supporting existing processes to improve, rather than innovate around, product delivery.

#3 Rational Unified Process

This was a major shift. With Rational—and the RUP methodology—the process and the tools were built in parallel and interdependent. Thus Rational is referred to as a “software process product”.

The ultimate goal of RUP was to mitigate and control change. The predominant thought was that poor design and unclear requirements resulted in costly change. Change was treated as a problem that needed to be mitigated through a clearly defined series of phases that included a combination of textual but also visual representation of what’s being built. 

As we’ll see, it’s this attitude around change that really shifted the mindset. 

#4 Agile

When the Agile Manifesto was announced to the world in 2001, BAs considered Agile revolutionary after so many years of process, structure and rigid planning. As Agile-specific tools were introduced in great numbers, we returned to an era of process-driven technology, only this time the drivers were the engineering teams and the BAs found themselves struggling to fit in.

There’s no doubt Agile will stick around, but it is experiencing a backlash of sorts, specifically by those outside the core software-development teams. Many BAs must juggle ramifications rifts between product (and the business stakeholders) and engineering over misalignment around structuring requirements. This lack of communication and visibility is somewhat ironic, given its initial goal was to increase communication.

Agile continues to be top of mind and hotly debated. Many BAs adopt hybrid approaches to better align teams and seek ways to bridge the gaps across the organization. 

#5 Social & Mobile

Social marries technology with the way people naturally engage to bring people together to communicate, plan and make decisions. Facebook, which ushered social into the mainstream, states as its mission to:

“…give people the power to share and make the world more open and connected.”

A broad, bold statement, yes, but it summarizes how our world has changed with technology. It was unimaginable back in 2001 that we’d be so quick to share details of our lives in 256 characters or less with people we didn’t necessarily know. Yet, as we’ve realized the benefits we are readily adopting social constructs. The idea of an @ mention or a # suddenly isn’t something only the kids do. It is part of our lives, our culture and increasingly part of our work.

Mobile devices have freed us from needing to be in a physical location. They also free us to live and work more in the moment. Embarking on a trip requires little more a confirmation email. Meeting friends at a sports event requires much less detail than it used to: via text, voice call or an app, we work out the details once we all are on our way or have arrived. 

In the case of mobile, technology is driving the process. Communication has been completely reinvented. This is a huge shift for BAs and can have enormous benefits to product delivery. The intersection of social and mobile with Agile could be the driver for Agile to take root across larger, distributed teams. 

Technology and Process in the Balance

Throughout the shifts over the past few years, the business analyst has been introduced to new tools and processes designed to make product delivery more efficient and successful. Social is doing this by applying best practices from 10+ years of agile implementations and layering on the technology to accelerate how we work.

Don’t forget to leave your comments below.

Visibility Encourages Project Success

As we continue to seek ways to improve product implementation, I’d like to talk about visibility. Product implementation—regardless of software, hardware, stage, team, complexity, or methodology—is often accomplished in a series of independent, often disconnected, silos, hidden from view from others outside that particular silo. This kind of hidden work disrupts projects and puts them at risk. It’s not just teams that live in siloes; information also gets hidden. Whiteboard sessions and meetings, closed discussions and decisions… these stay invisible to those not in attendance.

The visibility of work, information, conversations will encourage product implementation success. The questions are how, when and with whom should information be shared.

The Project Management Institute recently highlighted how the project team involved in building the Buddha Memorial Center in Kaohsiung, Taiwan, succeeded because it embraced change and visibility throughout. “’Program visibility’ refers to making sure everyone involved is aware of objectives and strategy risks, and that everyone feels involved in the management and its outcome.”

Why is visibility important?
Concerns around visibility center on fears that sharing information early and often increases the potential of information overload, that constant streams of communication cause more work and confusion. These concerns are well documented and are core to people’s hesitation to increase collaboration.

These fears are misguided. Collaboration does not increase the quantity of conversations. Rather, it increases the visibility of preexisting siloed conversations. Any new conversations taking place do so because people are now aware of relevant conversations, to which they originally were not privy. This is not additional noise; more voices heard equals more value.

Additionally, visibility improves projects in the following areas:

  1. Awareness
  2. Alignment
  3. Reduced risk

Awareness is a form of empowerment, motivation and confidence. By being aware of activities, work, and content, people feel they are part of something. Awareness enables them to work more efficiently because they can directly connect their work to other activities and goals within the team, department or organization. 

Alignment results from people being aware. Motivation and empowerment, at a group level, provide alignment and increase quality by ensuring voices are heard and people are working toward a common goal.

Reduced risk is the end result of awareness and alignment. We reduce risk by decreasing potential missed expectations or misunderstandings that are the root cause of most failed projects and costly mistakes.

Methods for Increasing Visibility

As you think about increasing visibility—individually or organizationally—consider both push and pull methods. Visibility, much like how we see in general, is either revealed (pushed) or sought out (pulled).

With push, users have control over information they wish to share. They can engage with external users to improve the project work. They can push information simply, as in a meeting, an email, or through a collaboration stream. Understanding the roles of others and how people behave helps individuals determine which communication channel provides the highest possible value and opportunity.

With pull, people are looking for information. Finding information requires that it be visible and accessible. According to Forrester Research analyst Rob Koplowitz, information workers spend more than an hour a day just looking for information. Pull is harder than push. Not only does it require additional coordination by everyone, but also it depends on the people pulling information to know how to find information. The harder this process is, the less likely people are to seek out information.

In summary, visibility results in teams being more aligned and empowered. By making information more readily accessible and making it easier for people to share and engage with others, visibility removes unseen barriers and improves efficiency.

Don’t forget to leave your comments below.

How Deep Does the Reuse Rabbit Hole Go?

Introduction

Requirements reuse is a topic that has been discussed and documented for a long time. In 2010, Yuri Chernak describes the state of reuse, as well as the challenges for broad adoption. Requirements reuse holds the promise of “faster, better, cheaper.”

The company I work for recently published a study that quantifies the importance of reuse to product-development professionals: 95% said reuse is important to delivering on time.

It all boils down to efficiency. Yet, despite all the enthusiasm, reuse is rarely implemented in a way that provides the promised value. Several key factors are associated with this:

  1. The definition of reuse needs to get beyond “copy and paste.”
  2. Successful reuse requires an organizationwide adoption model.
  3. Technology isn’t always aligned with desired capabilities.

Let’s go through each in turn.

Defining Reuse

According to BABOK, reuse falls under the “Requirements Management & Communication” section. In general, the BABOK is fairly light on this topic, referring to reuse as a “repository,” and advising businesses to identify a person “to manage the repository.” There’s mention of “impact analysis,” and that requirements should be identified as “candidates” based on an organization’s long-term needs.

These are all important concepts, some of which will be addressed in more detail here, but I think a more practical definition is in order. Here’s my attempt at defining reuse:

Reuse is an agreed upon policy, where by, separate or related teams, projects, or departments, are able to utilize previous work done in such a way that new work can be accelerated. In addition, on going changes to the reused information should be shared, such that the different entities can accept, reject or merge the work.

The idea here is that while many people view reuse in terms of copy and paste, or linking, it is more around utilizing work done, and keeping that work synchronized over time and across teams.

Example: Team A has just completed building a product. The product could be hardware, software or even a combination. Now Team B is about to embark on a new product that is very similar to Team A’s product. In this scenario, Team B is able to utilize not only pre-existing requirements but also any downstream artifacts such as Use Cases, Non-Functional requirements, regulatory laws, stories, test artifacts and of course the coverage or traceability between them. By reusing this information, Team B has a significant leg up and has saved a lot of work and time and time, (at least 25%, according to the survey).

harris March12 Img01If understanding the definition of reuse is the important first step, the second step is to share this definition organizationwide. 

<< CAPTION: reuse becomes increasingly necessary and provides exponential benefits as products and teams increase in size>>

Successful reuse is an organizationwide adoption

Based on my definition, reuse becomes increasingly necessary and provides exponential benefits as products and teams increase in size; however, as this size increases, reuse also becomes increasingly complex to manage. Therefore, the problem that organizations face is not if reuse should be implemented, but rather how. Like different methodologies, the implementation of reuse is going to vary based on the type of product, the team size, and the organization’s ability to adapt and adopt. 

For this reason, it is important to carefully analyze areas where teams would benefit from reuse and then work backwards to determine the implementation strategy that would have helped. It is also important to find incremental wins while keeping an eye on the big picture so you can expand your reuse strategy over time. For example, you may start by simply reusing the requirements from one product to another, working to keep them synchronized. Later you could continue looking at creating a central repository of common requirements. Finally, you could start looking beyond just the requirements and begin pulling in traced artifacts. This last item is important; reuse is not just a Business Analyst problem, it impacts the entire team. 

As you can see though, this kind of reuse strategy is very difficult to do manually with just documents. To do it right will require more sophistication and better technology. 

Technology isn’t always aligned with desired capabilities

Our desires tend to exist in a realm just ahead of what’s possible. Sometimes technology evolves to meet those desires, even producing unexpected outcomes. Some examples might be Mark Twain’s prediction of the Internet in 1898 through a sci-fi story, or on a more related note, the 2001 Agile manifesto, which called for better collaboration several years before the tools and technologies necessary to facilitate true collaboration were even available; hence, the early push toward entire teams being confined to a single room around a single table. It wasn’t until 2004, when the social networks emerged, that we began to see an evolution in business software and human behavior that favored the kind of collaboration necessary to push Agile into the enterprise. This area continues to rapidly evolve.

The same is true with reuse. The topic has been around for years but until recently, it was very difficult to manage complex reuse without adding an exponential amount of administrative work to keep track of everything. Too much reliance on the trust of too few, rather than on tools or technology.

Some of the solutions today offer some form of reuse, all of which are designed to enable teams to better reuse work that has been done. This might be just around requirements but I believe it goes deeper than that.

How deep does the rabbit hole go?

This brings me to the final question: how deep does the rabbit hole go? Well, considering that we could start with the most basic of copy and paste, this does feel like the beginning. As we go deeper we see that requirements are being shared but remain the same, existing in different places. Deeper still, we see the requirements are being separated but stay synchronized through a change-control process. Digging further down, the lines become blurred as we question what a requirement really is: the text, the meta-data…what then should be synchronized… all aspects of the requirement?, or just certain ones? What about any attachments associated with the requirement, or relationships to upstream or downstream? Does the traceability remain or do the test cases also get reused?

Reuse is a powerful strategy. When done right, reuse provides huge rewards. To reap those rewards as a user, manager or executive taking the plunge, you’ll need to be smart and communicative to avoid losing your head.

Don’t forget to leave your comments below.