Articles for 'Karl Wiegers'

Jun 12, 2022
10485 Views
9 Likes
0 Comments

There are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.

May 08, 2022
11399 Views
9 Likes
3 Comments

A software feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. Many business analysts use features as a way to describe the scope of a project. However, a simple list doesn’t readily show the size and complexity of various features. Nor does quickly skimming a feature list easily reveal the full scope of a project. A feature tree is a visual analysis model that organizes a set of features in a format that makes them easy to understand.

Feb 13, 2022
9602 Views
5 Likes
0 Comments

Knowledge isn’t like other commodities. If I have three dollars and give you one of them, now I have only two dollars. Money is zero-sum in the sense that I must lose some of it for you to gain something in this transaction. In contrast, if I give you some of my knowledge, I still possess all the knowledge myself. I can share it with other people, as can you. Everyone touched by this expanding circle of knowledge benefits.  Everyone has something to teach—and to learn. You don’t need to be the world’s expert on some topic to be helpful. You just need some useful block of knowledge and the willingness to share it. In the world of technology, if you’re one week ahead of the next person in some area, you’re a wizard. Someone else will doubtless be ahead of you in other areas, so take advantage of their trailblazing. People in a healthy learning culture share what they know and also acknowledge that someone else might know a better way.

Oct 03, 2021
9824 Views
2 Likes
0 Comments

There’s always more than one design solution for a software problem and seldom a single best solution. The first design approach you conceive won’t be the best option. As one experienced designer explained it:

You haven’t done your design job if you haven’t thought of at least three solutions, discarded all of them because they weren’t good enough, and then combined the best parts of all of them into a superior fourth solution. Sometimes, after considering three options, you realize that you don’t really understand the problem.

12420 Views
6 Likes
0 Comments

     Designing a new product is a messy process. It involves initial brainstorming, rough concepts, false starts, and extensive refinement. Good designs begin with an identified need or opportunity, and they’re based on a solid understanding of the product’s requirements. No matter how skilled the requirements analyst is or how informed and cooperative the customer participants are, the first set of requirements they develop will be only approximately correct. It takes a process of iterative refinement and validation to accurately understand the requirements for any nontrivial product.

11184 Views
12 Likes
1 Comments

 Not every manager is convinced that his team needs to do a better job on requirements development and management or that such an investment will pay off. Numerous industry studies, however, indicate that requirements issues are a pervasive cause of project distress. Let’s see why investing in better requirements is a smart business decision for any organization.

11800 Views
3 Likes
0 Comments

Software applications, cars, kiosks, and many other products must communicate important information to users. These feedback messages most commonly contain information about errors; warnings or alerts; and task progress, completion, or confirmation . Feedback from a product is most effective when it exhibits these seven characteristics...

11945 Views
29 Likes
2 Comments

I spent a lot of time in the past half-century doing software work: requirements, design, user experience, programming, testing, project management, writing documentation, process improvement leadership, writing 7 books and many articles, consulting, and training. Sure, there were some side trips along the way,.... But basically I’m a software guy. Over all that time, I’ve accumulated numerous insights about the software business. Here I offer 66 of those lessons. Perhaps you’ll find them as helpful as I have.

7229 Views
20 Likes
0 Comments
Everyone’s crazy busy when you’re launching a new project, and taking the time to study existing bodies of knowledge doesn’t seem like real work. However, “doing nothing” while you examine the lessons of the past is a high-yield investment in your own future. An overconfident project manager, in contrast, will rely solely on personal experience, memories, and the team members’ intelligence and experience to weather any crisis and master any challenge. Hubris, arrogance, and cockiness aren’t solid foundations for project success.
16147 Views
50 Likes
0 Comments

Visual analysis models provide a powerful set of tools that let business analysts depict system information at various levels of abstraction. These models serve as an aid to understanding, as well as an aid to communicating. Alas, I fear that modeling is somewhat of a neglected practice. I believe modeling is an essential skill every BA should master. Here’s why.

10486 Views
24 Likes
0 Comments

Perhaps you’ve seen a sign at an auto repair shop that asked, “What do you want: good, fast, or cheap? Pick two.” While humorous, the sign is also wise: it acknowledges the reality of trade-offs. You generally cannot optimize every desired outcome of a given situation.  The notion of such a “triple constraint” or “iron triangle” appears throughout project management. The problem is that I have seen numerous representations of the triangle with various parameters on the triangle’s vertices—size, cost, time, or scope—and various assumptions made about what is being held constant, such as quality or functionality. I’ve also seen diagrams that show four project dimensions. So, in my view, the traditional “triple constraint” is wrong, although the concept of constraints and trade-offs is certainly valid.

10595 Views
14 Likes
0 Comments

It’s more important than ever for software organizations to build a healthy engineering culture. Healthy cultures rally developers around common goals: shipping high-quality work, continuously improving, and having fun in the process. Your culture is key to recruiting and retaining the talent you need to ship exceptional customer experiences.

12914 Views
36 Likes
0 Comments

Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry we don’t do a great job of estimation. In this article I offer six safety tips to keep in mind as you prepare estimates for your project and for your individual work... These six safety tips might not help you create estimates that all of your customers, managers, and coworkers will dance to, but at least they will help you and your team hear the same music.

19039 Views
40 Likes
3 Comments

The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains that domain knowledge is not critical. A skilled BA, the thinking goes, can walk into nearly any project situation and do an effective job of exploring requirements, relying on previous experience and a rich tool kit of requirements techniques. The counterargument avers that an analyst who has deep subject matter knowledge can be far more effective than a more general practitioner.

I have experienced both situations, from inside a company as a regular employee and from the outside as a consultant. This article offers some thoughts about when domain knowledge is valuable, when it’s essential, when it’s not necessary, and when it can actually pose a risk.

12333 Views
28 Likes
0 Comments

Successful projects—and successful relationships—are based on realistic commitments, not on fantasies and empty promises. This article, adapted from the book Practical Project Initiation, presents several ways to improve your ability to make, and keep, achievable commitments... Unfulfilled promises ultimately lead to unhappy people and unsuccessful projects. Strive to build a realistic commitment ethic in your team—and in yourself.

Page 1 of 5First   Previous   [1]  2  3  4  5  Next   Last   

 



 




Copyright 2006-2022 by Modern Analyst Media LLC