Monthly Archives: November 2006

First IIBA Certification Exam And More


This is a bit of a potpourri post. Found some good stuff out there today, check it out.

The first IIBA Exam just finished in Orlando Florida. Barbara was one of the 16 business analysts who took it. Read about her experience!

Her post has inspired me to crack open my copy of the BABoK again, so here’s some great stuff that other people have written recently:

Understanding The Goal by Marcus Ting A Kee

Marcus presents what reads like a fantastic real-world example, even though he starts with “Suppose a client…” Real or imagined, it is a great example, well written. A single idea, presented crisply. Great quick read.

A couple presentations by Kevin Brennan hinting at changes for the next version of the BABoK. In the BA Fundamentals presentation, Kevin presents the definition of a business analyst in a really interesting way. He starts on p9 with the complete definition:

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

This definition feels pretty heavyweight (although rigorous), and it reads like an eyechart but check out what Kevin did on slides 12 through 19. Great way to present the fact that BAs do a bunch of things, and the quote above is already a shortened description of everything we do. Criticism retracted. I would like to figure out a more concise way to describe the BA role, but nothing comes to mind at the moment.

How To Not Suck At Design


Michael Shrivathsan just wrote an article presenting five tips for creating products with great design.

Michael’s List

  1. Start with the user interface. [Roger Cauvin adds, start with a working first iteration]
  2. Work closely with UI designers.
  3. Pay attention to details.
  4. Simpler is better.
  5. Be brave.

Our Thoughts

User centric design is the core of UX and interaction design. It is the most effective way to design something that is a pleasure to use. As Michael points out, almost no one does it. Kent Beck (founder of Extreme Programming) argues with Alan Cooper that all the up-front design work to understand the users is wasting time that could be used to build something valuable. Cooper argues that designing for the users is the most important thing. They are both right. There isn’t a black-and-white answer to that debate.

Simpler is the key to avoiding featuritis, where too many features actually make a poduct less effective.

Being brave. Great point. Great designs are product leaders. Many politicians try and predict where the population will be (test polling, trial balloons, etc), and then try to get there first – so that it looks like leading. Not very brave. Michael’s examples of the iPod and GMail are good ones. Both products demonstrate design departures from “everybody else.”

Our Additions

We would also add

  1. Have Valuable Innovation. Innovation for it’s own sake isn’t worth much. GMail uses tagging (instead of folders) because it is valuable. Folders require every email to only be in “one place.” Tags allow emails to be in more than one place. That’s valuable innovation. [Here are ten tips for preventing innovation too – one of the most-read posts at Tyner Blain]
  2. Focus On Killer Features. Prioritization drives the identification of what is actually important. Don’t do the other stuff. Combine this prioritization with Simpler Is Better to get the most bang for your buck.


Great ideas from Michael. Thanks!

Valuable and Functional Requirements

group exercise

Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.

Roger’s Questions

We started with an example of a quantified market requirement. We then extended that example to show how to create product requirements from the market requirement. As part of the ongoing conversation, we clarified the semantics of our language with an article about context and perspective. Roger’s comments followed that article.

Okay, so if I understand your semantic framework correctly, we have:

market requirements – goals to achieve to solve market problems
product requirements – goals for the software or product to achieve
functional requirements – what developers should build

But then:

1. Can a market requirement be functional?
2. Can a market requirement be nonfunctional?
3. Can a product requirement be functional?
4. Can a product requirement be nonfunctional?
5. Is it the case that every requirement is either functional or nonfunctional?
6. Are the functional requirements what the developers should build, or do they need both the functional and nonfunctional requirements to know what to build?

Roger Cauvin

Valuable Requirements

Market requirements and product requirements are not about functional / non-functional distinctions. Market and product requirements are about value. These requirements are designed to identify opportunities (market requirements) and identify strategies for addressing them (product requirements). They do not specify how a particular implementation approach (product, process, etc) will achieve them.

Market requirements and product requirements are goals.

Goals can be driven by

  • Hard ROI. In our example, we target a 50% reduction in food spoilage cost. Hard ROI goals are measurable.
  • Soft ROI. Branding is a classic example of soft ROI. A strong brand will drive more (or better) sales of a product. But you can’t quantify how much a brand is improved or how much that improvement will improve your margins.

