Skip to main content

Tag: Business Analysis

Simplicity – The Newest Craze in Agile

My motivation for this article isn’t to slam or denigrate any of the scaling frameworks (and those that continue to emerge). Full disclosure, I’m a SAFE SPC, and I find significant value in leveraging some framework for Agile at scale.

That being said, I have a great concern that I want to share. I think we’re losing some of the original thinking and approaches from early instances of Agile. The methods grew out of small teams doing big things.

But as we’ve gone forward and introduced agility into larger instances (enterprises, large-scale companies, distributed projects, etc.), I’m afraid that we’re losing the very essence of agility that made it attractive in the first place. Things like:

  • Small teams
  • Simple, focused solutions
  • Just enough
  • Face-to-face collaboration
  • Working code
  • High-value delivery

These seem to have lost their attractiveness. I want to share a series of stories that I think (hope) might shine a light on returning to our Agile roots. Or at the very least, might get you to rethink some things.

First Story – Remember Wordstar?

I doubt whether many of the readers will recognize this program. But at one point, pre-Microsoft Word in the early to mid-1980s, Wordstar was the premier word processor on the planet. It was supported on something called CP/M and later on DOS.

What was amazing about Wordstar, at least to me, was that it fit into 64k of RAM. In fact, it fit into less than that because it had to share that space with the operating system. Imagine that, a simple, but full-function word processor fitting into less than 64k of RAM. Clearly the designers had to make incredibly tough choices as to what features were critical to the program. In today’s terminology, we call it an MMP or Minimal Marketable Product.

Did folks complain about missing features and capabilities? You bet! But that didn’t stop a whole generation of programmers from being able to use Wordstar to get the jobs done.

I reminisce about Wordstar and similar programs because I think today we’ve gotten a bit lazy. Since we have hardware resources to spare, we design bloated products just to prove that we can design 100 complex ways to do inherently simple things. It’s easier than thinking about simple designs and simple solutions to complex problems. When Agile came around, it placed a renewed focus on design simplicity, heck simplicity everywhere. Getting to the essence of a problem and solving…just it.

I think we could relearn something important by revisiting those software design goals from so long ago…

The Lesson: Wordstar had hardware limitations that forced the developers to minimize the product to an MMP feature set. Today we would do well to imagine that we had a small hardware footprint to encourage us to be creative, innovative, and frugal in our applications.

Related Article: Agile is Focused on Capacity Equalization

Second Story – Unix

The beginning of Unix is another one of those minimalist stories. It was developed by a handful of developers in the early 1970s at AT&T Bell Labs. While some of the early Unix contributors were considered super-programmers, nonetheless it’s another case where a small group did big things.

As Unix’s popularity grew, the software got bigger of course. However, I still remember the “erector set” nature of basic Unix commands and how you could “pipe them together” to do more complex tasks. The architecture itself was simple, yet elegant, and it remained that way as it historically expanded.

In the early 1990’s, Linus Torvalds famously released an Open Source version of Unix called Linux. In the beginning, it too was incredibly small. He initially worked on it himself and then with a small group of dedicated maintainers. Again, Linux has grown well beyond its original size constraints. But both systems are clear examples of elegantly designed small systems that had a huge impact on our technology.

The Lesson: Again simplicity, but not only that, the beginning of the realization that a small group of programmers could deliver big, useful things. It didn’t take a team the size of Montana to deliver meaningful products or applications.

Third Story – Bloatware and Pareto

I’ve been using a quote for quite a long time in my classes. I can’t remember where I’ve seen it before, but it goes like this:

Less than 20% of the features of Microsoft Word are actually used by human beings on the planet earth. So how did the other 80% of features get in there if they have no (lean) value?

  • Competitive pressures
  • Marketing checklists
  • Flat out guesses
  • Gold plating
  • Feature creep
  • Youthful enthusiasm

All probably contributed. But at the end of the day, the only determinant of value should be REAL customer usage. Now if only Microsoft would agree to trim Word down to size.

Here’s a supporting quote by Kelly Waters from a 2007 blog post:

