Interviewee: Karl Wiegers is former developer, manager, experienced analyst, consultant, trainer and author of many courses and such great books as “Software Requirements” and “More About Software Requirements”. He has kindly agreed to give an interview to the representative of Belarusian business and systems analyst community and just to the man who treats Karl as the “big father” of systems and business analysis. Karl’s home page — http://www.processimpact.com/.
Interviewer: Yuri Vedenin is a former developer, project manager, business and systems analyst, co-founder of Belarusian business and systems analyst community (http://analyst.by) .
Yuri Vedenin: Hello, Karl! Good morning to you (:
Karl Wiegers: Hi Yuri — Do you want to get started?
Yuri Vedenin: Yes, I’m ready, so let’s start. Could you tell me about yourself in a two-three sentence manner? Like who are you, how old are you, where do you live, a few words about your family and your current job.
Karl Wiegers: I am 56 years old. I live in Portland, Oregon, USA. I have a PhD in organic chemistry but I have worked for more than 25 years as a software developer, manager, and process improvement consultant, trainer, and author.
Yuri Vedenin: Interestingly because both my parents are also chemists and they’ve also switched into another work spheres (father into IT, mother into accountancy) about 10-15 years ago.
Karl Wiegers: Good for them! I find chemistry fascinating and I always regretted that Kodak, where I started my professional career, never let me really use my chemistry background properly. So I fooled them, I switched into IT.
Yuri Vedenin: Talking about your education I would like to ask where have you studied (I mean higher education) and what is your attitude towards the school you’ve studied in? Has it given you what you expected? Was it interesting to study there?
Karl Wiegers: I received my BS in chemistry from Boise State College in 1973, a small and not very good college in Boise, Idaho, where I also went to junior high and high school. (My father was in the U.S. Air Force so we moved around a lot and I lived in many places before we moved to Boise.) I was quite young when I was in college so it made sense to stay at home. I was 19 when I got my BS. Then I got a MS and PhD in organic chemistry from the University of Illinois, which is an excellent university, rated one of the best in the country for chemistry. I started programming in Fortran when I was in college and I programmed and used computers a lot in graduate school also (1/3 of my PhD thesis was software code). So was not a radical leap for me to change into IT.
Yuri Vedenin: You’ve probably already answered my next question, but I would like to ask it evidently to get the right answer: How did you get in IT? How you decided to do it? What was the first company you worked at and what was the first position you’ve taken?
Karl Wiegers: I started working at Kodak in Rochester, New York, as a photographic research scientist in 1979. But I got frustrated because I was not able to use my education and I was not that excited about photographic science. So I started getting into the use of the computer in the research labs at Kodak.
Back then it was an IBM mainframe. I did a lot of programming for myself, and then for other scientists, and then we formed a group to provide software development services for the photographic research labs. Later I managed that group. Then I moved into process improvement leadership in Kodak’s digital imaging areas and finally in the kodak.com group. I started my own company, Process Impact, in 1997 and left Kodak shortly thereafter.
Most of my work at Process Impact has been in the area of software requirements and project management. I have written books on those topics and also software inspections and peer reviews. However, the requirements domain and business analysis has by far been the area that most of my clients have contacted me about.
I have always been the only employee at Process Impact. Everything that is done at Process Impact I personally do myself. I even empty the waste baskets :-)
Yuri Vedenin: So why don’t you want to grow as a company? I mean hiring more people, getting more clients, etc.
Karl Wiegers: At this point I do not wish to grow because I am largely retired from the software industry. I am no longer doing any writing or speaking at conferences and I do only very few training or consulting engagements that seems particularly interesting or convenient. I have been fortunate to have all of the work I ever wanted to do so I didn’t need to have more clients. I have worked with more than 100 companies and government agencies at all levels over the past 15 years. So I have seen a wide cross-section of the software industry. And I have found that the techniques I described in my books and courses are generally applicable to just about any organization.
Yuri Vedenin: That’s really true. Even nowadays, even in our country (:. By the way, Karl, you have an interesting talent to answer the questions that I’m just willing to ask. Using this ability you’ve already answered my not-yet-asked question: “What are you working on now? What are you primary activities now?” So I will ask another one then: What do you do now? How do you usually spend your time now?
Karl Wiegers: Being retired I do quite a bit of volunteer work, I read a lot, I watch movies, I play my guitars and write and record some music (see www.processimpact.com/songs), and enjoy wine tasting. :-)
Yuri Vedenin: Talking about the job I can’t bypass the following question: What was the most routine job for you and what steps did you take to make it more interesting to you?
Karl Wiegers: The most routine job has been to teach my most popular course, «In Search of Excellent Requirements». I have taught this course almost 180 times, mostly as two days in duration. After teaching that course so much it isn’t very interesting to me anymore, although I think it is still a very good and relevant course.
It’s not important if the course is interesting to me; it’s important that the course is interesting and useful to my students. So I always try to remember that even if I have taught it many times, they have never heard it before so I do the best job I possibly can every time. I have tried to keep the training business more interesting by creating other courses, such as «Writing High-Quality Requirements», but the biggest demand has always been for the In Search course.
So one way I have kept it interesting is to license my courses to other people so they can teach them instead of me. :-)
Yuri Vedenin: Can you refer at least some of those people / organizations?
Karl Wiegers: I can refer an interested client to some of my licensees who might be available to teach classes for them at their location. Some of the licensees occasionally present public courses that anyone can attend, also. Most of the licensees are in the US and Canada but one is in Japan. Here are the companies that present the public sessions of my courses:
1) PMO To Go
http://www.pmotogo.com/expertise/training/business-analysis-training/
2) MAX Technical Training
http://www.maxtrain.com/classes/classSearch.aspx?GroupID=167&M=Professional+Skills&C=Requirements
3) Cyx (Japan)
Yuri Vedenin: Thank you. My next question will be about your writings. When and why have you understood that you need to write the book «Software Requirements»? And if it is you first book then how long have you been writing it?
Karl Wiegers: My first book was called «Creating a Software Engineering Culture», published in 1996. I decided to write the first edition of my «Software Requirements» book because there were very few books published on this important topic at that time. Steve McConnell (author of many important software books like Code Complete and Rapid Development) is a good friend of mine and he suggested maybe I should write a book on requirements. I had been thinking about it anyway so I went ahead and did it. I tried to cover the whole process of requirements development and requirements management, which really had not been addressed before. That book came out in 1999.
Yuri Vedenin: Here I would like to thank you personally for this book, because it’s changed my professional life (:. And I also would like to ask you to extend my thanks to Steve McConnell next time you will be talking to him for the advice that he has given to you (:
Karl Wiegers: Thank you, Yuri. I’m glad you found the book helpful. It always means a lot to me when I hear comments like this from readers. I tried to write a very practical book and it’s good to hear people say that I succeeded.
I will tell Steve :-).
Yuri Vedenin: Talking about your writings I would also touch your not so big but helpful article ‘Ten Requirements Traps to Avoid’. I really enjoyed it very much. It is very concise and substantive. Could you think of ‘Ten Requirements that are must to do’? I understand that it might take more than 1 hour (and probably this is just a new idea for you to write something like this), but can you state at least 3 or 4 now?
Karl Wiegers: I don’t have a specific article like that but really that’s what all of my other writings are addressing, important things to do regarding requirements on projects. Some of the critical things are:
1) Define the project vision and scope so everyone knows what the team is trying to accomplish and how to tell when they’re done.
2) Get good customer engagement so you really understand their needs.
3) Prioritize the requirements to make sure the team is always working on those requirements that will deliver the maximum value to the customer soon as possible.
4) Recognize that requirements development is an iterative and incremental process and you will not be able to get all of the requirements done up front matter how hard you try.
5) Change is a reality whether you like it or not so establish mechanisms so you can anticipate and accommodate change and the impact it will have on your projects.
6) Be sure to address nonfunctional requirements, such as quality characteristics of the product, in addition to the functionality that people ordinarily focus on.
These are a few of the most important things every project should address regarding requirements.
Yuri Vedenin: You’ve given 6 of them. It’s even more than I’ve expected. Thank you!
I’ve started working as an analyst not so long ago, approximately 5 years from now, and I’ve noticed that this profession is still very young. So my next question is a little bit funny, but it is still a serious one:
Not only I, but many treat Business Analysis as a very young profession. What do you think, if Business Analysis would be a human, how old would she/he be?
Karl Wiegers: She would be 15, but with the maturity of a 6-year-old. :-)
Yuri Vedenin: Oooh, that means automatically that being not even an adult BA can’t drink wine or beer not in US, not in EU, not in our country (:
Karl Wiegers: Okay, 21 with the maturity of a 14-year-old. That is, people have been performing the role of business analysts on projects forever, even if not explicitly. After all, the first time someone wrote a program for someone else they had to figure out what that other person needed. So as a «person» she would be quite old, but it has only been recently that business analysis has been recognized as a professional discipline that involves a body of knowledge, the need for training, certain personality types, certain expertise and experience, and so forth. So this is why I would say the business analyst isn’t very mature even if she’s old.
Yuri Vedenin: I enjoy your answer (:. By the way, you’ve mentioned body of knowledge. I’m pretty sure you’ve heard that a few years ago BABOK (Business Analysts Body of Knowledge) along with «A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)« was introduced by the IIBA. I’m just wondering if you have participated in creation of BABOK? (I truly hope for it.. fingers crossed) Because if not, then I will personally contact IIBA and tell them how much they’ve missed already and are still missing.
Karl Wiegers: I did not participate in creation of the BABOK, although I understand that my books were used as resources. I was invited to participate but I did not feel I could spend all that time. Frankly, I have not read the entire BABOK. I’m sure there’s a lot of good stuff in there and I’m glad to see IIBA established as a professional organization for business analysts.
Yuri Vedenin: And what is your attitude towards certifications for BA?
Karl Wiegers: I am concerned when I see people who wish to obtain the BA professional certification from IIBA concentrate so much on simply passing the certification test, rather than really mastering the right set of knowledge for them to do a good job. Ideally these would be the same thing. However, I recently met a woman who said that some of the questions on the BA certification exam contained errors based on errors in the BABOK and you have to give the wrong answer to make sure you get the question graded as being correct! This is not what a professional organization should be about. But I do have a lot of respect for professionals who go back to school or train themselves to increase their capabilities and get professional certifications.
As I indicated, any professional certification is good if it motivates people to learn more about how to do a good job in their chosen field. But if they become hoops to jump through, I have a problem with that. As an analogy, I knew several people who got PhD’s in chemistry back when I was in graduate school who were clearly incompetent chemists; some of them were even what I would call idiots. Simply having the certification doesn’t mean you are qualified to do a job or have good judgment about how to do it well. It does mean that you took the trouble to try to better yourself and for most people this will be valuable.
I do have some problems with the way some of the certification bodies take themselves too seriously. For example, if my courses are to be listed as «approved» or whatever the right term is by IIBA or PMI, I need to spend quite a lot of money and go through a certification process, even though I feel like I made some significant contributions to developing that part of the industry. It’s kind of a racket, IMHO.
Yuri Vedenin: Wow. It is very detailed answer. Again, thank you for it. I agree with your thoughts and I think many BAs will be interested in your opinion, because I believe I’m not the only one who’s professional life was changed by your book. And what about you? Could you remember the man, the thing, the deed or several ones that dramatically changed your life?
Karl Wiegers: I don’t know about specific things that dramatically changed my life, but I have certainly had important influences. A professor who was the director of the honors program at Boise State College had a lot of influence on me. My PhD thesis advisor, Dr. Stanley Smith, taught me many things that go well beyond chemistry, ways of thinking that have strongly influenced me for the rest of my life. Deciding to start my own company obviously was a dramatic change, leaving the comfort and security of a big corporation, but it worked out very well and certainly glad I did it.
My feeling is that as you go through life you have many small experiences which, if you’re paying attention, contain powerful lessons that can be valuable to you forever. If you’re paying attention.
Yuri Vedenin: I had to agree with your 2 last statements. As I know, you need to quit very soon for your volunteering and I still having too many questions to ask now need to choose only 1 or 2 of them. Let the first of them be the following: Could you state the 5 most important skills of BA? Actually you can name as many as you think are important, so it can be 1, 2, 3 or more.
Karl Wiegers: I’ve written articles about the skills needed to be a good BA so I don’t think I can say necessarily which the top five are, but I will give it a try.
1) The job of business analysis is, more than anything else, a communication job. So an effective BA must be able to communicate with all the various stakeholders who are part of a project. They need to be able to communicate with user representatives to understand their needs in their terminology. They need to be able to translate that information into specific software requirements that technical people can understand. And so forth.
2) It’s also important for BAs to remember that they are not just a scribe, writing down whatever the customer says. They need to actually analyze. So one important skill is for the analyst to be able to think effectively at both high and low levels of abstraction. Some people are good at the big picture strategic view, others are good at the little details, but the BA needs to be able to flexibly move from high abstraction to low abstraction.
For example, the BA needs to be able to start with an example of a user story and generalize that into a use case that covers a set of related stories. Also, the BA needs to be able to drill down from a high-level concept to the appropriate level of detailed requirements at the right time in the project. I think this is actually one of the most important skills, judging where to be along the abstraction scale for a particular discussion or when writing requirements.
3) Another critical skill is to be able to represent requirements knowledge in a variety of ways. When I think of «writing requirements» really I think of «representing requirements knowledge», which means writing some information in the form of traditional natural language statements, but also using a toolkit of models and other techniques to communicate information to other stakeholders. However, every requirement specification I have ever read contains almost exclusively natural language text, which is unfortunate. I’m a big believer in thoughtful modeling and choosing tables, formulas, lists, photographs, or other techniques for communicating information when that is effective.
Yuri Vedenin: Thanks again, Karl. And my final question will be: what advice (or several) could you give to the one who would like to become the analyst nowadays?
Karl Wiegers: I would start by reading three things from my website. First I would read the articles titled “So You Want to Be a Requirements Analyst?” and “Habits of Effective Analysts” to get some ideas about what the analyst’s job is like and how to do it effectively. Then I would read the “Requirements Analyst Job Description” and evaluate my own skills and knowledge against this description to select some areas where I want to personally improve my own capabilities.
Yuri Vedenin: Karl, I have at least a dozen of questions to ask, but I can’t keep you at interview anymore. So THANK YOU for such a wonderful interview! It was really a pleasure talking to you.
Karl Wiegers: You can go ahead and send me e-mail and I will answer the other questions that you have. I’m glad this worked out well. Thank you for your help in setting up Google Talk and for inviting me to participate in this interview. Talk to you soon. Bye.
Yuri Vedenin: Talk to you later. Bye!
Additional questions asked later via e-mail:
Yuri Vedenin: Now there is growing tendency in some companies for creating specialized departments / units / offices like PMO (project management office). How do you like the idea for creating RMO (Requirements management office)? What are the pros and contras from your point of view?
Karl Wiegers: It depends on how an RMO would operate. Certainly, developing a group of educated, skilled, and experienced requirements analysts will help any organization that wants to build the right software efficiently. Too often, team members are asked to perform this difficult task without proper preparation, so it’s no wonder that they don’t always do a good job despite their best efforts. However, I think it is an advantage for a BA to have knowledge of the application domain. Simply expecting any random analyst to do a great job when thrown into any random project isn’t necessarily realistic.
There’s also an organizational question. In some organizations the BA is part of the customer community, and in other organizations the BA is part of the IT community. BAs also have a variety of backgrounds. My informal surveys suggest that perhaps 60% of BAs come from the user side and the rest come from a technical background. Either is fine, provided they recognize that they need knowledge in both the business and technical domains, as well as the ability to communicate effectively with people from both domains and to get the respect of both technical and business stakeholders on her project.
Yuri Vedenin: Do you feel any difference between BA (business analyst), SA (systems analyst), BSA (business systems analyst) and RA (requirements analyst), etc.? If yes, could you name it?
Karl Wiegers: I have heard all of these terms used and others, such as requirements engineer, requirements manager, and planner. I think these are all synonyms for the same job in most cases. In some cases I have seen companies that had two people involved in this function, perhaps one called a business analyst from the customer community and one called a systems analyst in the technical community. In other cases the systems analyst is really a technical position, like an architect or designer. Unfortunately, there is not good consistency of these job descriptions. (This is why I always avoid answering questions about who should perform a particular function on a project.) The most important thing is to make sure that the responsibilities of each person on a project who has one of these titles are clearly understood and agreed to. This helps avoid two problems: (1) one person does a job that someone else thinks they’re supposed to do, which can cause hard feelings and (2) no one does an important project job because they don’t realize it’s their responsibility.
Yuri Vedenin:Which modeling notation do you use and recommend for requirements engineering? Is it only UML or anything else that suits specific processes and purposes? Which tools would you choose for each of the mentioned notation?
Karl Wiegers: As you know, I am a big fan of modeling during requirements development. When I survey my seminar audiences, I find that many of them are familiar with some of the standard modeling notations, but they actually use very few of these techniques. I find this puzzling and disappointing. I have seen very little use of UML by BAs. Many of the classical structured analysis techniques are still perfectly useful, such as the context diagram, data flow diagram, and entity-relationship diagram. The UML does not contain counterparts for all of these. (For example, a use case diagram is not really analogous to a context diagram, although there are some visual similarities.) I always find state-transition diagrams helpful, and the UML statechart (or state machine) diagram is somewhat more powerful.
It is important for the analyst to become familiar with all of these techniques and to be able to use the most effective method in each situation. In other words, don’t discard structured analysis models just because they’re old and don’t discard UML models just because they’re complicated. In general, I think customer representatives will find the structured analysis models simpler to understand. I can’t comment on specific tools because I don’t try to stay current on what is available today.
The worst situation is for people to invent their own notations. The whole point of modeling requirements is to communicate effectively. If you are making up your own notation and nobody else knows how to read it, this does not facilitate effective communication. There’s no reason to make up your own notation unless you have determined that none of the standard modeling notations that have been available for a long time will work for you in a given situation.
Yuri Vedenin: What you do to keep your mind in shape do you have your own tricks or exercises or your analytical job is the best exercise for that?
Karl Wiegers: I like to play games and do puzzles to try to keep my mind sharp. For example, I recently learned about a website called www.lumosity.com, which has many «brain games» that help you improve concentration, response time, field of vision, attention, problem solving, etc. I enjoy these games and it’s nice to get higher scores with practice. As I get older this will become even more important!
Nice food for brains. Thanks guys for a consistent and informative interview.