So, to answer the first five questions:

Market requirements and product requirements are neither functional nor non-functional. They are valuable, and the value is either measurable or not. Therefore, not all requirements can be classified along the functional/non-functional axis. Along that dimension, market and product requirements are undefined.
What Should Developers Use?

Roger’s final question is a bit unrelated to the first five. Developers should not be writing code (creating designs) directly from market or product requirements in a structured requirements framework. They should be building the solution relative to a functional requirements document or software requirements specification (FRS or SRS, respectively). We can see the continuum of documents in the following diagram from One Man’s Trash.

Requirements Document Continuum

In that diagram, we describe five layers: market, requirements,specification,design, and implementation. The design should be built from the specification, and the implementation should be built from the design. Note that this framework holds true for both agile and waterfall processes.

Non-Functional Versus Functional

The FRS is unfortunately named, as people could infer that it therefore excludes non-functional requirements. Non-functional requirements are still requirements, and deserve equal attention. The following diagram shows that non-functional requirements are derived from (or created in support of) goals, just like functional requirements.

non-func structure

Both are components that drive design and therefore implementation.

As an aside, constraints don’t drive requirements, they drive design. An example of a constraint in the wild: Numenta, Inc. is creating memory systems modeled on the way human brains process information. Their software development choices, when creating applications (like robot navigation systems) are constrained to use this particular technology.


Market requirements and product requirements can be characterized based on value, but are undefined along the functional/non-functional axis. The requirements that make up a specification can be classified as functional or non-functional. And these are the requirements that drive design. Design boundaries are defined by constraints.

6 Tips To Double Your Requirements Interview Effectiveness

Several Q Tips

Being effective at interviewing is key to gathering requirements effectively. We suggest six tips to make the interviewing process more effective and efficient.

Interviewing Primer

To be successful at interviewing subject matter experts at gathering requirements, we have to first understand how to interview our experts. This understanding allows us to define our approach, plan, and follow-up after the interview. Having a good framework for the interview is neccessary, but not sufficient. We also need to be good listeners. Being a good listener encourages our interviewee to answer our questions more comfortably and openly.

But to be truly effective, we need to do more than that.

Why This Is Hard

One of the business analysts on my team and I were reviewing actual performance, specifically time spent on-task versus time estimated for gathering and documenting requirements. We found that the time spent in subject matter expert (SME) interviews was more than double the original estimates. We found that repeated interviews and iterations were required to get a reasonable documentation of the process. We reviewed the documents and agreed that the level of detail was roughly what we desired, and that the problem was in having too many iterations.

We found that the extra iterations were needed because

  • Systemic clarifications were required – the initial drafts bore little resemblence to the final draft.
  • Areas of business process were missing – initial process documentation only showed the most common cases.
  • Generalizations and vague statements peppered early drafts – ambiguous and incomplete statements were taken at face value initially and refined later.

The good news is that we got the desired documents, at the desired quality level. The bad news is that it took twice as long as it could have taken. The SME for this area of requirements gathering knew the subject very well. We discovered that we were struggling to get the data from the SME efficiently. We discussed half a dozen ways to improve the analyst’s interviewing process to address these challenges.

