Category Archives: Uncategorized

Data Privacy Policies

See our Privacy Policy page for details about the data we may collect from visitors and other users of this site. We do not necessarily collect all that data, but it is possible.

At this point in time, this site is not active and exists as an archive of information. So we actually collect less data now than we did in the past.

This is a WordPress site and WordPress uses cookies. We are not using any kind of Analytics, so we are not storing IP addresses or tracking visitors. At present no new accounts or comments can be created. If you use a form on the User Data Request page, then we will receive and use your email address as indicated on that page and only for the purpose indicated. Otherwise, you can browse anonymously – we will not even know you have been here!

If you created an account on this site in the past, your account information is still in our database. You can log in and change that information yourself, or ask us to do it through the User Data Request page. If you created posts, they are still in the database. You can edit them or remove them.

If you left comments on this site in the past, those comments were stored in our database with your name, email address, and IP address. If you want changes made to any of that data, use the User Data Request form to let us know what needs to be done.

Taking a Hiatus

I have been pursuing various projects lately and have not really been writing much about Business Analysis. My focus today is more in effectively implementing Agile.

There is a lot of great information here, so do feel free to browse around.  I recently went through the whole blog, cleaned some stuff up, and discovered some very cool posts (check out the category of Online Game).

I am currently focused on my Agile Transformation blog at Agile is Dead (or is it?) and am also working on publishing a series of Agile books for Executives. See Geri Schneider Winters site for information on my books and how to contact me.

A modern fable: Where the Product Owner role came from

This story is a fictional account of how the Product Owner / Customer role may have come about. It’s purpose is to illustrate why so many companies have so many problems with this role.  After the fable, the article continues with some examples showing what some companies are doing differently.

Once upon a time there was a team implementing software. They had just been staffed to a new large project which would be released as a series of releases. They met with the Business Analyst to learn the requirements of the first release. They developed a solution, then showed it to the Project Sponsor. The Project Sponsor was not happy. “This is not what I want”, he said. “You will have to redo these 3 parts completely.” And so the team reworked those parts, showed them to the Project Sponsor, and life was good.

The team started the next release, and the same thing happened. The Project Sponsor liked some of what they did, but other parts they had to completely rework.

One day when the Project Sponsor was not happy, the team said in frustration, “If you are not happy with this then come and sit with us and show us just what you want us to do”. The Project Sponsor agreed and sat with the team for a couple of days until the problems were fixed. Everyone was happy.

The team said, “This worked so well, come and sit with us all the time and tell us what to do.” The Project Sponsor said, “I cannot possibly do that, I have another job”. So the team said, “Then send us someone you trust completely to tell us what to do and agree that if our work is acceptable to that person then you will also accept the work.” The Project Sponsor agreed to do that for the next release.

The Project Sponsor sent one of the best of his staff to sit with the team full time for the whole release cycle. This was just as good as having the Project Sponsor sit with the team. When the Project Sponsor saw the finished work, he was happy.

The team said, “This is the way we should always work. There should never be someone between us and the Project Sponsor, though having one of his best people worked out.” And the Project Sponsor thought, “This is not sustainable. I cannot give up my best people forever”, but he said nothing because everything was in fact working for this project and he would worry about how to address the issue later on a different project.

That team was led by someone influential in the software development community, someone who did a lot of writing and speaking at conferences, and so the word spread. Teams with the same frustrations embraced this model and insisted on it with their Project Sponsors. A short term fix born out of frustration and immediate need, that was not grounded in root cause analysis, became a recommended solution for everyone.

Unfortunately, this story did not have a happy ending. When that project was finished and the product released to end users, they rejected it. It did not meet their needs. One thing the Business Analyst had done was work with the end users, so by removing that person from the team, there was no one looking out for the end users. The Project Sponsor and his staff were not in touch with actual end users and their needs. Ultimately this project was a failure that wasted millions of the company money.

This model of the customer sitting full time with the team, that was an impulsive solution to the problem of the team having to do rework due to the Project Sponsor being unhappy with the results, introduced two intractable problems:

  1. It is not sustainable for the business to remove Project Sponsors or members of their staff from their day-to-day work to sit full time with an implementation team to tell them what to do.
  2. It removes the voice of the end users from the project (UX as it exists today is too much about design and not enough about the actual human beings using the product. It is insufficient.)