Anyway, back to my point about the 80/20 rule, Microsoft’s own research found that the average user of Word uses only *8%* of the functionality. That’s 8%! And I wouldn’t mind betting at least 80% of us use the same 8% too! [assertion]. If Microsoft had developed only the important 8% of Word, maybe they could still have captured the same market share? Maybe, maybe not; sadly we will never know.

The article also alludes to leveraging the Pareto Principle when it comes to mining for customer features that truly make a difference. Otherwise known as the 80/20 Rule, here’s an article I shared about Pareto in another context.

The Lesson: Pareto is alive and well and applicable in everything we do in software. We need to continue to look for the 20% of features that deliver 80% or more of the value to our clients. Then deliver that FIRST before we worry about the edge cases.

Fourth Story – Chrysler C3

The original Chrysler C3 Extreme Programming project was the inspiration behind the Extreme Programming Agile approach. I wasn’t part of the project, but my understanding is that it was a typical, large-scale, Waterfall project that failed. There were perhaps 50+ folks who were working on the effort for over a year.

When it was initially cancelled, the project had been a dismal failure. The story goes that Kent Beck made a case for a much smaller team to use a different approach to try and recover the project. The team was about 20% of the original team size.

As you can guess, the team recovered the project and delivered a workable HR system. But the project never met the overall goals and was ultimately cancelled again in 2000.

This was the project where Kent, Ron Jeffries, and several other famous Agilists earned their chops. It also inspired XP as a popular methodology and initiated the movement, as it exists today.

The majority of software projects today make use of XP practices even if they’re not Agile. Those early XP experiments in things like pair programming, refactoring, and continuous integration have proven to be incredibly sound ways to build software iteratively.

The lesson: A small group of focused technical folks can do big things IF they apply the principles and practices of the Agile manifesto. Bigger isn’t necessarily better.

Fifth Story – iContact vs. MailChimp

I worked at iContact from 2009 – 2012. iContact provided a SaaS email marketing application that competed primarily with Constant Contact and MailChimp. At the time, we mostly focused on MailChimp because of their phenomenal customer growth.

Beyond MailChimp being a direct competitor, we were both Agile shops. And I was at the time and still am enamored with the nimbleness of MailChimp.

In 2012, iContact had nearly 400 employees. Around the same time, MailChimp was reported to have approximately 80 employees. So they were 20% of our size. I just did a LinkedIn search for MailChimp and it showed 106 employees. So they are still relatively small and nimble.

What’s my point?

Well, to put it bluntly, MailChimp cleaned our clock! They kicked our butt when it came to head-to-head comparative measures of our SMB email marketing applications. They were quicker to deliver features. They were quicker to change and pivot directions. They were more creative, bringing out a freemium offering that drove tremendous growth A strategy that we tried to copy and failed.

I’m currently a MailChimp customer, and I’m amazed how insightful they are into the needs of their customers and how frequently they bring out new and, more importantly, useful features.

If you extrapolated from the numbers, we had about 100 people in technology. Mailchimp would have had 20-30 of the same folks developing, deploying and supporting their products.

I was at the time and still am envious of them. They were truly Agile in spirit and action. They had an incredibly small team that built and evolved a robust email platform that simply rocked in its market space.

The Lesson: We all seem to have a tendency to bring more people to bear on problems, under the impression that we’ll achieve our goals faster. However, that often doesn’t happen. Instead focusing a small, Agile team on thoughtful, high-impact client goals seems to be a winning strategy.

BTW: there are numerous other companies that are quite small, but that do incredible things. One historical example is 37 Signals the makers of Basecamp. Another is Menlo Innovations, who focuses on application development.

Final Story – ChannelAdvisor

Here is one final story just to finish whetting your appetite around my article themes.

This comes from my personal experience. During 2007 – 2009 I worked as an Agile coach and leader at a company called ChannelAdvisor here in Raleigh, North Carolina. As with iContact, ChannelAdvisor was an Agile shop (Scrum), and they built a SaaS application suite for eCommerce customers.