Six Tips To Double Effectiveness

  1. Use Absolute Statements. This is a modification of an active listening technique. When the SME says “We generally follow up X with Y”, respond with “OK, so you always follow X with Y.” This helps when working with a SME that doesn’t use precise language. One source of iteration is “well, I forgot to tell you about this exception.” The best SMEs can usually do their job in their sleep. And that is great, except that it makes it easy for them to forget to tell us important stuff. Experts can quickly deal with exceptions when doing the work, but often struggle to prepare others for the exceptions. “Always” becomes a magic word – the expert immediately knows that always is wrong, and won’t hesitate to tell you.
  2. Not The Opposite. Twist the SME’s words around. When the SME says “We always X if Y”, respond with “If not Y, then never X.” Sometimes, saying always all the time gets old. An our SME may start to tune it out (always == generally). By reversing the logic, we force them to think about it backwards – usually enough to jolt someone out of the cycle. The logicians out there will recognize this as modus tollens. A sneaky but solid argument. X leads to Y. That doesn’t mean that if we have Y, we must have had X. But it does mean that if we don’t have Y, we can’t have had X. For example: Fire produces heat. There are other ways to make heat (fire is not required), but if we don’t have heat, we definitely don’t have a fire. This can disable the autopilot that SMEs sometimes have when describing a process.
  3. Apply Other Patterns. Many business processes have a lot of similarities. The folksy phrase “It’s the same, but different” captures the situation perfectly. When interviewing about process X, try and think of similarities or patterns between process X (which you don’t understand yet) and process Y, which you already understand. Try and apply the pattern from process Y to process X – ask if it will work, and then ask why it won’t work. You may find an otherwise hidden step in X, or a need to update Y. For this approach to work, you have to be completely fearless about sounding like an idiot. If you believe stupid questions come from stupid people, then you’ll struggle with this one.
  4. Ask For Examples. Ask the SME for examples or scenarios that cause a process to behave in a certain way. If you aren’t using a process-centric approach, ask for examples that exercise different business rules. Make sure and get an understanding of the frequency of these examples. Some SMEs will think like a rules-engine, and propose all of the exceptions as examples. Start explicitly with an example of the most common situation. This is analogous to the normal course of a formal use case.
  5. Create Examples. A merciless way to test your listening effectiveness is to create your own examples, intentionally designed to exercise a particular rule, or create a specific outcome, or test a selected branch of a process. When your understanding has gaps, your examples will have flaws. These flaws are extremely visibile to subject matter experts – and the SME is almost gauranteed to interrupt you to fix your example. These are the exception courses of the use case.
  6. Draw Stuff. Make truth tables on the whiteboard. Draw flow charts showing branching logic. Add visuals of the different actors – and make them fun. Managers wear ties, engineers have glasses, accountants have eye-shades. Or colors, whatever is fun for you. And name the users, or people, or companies in your examples. These names help a SME (pronounced ‘smee’) to think about a process in the specific, not the abstract. Combining these visuals with examples changes gears for our SME. By changing gears, we are picking the lock of our SME’s vault to get to the good stuff. These examples should poke at the boundary cases, to make sure that we have a good understanding of the process.


These are all refinements, or specific approaches to active listening. Their goal is to get more thorough information from a subject matter expert in less time than it takes to interview repeatedly and iterate on the documents. And they work.

Quick Post on Passion

Why Passion is Important

Thanks Kathy for Two Simple Words of Passion

I distinctly remember some eye-rolls when we posted Writing Passionate Requirements as part of the Big Ten Rules to Writing Good Requirements series.

When we are excited about our product, and believe in the value for our customers, we will write better. When we know that we are doing work that is worth doing, we approach it with that ‘extra something’.

Have a great weekend!

Requirements Context

Dubai Hotel Tennis Court / Helipad

Understanding someone’s perspective on requirements requires that you appreciate the context in which they’ve formed that perspective. Not everyone is playing the same game on the same field.

Words and Symbols

When someone says “write a test case”, we may wonder if they mean system test, or unit test, or user acceptance test, or regression test. Without more information, we don’t really know what they mean. But we do know that they aren’t talking about implementation or design or requirements gathering – they are talking about testing.

When someone asks “document the requirements”, we don’t know what they are talking about. They might mean market requirements, or product requirements. They may mean functional, or business, or user requirements. As product managers and analysts, we have to understand the perspective of the listener before we can determine which type of requirements document is required.
The very word, requirements, has become a touchstone for debate – almost the third rail of software development. There are two factors that create the semantic debates about what requirements are and are not.


Every person on a software development team works within a given framework. From that perspective, there is a notion of why something needs to be done. An individual has an idea about what he needs to do. And while he may delegate getting stuff done, he will still talk about how it needs to be done.

The variations in framework have spawned many different requirements documents.

Even when we recognize that there are different ways of perceiving why, what, and how, we still run into a problem when debates involve the use of the word requirement. The word has developed a symbolic representation for many people. The problem is that the symbol is ambiguous, because it doesn’t mean the same thing to everyone.