What is needed is a determination of the root cause of the initial problem and fix that.  Since this is a fable, we can only guess at the root causes. These are some things I have seen in my career that have caused exactly the problems described above:

  • The Project Sponsor changed their mind at some point and did not communicate the new requirements to the Business Analyst.
  • The Business Analyst spent too much time with the end users and did not cross check the information with the Project Sponsor.
  • The Business Analyst was not trained or know how to do the role.
  • The development team ignored what they were told by the Business Analyst.
  • The development team did not review documentation provided by the Business Analyst.

I am seeing a number of different approaches to resolving these issues.

Microsoft recently published some articles about the 5 year Agile journey they have been conducting in their developer division. They have found they need 2 Program Managers for each team of about 10 implementers. (A Program Manager combines the responsibilities of Product Manager, Business Analyst, and Product Owner.) This allows each one to spend half their time on the work they need to do on the business side and half their time with the Agile team.

Menlo Innovations does custom programming. Their customers are other companies.  The customer is not on-site, the users are not on-site. Menlo has High-Tech Anthropology teams who coordinate the work between the customer, end users, and their own XP teams. Each XP team has a pair of Solution Anthropologists working with them.

A lot of projects still have a traditional Business Analyst role. But they understand that they have to train and mentor their Business Analysts. They do not just put any warm body in the role if they want that person to be effective. They typically train their Business Analysts in a broad range of skills, including things such as mediation, negotiation, and effective communication.

I just talked with a Business Analyst today who recently got a top award from her company for effectively negotiating the requirements and release schedule between the business unit that was the customer, the actual end users, and the Agile IT team implementing the solution. This was a very tricky situation, and she was personally credited for making it work to everyone’s advantage.  She is highly trained in not only Business Analysis but also in Sociology and Leadership.

In all three of these examples, the team is not getting input from one person (the customer, the Product Owner). Rather the team is getting input from the customer and many, many users filtered through one or two people who directly interact with the team.

At Microsoft, the Program Managers are responsible for being closely in touch with the market and the end users, and they bring that knowledge with them when they sit with the team. The same is true of the Solution Anthropology teams at Menlo and the well-trained experienced Business Analysts I meet.

We do not have to remove a business SME or Project Sponsor from their full-time jobs to make Agile work. We need to provide trained, experienced people who know how to negotiate the best results for the customer, the users, and the teams who implement the solutions.

Is Anyone Doing Solution Anthropology?

I was chatting with a good friend recently who said “Solution Anthropology sounds really cool, but is anyone actually doing it?” I can say with certainty that yes they are and I see the demand growing.

In recent weeks I have spent quite a bit of time with a number of different companies in the US and Europe talking about their product (especially software) development processes. As part of these discussions the topic of Solution Anthropology came up. These companies are already trying to do some work in that domain and are looking for more information. These companies are in a variety of sectors. The ones I have been talking with recently are in manufacturing, insurance, banking, and product development.

One of the companies trained about 35 people in Solution Anthropology a couple of months ago and they have a large waiting list of people who did not get into that training. They wanted to know if I could provide training for more of their people. Of course I said yes! (At this time I am one of the two companies I know of that offer training in Solution Anthropology. Our courses are consistent with each other so this client will be working with both of us to get everyone trained.) Much of the work will be using Solution Anthropology to examine their own company to see how they can provide a better work experience for their employees. This is especially important in areas where they are seeing high turnover.

An award winning mobile app design team at another company has asked me about Solution Anthropology training and follow up coaching because they think they can be even better. Their company is happy to do this because the quality of their apps has let them get a lot of customers from competitors in their market. Creating apps that delight the users is really important in markets where the products are very similar and there are a lot of choices for the consumer.

Another company is considering training 20 people in Europe because they see Solution Anthropology as a way to get better-described work packages for the implementation teams that are scattered around the world. The only thing delaying it is they want to hire locally, but the only companies offering training in Solution Anthropology at this time are in the US.

I also have been contacted by a couple of startups who are trying to apply Lean Startup principles. They see Solution Anthropology as the set of skills they can use to closely interact with their customers and quickly grow their business.

These are just a few recent examples. I have not yet found a company that told me Solution Anthropology was of no use to them. Most companies have people with a lot of the skill sets they need, but it had not occurred to anyone to blend those practices to focus on the user in their native environment.