We had a large Scrum team that was focused on developing web search application extensions for our platform. The company was growing, and we were of the habit to grow our Scrum teams rather large before we would split them into two smaller teams. Our search team was approximately 12 in size.

A business priority change happened that caused us to split the search team in two – essentially making two Scrum teams of six members each. One continued to develop the search application, and the other was redirected to another component area.

What’s interesting about the story is that the search teams’ velocity didn’t change after we split them. They were averaging 25 points per sprint before the split and 24 points per sprint after the split.

I know what you’re thinking…that’s impossible. Well, no, this really happened. So what was going on here?

Simply put, the smaller team was more efficient in delivering software. There were fewer communications channels, fewer hand-offs, more collaboration, and better focus on their goals.

The Lesson: Try to solve your problems with as small a team as possible. Let them form and mature and achieve a steady velocity. Then “feed them” a prioritized backlog. You may just be surprised at how much they can get done IF you get out of their way.

Wrapping Up

I think that all of the scaling hoopla is just that. I don’t believe we have a distributed team problem or a scaling problem in today’s small or large-scale Agile contexts. And huge applications don’t need to be built by 10-50 Scrum teams.

We have an un-scaling problem. We have a boiling the ocean problem. We have a trying to throw too many people at it problem. We have a love of size and scope problem.

We’re looking at problems and creating the most complex solutions we can come up with. We are enamored with:

  • Distributed teams and/or large groups of teams
  • Way too complex architectures and designs
  • Solving problems with project management thinking
  • Management solving problems with “old thinking”
  • Building bloated software with features nobody uses
  • Not truly understanding our clients
  • Allowing business-facing folks to ask for everything
  • Scattershot vision hoping that we eventually hit the target

I can’t tell you how often I hear someone explain why his or her systems are complex. They reference the complexity as a badge of honor and a must have.

I would argue that there is no need for 100’s of developers to build systems. Small teams can do great things. That is if we allow them to do it.

That was the essence of agility in the beginning and it still is. I hope this article has inspired you to reduce your teams, break up your products, and take a new look at how you build your software and what you build.

Remember – a handful of Agile teams can do great things. And a handful of product visionaries can guide them towards just enough, lean, and wonderful software.

Stay Agile my friends,


The Transformational Enterprise Business Analyst

Why do we keep talking about the Enterprise Business Analyst (EBA)? Because it is quickly becoming the pivotal business/technology role of the future.  The EBA is a business-driven strategic partner and integrator, an enabler of organizational change, and the driver of business success.  As a strategic partner, the EBA often becomes an internal consultant – a business relationship manager at the top of the food chain of the BA profession. 

Operating at the enterprise, strategic level, the EBA engages in radical collaboration, as the Stanford University Design School refers to it.  The EBA understands that today’s complex projects demand an unprecedented amount of teamwork and cooperation among all key business and technology roles in a critical project.  Indeed, shared project leadership is replacing old project management models.  Perhaps the most valuable partnership when operating at the enterprise level is the one between the project manager and the business analyst.  


The BA and PM work together to ensure projects are launched to bring about innovative solutions, value to the customer, and wealth to the bottom line.  All decisions are made with the customer in mind.  Changes that add value are not only welcomed but sought after.  

Related Article: The Future is Now: The 21st Century Enterprise Business Analyst


The rise of the EBA marks a significant departure from business-as-usual business analysis.  The EBA is a strategic asset to decompose strategy into valuable change initiatives.  The EBA plugs the gap conducting the burden of analysis that is too often missing from business/technology project prioritization and selection.  

EBAs work up front and personal, in support of an investment framework based on business value.  The EBA performs the due diligence that is so often missing during project initiation. This due diligence includes competitive analysis, problem/opportunity analysis, experimentation, creative brainstorming, early complexity assessment, and captures the results in the form of a business case to propose a new change initiative.



The EBA employs transformational practices to bring about value-based decision making and project management practices.



The EBA fulfills many strategic roles, essentially putting a finger in the dike for many areas that have been woefully inadequate in organizations today, from business relationship manager to internal strategic consultant.


Business Relationship Manager and Internal Consultant