Roger commented on our recent article about defining product requirements to support market requirements. In that article we showed a transition from market requirements (clarity of vision, too vague or high level to be actionable) to product requirements (a given approach to solving a market problem). Roger wanted to know if use cases fall in the space between market and product requirements.

No. :)

In a structured requirements approach to documentation, we have a diagram that looks like the following:

structured requirements

We also wrote about combining interaction design with a structured requirements approach.

In both of these situations, use cases live between goals and the functional spec.

Market and product requirements are both at the “Goal” level. [More detail in this article]. Use cases are used to convert a vision of how a product will exploit a market opportunity. Use cases describe how the product will be used. And functional requiremens enable communication between the business and the implementation team.

User cases live between product requirements (GOALs, above) and a functional requirements spec with enough detail to allow people to follow it.

Bad Usability Calendar From Netlife Research

January from Netlife Research

What a great way to demonstrate 12 key usability concepts – creating a calendar where each concept is demonstrated.  You’ve heard the saying – “If you can’t be a good example, be a horrible warning.”  Here is that saying manifested in calendar form.

The Calendar

A Brilliant presentation of the importance of usability.  Brilliant because it is fun, and the ideas are all extremely well executed.  Thanks to Netlife Research for this!  And a hat tip to Jesper at  Netlife’s main site is in Norwegian, which will be a pleasent surprise for some of our readers.

The other twelve months of the calendar are available in a pdf (go to to get the download), and are really great.  My favorite ideas (cleverly done in calendar as examples of how not to do it):

  • Give All Pages Suitable Titles and Subtitles
  • Don’t let news and information take up too much space from the main focus
  • Use a language the users understand


Thanks, Jesper, and happy birthday – the one year mark is a big deal for a blog!  Jesper’s current “highest traffic post” is a roundup of 30 ajax tutorials.  Let’s see if we can push the bad usability calendar to the top of the list for year two of  Go check it out!

From Market Requirement To Product Requirements


Last week, we looked at an example of market analysis, defining first a market opportunity, and then a market requirement. We wrote an article a while ago about how to go from an MRD to a PRD. In this article, we will look at the journey from our example market requirement to associated product requirements. And thanks, Roger, for throwing down the gauntlet.

Background Perspective

We have shown that the same statement means different things to different people, depending on their perspective. “Improve the handling of that car” could be an implementation or design statement, or it could be a requirement or goal. An executive, faced with market research data could conclude that the best way to penetrate the enthusiast market is by making the car more fun to drive, and would choose to achieve that requirement by improving the handling. An engineer in the automotive design department will sit down to design a new suspension system, or shock absorber, with a requirement – “Improve the handling”.

The difference is perspective. We’ve taken a look at how this affects folks in the software world in our article, …One Man’s Trash.

Recapping Our Example

We’ve identified a market opportunity

Sole-proprietor restaurants are losing over 5% of their top line sales in food spoilage.

And from that, based on our strategy and vision, defined a market requirement

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

Finding a Path

Finding the Path To Product Requirements

The key to making the next step is in recognizing that this is an ideation step. There are multiple ways to address this market requirement. We have to choose one.

The challenge in creating product requirements designed to address this market requirement is that we don’t want to specify design. [Ed: Here’s an article on the difference between requirements and design]. There are many different ways to achieve the requirement, and not all of them involve products, or software.

Different Solution Approaches

With a market requirement of

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

We can reasonably choose any of the following (and so can our customers):

  • Change to suppliers with shorter lead times. This allows us to reduce the amount of food on hand at any point in time, thereby allowing us to reduce spoilage. With shorter lead times, we can better adapt to variations in usage by changing the size of our orders. No product or software required. This improved service will come at a cost – increased ingredient prices, and increased process costs (from the extra order-creation and delivery steps).
  • Change our ingredients. We could use ingredients with a better shelf-life. Canned tomatoes instead of fresh ones. Frozen chicken instead of fresh. These products would last longer, thus effectively reducing the spoilage. While we would still have the same amount of inventory on hand at any given time, we would reduce the amount of “about to spoil” inventory, thereby increasing our ability to deal with variations in demand. This improved ingredient longetivity would also come at a cost – reduced food quality.
  • Change our storage technology. We could start vacuum-sealing all of our ingredients. This would extend their shelf life by changing the “spoilage equation.” This approach also reduces the amount of “about to spoil” inventory, without a sacrifice in food quality or increased food costs. However, this is a product-based solution, with costs associated with the sealing equipment, as well as increased process costs to seal and un-seal ingredients.
  • Change our order sizes and frequencies. Simply put, we have spoilage because we order too much food. We absorb this cost to avoid the risk of 86’ing items on the menu. 86’ing would result in lost immediate sales, and lost long-term sales (by losing repeat business). To reduce our order sizes, we have to do it in a way that does not increase our risks.