I discovered on my trip that a lot of people have been downloading my pdf “Solution Anthropology Explained” and passing it around inside their companies. And I got some great feedback on it, so I know they actually read it!

If you have not read it yet, you can get it here SolutionAnthropologyExplained.pdf


Tips for Job Searches

Many people come to this blog because they are changing careers. I recently put together a workbook that steps you through using the Strengths Finder quiz to find keywords to use in your resume, LinkedIn profile, and cover letters. These keywords are your strengths, as well as being the search terms that recruiters use to find people for jobs.

Right click on the link to download the PDF.

Using Strengths Finder to Get the Job You Love

I hope you find this useful.


Managing Up

I was pleased when Geri asked me to write a guest post about managing up. I think it is an important skill that everyone should cultivate, regardless of job level or industry. The following post skims the surface–I look forward to any questions or comments you may have so we can expand the conversation.  -Jen

One of the most important skills any professional can have is that of “managing up,” or Managing Your Manager. While the idea of managing the person who is supposed to manage you may sound contrary, you can also think of it as a beneficial outcome to communication, demonstrated professional integrity, and good consulting skills.

Managing up also is a form of visibility, or presence. As workplaces and teams span locations and more of us work remotely, it is important to remain visible in a positive way. Being top of mind (and showing how responsible, consistent, and good your communication skills are) is a great way to get considered for successively more interesting or challenging projects. Plus, you’re helping to ensure that your manager isn’t caught off-guard when it comes to you or your projects, and that often translates to more latitude (or less micro-managing).

What is it, really?

Managing up will sound like your boss is going to get more out of it than you will. In the short term, that’s probably true. A big part of managing up is to help your manager look good by keeping him apprised of what’s going on with you, your projects, and the team. The benefit to you is that people appreciate it when their staff–or teammates–help them look good. You get the benefit of people wanting you on their teams and the good professional reputation you’ll build in the process.

  • It is a tangible demonstration of your professional integrity. In his book “Selling the Invisible: A Field Guide to Modern Marketing”, author Harry Beckwith states, “Invest in and religiously preach integrity. It is the heart of your brand. The heart of a service brand – the element without which the brand cannot live – is the integrity of the company and its employees. The value of any brand rises or falls with each demonstration of the company’s integrity.” (p. 155). In this case, rather than thinking of the “company” brand, think of it as your personal brand–the value of your brand rises or falls with each demonstration of your integrity. Giving your boss a heads-up when something didn’t go well, reporting what you have been and will be working on (without it being required), and telling the truth are all demonstrations of personal integrity.
  • Your manager should always be able to answer the question, “What is Judy/the team/the department working on?”. By proactively providing this information, you are helping your manager to look good to his/her peers or boss – and that’s always a good thing.
  • Your manager should never be caught off guard by hearing project news from someone else. Especially if it’s bad news! If something transpires that may result in a call to your boss, make sure he or she hears about it first from you, and not when they are cornered in the company cafeteria or restroom. It may be very uncomfortable to deliver bad news to your boss, but it’s guaranteed to be even less comfortable if they hear about it from someone else–and look uninformed or not in control of their staff/team in the process. By hearing about it before having to have a conversation, they can be better informed and prepared for any conversations that may arise–or have the opportunity to be proactive and nip a potential issue in the bud.
  • Managing up isn’t just for the little guys. This is one skill you’ll always need – everybody has a boss, even if it’s the Board of Directors.

How do I do it?

You might be wondering how this managing-up thing works and how it’s accomplished. Here are a few suggestions based on my own time-tested practices:

  • Provide a weekly status report, even if one isn’t required. Especially, in fact, if one isn’t required. It can be a simple email or one-page document that lists:

– What you accomplished that week

– Any issues or roadblocks

– What you’re working on in the coming week

  • Provide an as-needed update, especially if something significant happens relative to a project. If good or bad news comes up for a project, let them know right away–no need to wait for your weekly status report.
  • Keep it short. The point isn’t to over-burden your managers with minutia. If they want more information, they’ll ask for it.
  • Keep your tone professional. Managing up isn’t about competing with others, it’s about being professional and helping your boss to look good.