As business relationship manager, EBAs fully understand the needs of the business, from vision and strategy to execution of operations.  EBAs build executive level relationships as well as relationships with lower level managers and practitioners.  They decompose strategy into valuable projects and programs.  They lead creativity sessions to ensure we conceive the most innovative solutions.  They create business cases to propose new initiatives.  They conduct competitive analysis to understand where their industry is headed.  They coach project teams to ensure the teams understand the business need and the value expected from the initiative.


The EBA often has a seat at the table with the executive management team, participating in strategy sessions, facilitating the management team through problem analysis, alternative analysis, and opportunity analysis.

Innovator, Designer, and Architect

The EBA understands that creativity is a skill that can be learned.  Understanding and using design principles enable EBAs to lead sessions to design the transformation prior to examining alternative solutions.  Using architectural techniques, the EBA makes the future visible through models and rich pictures.

Business/Technology Optimizer

World-class EBAs stay ahead of trends within business analysis, technology-enabled business practices, and in the industry of their choosing.  However, staying up with trends is a difficult undertaking because of the amount of information that is out there; it is voluminous and can be overwhelming. The trick is to concentrate on keeping abreast of business and technology trends at a high level, and go deep in a just-in-time learning manner.  That is educate yourself on areas of interest at the time when you need to apply them to your current endeavors.  

The EBA thinks holistically about the business, the ecosystem surrounding the business, and about the technology supporting the business.  The EBA understands where the industry is headed globally, and how that will impact their organization.  In addition, effective EBAs understand the current technology infrastructure, and trends that are emerging.  Some of the contemporary areas of focus include:

  • Collaboration and productivity
  • Customer & operations support
  • Cyber Security
  • Digital, wireless, and mobile spheres 
  • Software
  • Open technology
  • Internet of things
  • Compute
  • Networks
  • Social media

Leader, not Manager

In performing all of these roles, the EBA becomes a value-driven strategic resource for the organization.  The EBA has mature influence skills, collaborating with project managers and other key change agents.  The EBA understands how to build and sustain high-performing teams.  In a given week, the EBA might serve as:

  • Strategy and Competitive Analyst
  • Strategy Executor
  • Value/Benefits Manager
  • Creativity and Innovation Enabler
  • Transformational Designer
  • Cultural Change Manager
  • Team Leader

Lead through Connections

The world is hyper-connected. EBAs leverage the collective intelligence that resides in the untapped knowledge of their network. EBAs can embrace the dynamic tension between creative disruption and operational efficiency. EBAs cultivate organizational creativity in an age of complexity.


The traditional measures of project success have been on time, cost, and scope. Even with advances in technology and the project management and business analysis professions, superior project performance remains elusive. The CHAOS Manifesto 2013 reveals that 61% of IT-enabled business projects continue to fail to meet project cost, schedule, and scope goals.

In the 21st century we need to achieve 90% of projects on time, cost and scope through smaller, incremental development of solutions. And at the same time, our focus needs to be on innovation and value. Companies that fail to innovate will get lost in the dust of agile, fast-moving competitors. So, our new project success model needs to look something like this:


Clearly, the business analysis profession needs to step up to the plate to close the gap in project performance, and the EBA is emerging as that transformational role. EBAs are drastically changing the way we manage projects. EBAs adopt a more holistic view of change initiatives so that we:

  • Focus on delivery of business value and innovation vs. requirements management,
  • View change initiatives holistically, understanding that critical projects will likely impact the entire business ecosystem of people, process, organizations, rules, data, applications, and technology
  • Embrace architecture and design to help temper complexity and uncertainty, and
  • Strike a balance between analysis and intuition, order, and disruptive change.

Look for us at the Building Business Capability Conference in Las Vegas in November.