Each of the strategies outlined above involves ideation – we think about the fundamental problem, spoilage, and we devise several strategies for addressing it. As a software vendor, the last option is most appealing to us. We believe that our customers can easily achieve some reduction in spoilage with the first option, and incur some cost along with it. It is a net benefit to our customers, so for any sales that we don’t make, we will encourage them to pursue that – after all, losing the sale does not mean we have to lose the relationship.

Product Requirements

We can write product requirements, combining our market requirement (50% reduction in spoilage) with our strategy (make smaller orders without increasing risk). We will also incorporate a couple constraints that guide our software strategy. These constraints represent our understanding of our target market.

  • Our customers will require feedback (on the effectiveness of our software) in order to develop trust and thereby increase usage.
  • Our customers will not migrate their entire business process onto our software overnight – it will be gradual.

Given those added constraints, here are the product requirements:

  1. The system shall recommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline. This is the primary requirement. This is the only product requirement that is directly derived from the market requirement. The remaining requirements are in support of our constraints.
  2. The system shall allow users to ignore its recommendations. Without specifying implementation details (does the system automate the orders, does it print out a schedule to support manual ordering, etc), we know we need to allow our system to be adopted gradually.

Entering a grey area

The Grey Area Between Requirements and Design

This brings us to an interesting place. Consider the next set of statements:

  • The system shall create a prediction of spoilage associated with recommended purchases and timing. This is looking at the next level of detail. We propose that making reccommendations to reduce spoilage be based upon predictions of spoilage.
  • The system shall provide a prediction of spoilage associated with manually entered purchases and timing. Another detail – we want our feedback loop to apply our calculations to “manual orders”, which would help our customers gain confidence in the software more rapidly.
  • The system shall track ongoing food spoilage statistics. Strictly speaking, we don’t need the software to do the measurement for us, but we think that is a good idea. It supports our belief that user adoption is a function of performance validation, and this statement makes that validation process cost less. While our customers may not associate this with a hard ROI estimate, we believe that it does have an ROI impact, based on applying expected value calculations to the anticipated usage of the software.

It is tough to define if these statements represent requirements or design. [Ed: Many individuals will say this is easy to define. But those people will not agree on which definition. Therefore, it is hard]. We admit that using predictions to drive our reccommendations is a design decision. We also believe that the statement provides guidance to software developers about how to approach the solution.

Although we used language patterns that make the statements look like requirements, these statements are actually design. As a validation of that statement, we ask “Can other approaches achieve the same results?” There are many products that are designed for inventory management for manufacturing companies. Those products typically look at minimizing WIP inventory due to the associated opportunity costs of money tied up in inventory. Our problem, while not manifested in the same way, is still the same problem – excess inventory results in excess cost of goods sold. Those products can achieve the same results without predicting spoilage amounts.

Therefore, these are not requirements.


The market requirement:

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

Is addressed through two product requirements:

  1. The system shall reccommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline.
  2. The system shall allow users to ignore its reccommendations.

Additional decomposition of the problem would represent design or could be considered elements of an SRS (which, being a specification, is either design or requirements – depending upon your perspective).

Interrelation Digraphs As Prioritization Tool

opthamologists tool

Prioritization can be hard, especially when we’re dealing with a lot of variables. Peter Abilla, at takes a fairly esoteric tool (interrelation digraphs) and applies it as a prioritization tool. Opthamologists have learned that they can’t show us a bunch of blurry images and have us tell them which one looks the best, and then prescribe a corrective lense. They have to ask us “Is it better like this? Or better like this?” Peter’s approach does the same thing, but with a quantitative edge.