Here are a few examples from my own experience and that of friends:

  • “Hey, Jane–I just had a meeting with the stakeholders from Underwriting. They were not happy with the process we’re suggesting for (whatever).” (As business analysts, this will happen, probably more than we’d like it to.)
  • “Hey, Jane–I just met with Customer Service – they were really pleased with ….” (Stop in and deliver some good news, too – especially if something goes better than expected.)
  • “Hi, Stan, here’s some info you’re going to need. You don’t need to go over it now, but you’ll want to have it on hand.” (This was from a friend who works in a contentious engineering environment. After a meeting, he dropped off crucial numbers at his supervisor’s desk. His supervisor was then prepared to deal with the irate visitor he had thirty minutes later.)
  • “Do you have a minute? I was just in a meeting with Art from Accounting and I really lost my patience with him. I want to let you know before you get a phone call.” (Awkward? You bet. But not as awkward as getting called into your boss’s office after s/he gets a phone call from Art or Art’s manager. For best results, be sure you take responsibility for your actions, and let your manager know what you plan to do to remedy the situation. Or, ask for suggestions on the best way to deal with the individual. No matter what sort of jerk the other person may be, you will always look good by taking responsibility for yourself and behaving professionally, which is to say, not whining or blaming.)

Managing up takes some discipline and some courage. You will find that it improves your personal brand and over time is well worth the effort. This is a long-term career investment; get started today!

Business Analyst Podcast Series

Michiel Erasmus has a nice podcast series for Business Analysts. Michiel got the idea in 2009 to interview experienced BA’s so that he could learn more about the role. He decided to record the interviews and make them available so other people could benefit from the information as well. I quite admire him for his work on this series!

Michiel contacted me to be interviewed for this podcast series, and we met last week. He has posted the first part of the podcast (which is number 27), and it is available for your listening pleasure You can also explore the other interviews in the series.

You can post comments on his blog and if you choose to, you can make a donation to help him pay for creating the series.

I hope you enjoy this great resource from Michiel Erasmus.


Followup on Iterative Planning Class: Resources

During the Q&A for the Free class in May on Planning Iterations, I referred to quite a number of resources.  I had some folks ask me to write up those references. Here they are:

Book: XP Explained, Kent Beck
Certified Scrum Master training –
Book: The Inmates are Running the Asylum, Alan Cooper
IIBA and certifications:

Analysis is a very important skill, analysis on the problem, the requirements, the solution

Requirements Management Tools
Spirateam from Inflectra:
IBM Rational Requisite Pro,
IBM Telelogic Doors,

Free UML Modeling Tool

Requirements Writing and automatic activity diagram generation

Free Documentation Tool

LinkedIn Group: Starting A Business Analyst Career
Laura Brandenburg – good resource as a BA, and helps people with tuning a resume and job hunting. Her blog is

Network in the Local IIBA chapters – meet other BA’s

Business Process Modeling Standard,

Increasing Productivity and Performance

Author: Geri Schneider Winters

I was asked recently how to increase productivity and performance as a BA. Here are some ideas based on my own experience.

  1. Before acting ask yourself the best approach to something.
    • For example, when collecting information we often assume that interviews are the best approach. Before scheduling interviews, think about the information you need. Maybe you can get the information you need more quickly from a document.
    • Another example could be effectiveness. It may be more effective to collect 5 people in a room together where they can discuss an issue, rather than you asking questions of each of the 5, then following up to resolve differences. Acting as a go-between is less effective than letting the people work it out for themselves.
  2. Do only what you have to do at each  point in time and no more.
    • Early in a project, we identify just the architecturally significant requirements so that the project architect can do his or her work.  The rest of the requirements are discovered later.
    • When I write use cases, I start with the basic flow. Sometimes I do not have to write any more, but if I do, I write the alternatives when they are needed.
  3. Keep focused on the goal of the project.
    • You should not be working on things unrelated to the goal of the project. If you are asked to do so, talk about it with your Project Manager.
  4. Keep learning your craft and get better at it.
    • Take classes in areas where you are weak.
    • Look for ways to get additional experience. Many of the skills of the BA can be practiced outside of work. For example, you can practice interviewing by asking a grandmother to tell you stories of her life while you write them. You get to practice asking questions, listening, and writing, and you have stories from grandmother that you can share with the family.

What do you do to be more productive? What things have you found that help you work faster?