i Leading Through Connections, Insights from the 2012 IBM Global CEO Study (‎

Getting the Project Client to Focus on Requirements

Having trouble extracting project requirements from your customer? Does your project client think they have already handed you all of their requirements and is asking why you aren’t starting to design the solution yet? Are they worried about eating up the project budget with useless planning when you could be starting the “real” work on the project?

I know starting the real work on the project is tempting. It may even be possible – if it’s a two day or two-week project. But if your project is of any length and dollar amount to speak of, then you must – repeat MUST – have genuine project requirements. These requirements must be detailed enough to design and build a solution, and complete and complex enough for you to avoid making wrong assumptions that result in expensive and time-consuming rework later on in the engagement.

You can’t please everyone all of the time

For me, it’s about asking the right questions. For the business analyst who is likely leading much of the requirements definition effort and functional design document work, it has to be about asking the right questions as well. What the customer thinks are the requirements usually aren’t the real requirements. Often, as many have found, and the rest will soon discover, what the customer thinks is the problem is probably only a symptom of the real issue. The actual project may be a few layers down – and that’s the problem, need or issue you need to address. Otherwise, you’ll end up delivering something that doesn’t solve the end users’ real needs.

You may have followed the customer’s perceived requirements perfectly and gotten paid handsomely at the end of the engagement (and during). But 30 days later you find out that your customer is not very happy because what you delivered – while spot on with requirements – is not what they needed. And you now have a dissatisfied client and one who will likely point the finger at you while going somewhere else to get it fixed, and their overlooking you for their next project. Ouch. No, let’s get it right the first time. Here’s how you get there.

The key questions for the client

Related Article: Process Approach to Requirements Gathering

What are you current business processes as they pertain to this project?

The key here is to understand how the business operates now. It will help you understand their need or the perceived need. It will help you see the layers you may need to dig through to get to the “real” need if it isn’t the one the customer is currently presenting. It will help you see who else you may need to include in the discussion. What other key areas of the business are tied into this process? You should find that out here.

What do you want the new solution to be?

This one goes hand in hand with the question above and will give you even more insight into what the customer is thinking and if the real need is the one they have identified. Knowing the “as is” and the “to be” environment is critical to connecting the dots to get the client there. The “as is” situation tells you where they are coming from, and the “to be” will tell you a lot about what they are hoping to accomplish. It may help you better define the questioning process from this point forward.

What specific problems are your end users experiencing?

This is where you find out how tied into the process the end users are or have been up to this point. Maybe they originated the project request. Or maybe they know nothing about it. You need to know the answer to this question, and you need to draw them into the process. They are key.

Do you have specific technology needs or wants in mind?

There may be some underlying desire for a specific technology. I’ve gotten to this point a couple of times only to find out that a new technology – no real urgent need – is the only reason for the project. That’s not a bad thing – just a good thing to know up front. It may (or may not) change how you manage the project or the urgency of it. Just ask, you won’t be sorry.

Is this project supported by the executives?

Finally, make sure there is support for the project by the higher ups. It may not be appropriate to ask of an outside client. But if this is an internal project, it is definitely a question to ask. Why? Because lots of project “phishing” happens before any real funding or project approval has happened when you’re dealing with projects that are internal to your own company. They tend to skirt the formal process and may end up wasting a lot of your time and PMO time when there is no project out there. And how do you approach this on an external project? Well, carefully. But a skilled PM or BA can figure out a way to ask if the customer’s leadership is behind the effort. If you see this as a “weak” project or one that may not really be necessary, it’s a good question to ask no matter how you may go about it.


There really aren’t any magic questions that will that will draw out everything you need to know to deliver the right solution. No magic question that will make everyone happy and make all those potentially costly change orders completely unnecessary. Stuff happens, change orders happen, requirements change and sometimes they are foggy no matter how hard you try. They key is to try hard up front – put the effort into it. Good PM and good BA oversight and investigative questioning of the project client will get you 90% of the way there. The other 10% will be experience, skill, interpretation and a little luck.

How about our readers?  What do you “ask” or “demand” to get you through the muck to the real customer need and true customer requirements?  Please share your thoughts and expertise (and failures if you don’t mind).

Avoid These Phrases – Or Your Project Will Fail!

Everyone recognises the importance of good requirements writing. Good requirements must be written in such a way as to be clear and unambiguous to all readers. Explicit requirements require fewer review cycles to achieve approval.

Requirements that are vague are open to interpretation by stakeholders. It’s easy for such phrases to creep in when defining requirements but they are risky and will inevitably lead to confusion, wasted effort and rework. For Example:

“Flexible”. The business’s definition of flexible and the developer’s definition of flexible might not be compatible so be SPECIFIC about the actual variables. Requirements must say exactly what is needed by the business. Specific requirements must be clear, simple, consistent and at an appropriate level of detail.

“Some”, “Several” or “Many”. State a specific value, or provide the minimum and maximum limits, this will help to clarify exactly what you want in terms that everyone can understand. Requirements must be MEASURABLE, it must be possible once the system has been developed, to verify that the requirement has been met.

“Better”, “Faster”. In the context of your requirements, quantify how much better or faster constitutes a satisfactory improvement, this will help you ensure the requirement can be ACHIEVABLE within the constraints of the project and existing systems. If you can, sound out your requirements with a developer to ensure feasibility.

“Etc.”, “Such as” or “So on”. Be explicit about what happens next. Don’t let people guess the next steps as this could lead to various incorrect outcomes for your requirements. Requirements must always stay RELEVANT, you must be able to connect a requirement back to the overall business objective.

“Acceptable”,” Adequate”. Define the acceptance criteria, ensure that there is a statement or statements that can be used to determine a pass or fail result for each requirement. In other words it must be possible to design a TEST or come up with a means to determine if a solution has met the requirement.

Such ambiguous phrases should signal that requirements are incomplete and need further clarification with the stakeholders.

At Be Positive we use the SMART (Specific, Measurable, Achievable, Relevant and Testable) acronym to help avoid some of these troublesome phrases.

If you stick to writing SMART requirements you should find that you avoid ambiguous phrases naturally. But just to be safe, an effective check for ambiguous phrases is to consider your requirements from the perspective of a Tester. If you can’t envision a test that would determine whether or not a requirement has been met, you need to be more specific.

Ambiguous phrases must be corrected at the earliest point in the solution delivery lifecycle (defect avoidance costs much less to resolve than defects identified in subsequent phases of the solution delivery lifecycle).

Dear 007, Am I Finished?

Sometimes I get questions from BAs and PMs, and when I can’t answer them, I pass them on to CBAP 007. With an IIBA license to drill, no business analysis issue is too big or too small for this experienced professional. Here is one from July 2015:

Dear 007:

My project manager tells me to “finish the requirements”, but no matter what I turn in, she says it is not finished. When I ask what else she wants, she says she wants everything. When I suggest that everything costs infinity, she says I have an attitude.

She is right (about my attitude). What should I do to “finish” the requirements?


More Finished Than She Thinks

Dear More Finished Than She Thinks:

I assume that you, like most BAs, understand that requirements are rarely “finished” in the sense of being complete to the satisfaction of every stakeholder.

The most complete requirements ever written for a cell phone did not include the contingency factors inherent in a pair of boot-cut Calvin jeans worn two sizes too small and stuffed with an understructures oversize phone chassis.

Don’t even ask about rubber gasket temperature requirements for Space Shuttle boosters – they WERE included as requirements, but ignored by project management in spite of their completeness (“But Reagan is sending a teacher into space and giving a big speech – it’s a deadline!”). Deadline, indeed, but not a requirement.

SO, I assume that the words “finished” and “everything” means something different to your PM than they do to you. Let’s try a few definitions – if one of these fits you may realize what to do.

Does finished mean? :

  • I (the BA) can’t tell that anything is missing
  • She (the PM) can’t tell that anything is missing
  • We (the other Business Stakeholders) can’t tell that anything is missing
  • They (the Implementation SMES) can’t tell that anything is missing
  • It (the solution as implemented) can’t tell that anything is missing (everything” works)
  • Notice that none of these definitions involve anyone saying “I can see that X, Y, Z are missing” which would be more helpful.

Now for a definition that helps. Completeness is best defined at a GIVEN LEVEL OF DESCRIPTION. In the BA profession, we look to BABOK for the correct categories and levels of description. In this case, requirements have the following levels of description:

  • Business Requirements (High-level statements of key business needs, approaches and strategically justified capabilities that must be met regardless of stakeholder wants)
  • Requirements[Stated] (stakeholder wants and concerns not necessarily analyzed)
  • Solution Requirements (functional, work to be done)
  • Solution Requirements (non-functional, qualities of any solution to be implemented)
  • Transition Requirements (temporary needs and efforts, until “full” implementation)

“Our business has a need to deliver legal documents to its customers every day on less than one hour’s notice,” might be a COMPLETE business requirement. Make sure to comb your requirements and collect all the “high-level” actual business needs (as opposed to personal preferences, see below). You will discover some “low-level” requirements that imply high-level requirements, and vice versa. Separate them (analysis) into their own groups, rewrite them to fit their level and category. THEN IT BECOMES EASIER TO SEE WHAT IS MISSING AT THE HIGH-LEVEL. This is where MOST IT project mistakes get made and is the most important to get complete.

“I want a car so I can make those deliveries for the business” is COMPLETE in the sense of being a stakeholder requirement [stated, not analyzed]. Make sure that you comb your “requirements” and collect all the “not-really requirement” statements and put them into an “elicitation” document for further analysis. The “requirements” are not finished, because they are not analyzed, but COMPLETE in the sense of being everything the stakeholders said).