Interrelation Digraphs

An interrelation digraph, also known as a relations diagram, can be used to identify the complex web of interdependencies around hard to understand concepts. In this example, skymark shows the interdependencies of several urban-blight factors and dynamics. The arrows represent influencers and influencees. For example, “there is a high crime rate” is drawn as an influencer of “property values fall.”

This approach to describing a situation allows you to quickly see where changes can have the most impact. Those boxes with the most outgoing arrows have the greatest direct impact. The diagram also allows us to track (visually) any indirect impacts. The goal is to be able to focus our effort (for fixing social issues) on those factors that have the greatest influence.

Applied to Prioritization

Peter’s article shows a way of creating similar graphs to prioritize a set of features.
The eye-doctor realizes that people can easily make relative comparisons – “is A better than B?” and then uses a successive series of questions to find the proper prescription. The opthamologist is using a search heuristic to narrow in on the right corrective lense. People may not be able to say why A is better than B, but it is generally an easy answer to reach.

Imagine a list of features A through E. A relationship diagram with each arrow showing “Target” is better than “Source”, we end up with a diagram that looks like the following:


For a set of features, A through E, where there are obvious relative prioritizations, this graph is staightforward. For n items being prioritized, the sum of incoming connectors for each item i in the list would be n-i. This is basically a graph of what is known in HCI circles as “card sorting.” In card sorting, features are written on individual cards. First, two features are compared, and placed in order. A third feature is compared to the top card – and if it is higher priority, it is placed on the top of the stack. If it is lower priority, it is compared to the next card in the stack. If the new feature is lower in priority than the last card, it is placed on the bottom of the stack.


The Blender Redux

The problem with this approach is that it homogenizes the inputs, and the features in the middle end up on the top. Imagine one person rated the features A-E, and a second person rated them E-A. If you combined the two sets of prioritization by adding the results, you would end up with feature C at the top, followed by B and D, with A and E tied for last place. The least common denominator wins.

We end up devaluing the passionate opinions of any minority groups who provide us with inputs. We talked about this when considering improved application of market research data. To strike the point home, imagine that we were prioritizing the following features about a new car:

  • A) Extremely Fast
  • B) Comfortable Interior
  • C) Low Cost
  • D) Quiet Ride
  • E) Radically Good Gas Mileage

One person values a sports car, the other is environmentally concious. If we lumped their results together, we would end up with a car that was cheap, comfortable and quiet – but not very fast, and with low fuel efficiency. How many of these cars would we sell?

Imagine how many we would sell if we had a very efficient sports car.

A Better Way

We can avoid the blender-effect first by segmenting our markets, and second by weighting the scores in a prioritization exercise. Here are two approaches to voting on ideas in a brainstorming session. Both of these approaches afford us a way to quantify and capture passion. These approaches would help keep speed and efficiency near the top of the list in our example.

The key difference is that scores aren’t normalized into binary comparisons – passion manifests as a multiplier – making the “dramatically better” ideas influence the score “dramatically more.”


This technique is effective for determining relative prioritization for a single individual, but it falls short when combining data from multiple people.

Outside Reading and Thanks!


For your weekend reading pleasure, an interview and an article.

An interview

The folks at brainmates have a product management consultancy in Sydney, Australia and also publish a great blog. They’ve been running a really good series of interviews with product managers. And today they published an interview with me. Humbling! Thanks again, guys! You should check them out and subscribe. More good interviews are sure to come.

An article

Pragmatic Marketing publishes a print magazine,, with a large subscriber base (~50,000 readers, I think). They also post the magazine online, and the most recent issue just came out. You should subscribe to the magazine – it is free, and very very good.

Thanks very much to the folks at Pragmatic, I have an article in the latest issue. How to Use Timeboxes for Scheduling Software Delivery is an expansion on an earlier article we shared here. Check out the new improved version in their magazine.

Thanks to Tyner Blain Readers!

None of this would be possible without the support, word-of-mouth marketing, and encouragement that we get from all of you. Please accept my deepest thanks for everything!