“Bicycle couriers average 12 miles an hour in city deliveries, vs. 7 miles an hour for cars. Feasibility ANALYSIS suggests outsourcing delivery to couriers (or we can buy the stakeholder a bicycle instead of a car).” This might be a COMPLETE solution requirement (functional) – DELIVER LEGAL DOCUMENTS. Collect all the actual work functions implied in all your requirements, and list them in one place. It becomes easier to see what is missing (e.g., PREPARE PACKAGE WITH CORRECT DELIVERY INFO, and CONFIRM TIMELY DELIVERY WITH CUSTOMER). To be complete, list all the IMPORTANT business processes, and let the less important arise as needed (e.g., we need to ASSIGN DELIVERY TO COURIER SERVICE as a critical business function, but we can decide to implement this assignment via text message as we negotiate with the courier service. Is the requirement complete, if this “text message” spec is unresolved? Not really (see the beginning), but it is LOW risk and focus belongs on other higher level issues (e.g., how to MEASURE delivery performance objectively, once assignments are made).

“Delivery in less than on hour” was already stated as a business requirement – it is (for this simple example) the COMPLETE solution non-functional requirement – a service level guarantee. Can you think of any functional requirements that would help guarantee that service level? Put those above – group like with like.

Finally, transition requirements. Who has to be informed, trained, won over? Do we have to convert data from the secretary’s Rolodex to a label print system for the courier packages? What is the implementation plan (oh project manager mine). The project plan (think about it) is largely “transition requirements”, and should lump upon the head of your PM as much as on you.

IN short, if you use BABOK categories, you avoid level mixing, confusion, and you gain the ability to see what else belongs at that level. If you do it right, you will perceive redundancies between levels. This is normal, and shows traceability and shows that requirements are related across levels (that is why it is so easy to mix them up and get confused about how complete they are). An example of a seemingly redundant requirement was “Delivery in less than an hour”. At the business level, it is a service strategy defined by a performance level. At the non-functional level, it drives measurement, verification and other functional requirements. By putting it in both places as appropriate, COHERENCE is achieved, which helps stakeholders in perceiving completeness.

ALWAYS START BY FILLING IN THE HIGH LEVELS TO MAXIMUM COMPLETENESS. IF there is no time to “finish” a lower level, you might not even start it. Don’t spec the detail steps of MANAGE USER PRIVILEGES just because you can – stick with high value high-level critical business processes such as VERIFY TIMELY DELIVERY, and try to “complete” the success scenarios. If you have time, go for the top 3 alternate scenarios. At each step, decide how much you can accomplish and put BABOK boundaries on the work so the completeness can show.

THEN when your manager says to “finish” the screen color requirement, you know which requirement and what is missing.

Je suis finis – et vous?

Please comment below – let me know what you DIDN’t get, so I can finish it 🙂