Articles for 'Karl Wiegers'

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.

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.

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.

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.

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.

If someone said you could only perform a single quality practice on a software project, what would you choose? I’d pick peer reviews of requirements, which I believe are the highest-leverage quality practice we have available today.  In a peer review, someone other than the author of a work product examines the product for quality problems and improvement opportunities. Reviewing requirements is a powerful technique. Use them to identify ambiguous or unverifiable requirements, find requirements that aren’t sufficiently detailed yet, spot conflicts between requirements, and reveal numerous other problems.

The fact that software projects and tasks are reported to be “90 percent done” for a long time has become something of an industry joke. (A related joke states that the first half of a software project consumes the first 90 percent of the resources, and the second half consumes the other 90 percent of the resources.) This well-intentioned but misleading status tracking makes it difficult to judge when a body of work will truly be completed so you can ship the next product release to your customers. Here are several typical causes of “90 percent done” syndrome and a few possible cures.

Reuse is an eternal grail for those who seek increased software productivity. Reusing requirements can increase productivity, improve quality, and lead to greater consistency between related systems.

Reuse is not free, though. It presents its own risks, both with regard to reusing existing items and to creating items with good reuse potential. It might take more effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project. In this article we describe some approaches an organization could take to maximize the reuse potential of its requirements.

A business analysis consultant might perform three types of roles when working with clients: expert, pair-of-hands, and collaborator. Each of these represents a different kind of interaction and a different source of satisfaction for the consultant. This article, adapted from my book Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, describes these three modes of consulting engagements, which apply both to independent consultants and to internal consultants who work in large organizations.

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

In recent years, agile software development has been the classic example of this pursuit of magic solutions, so I’ll use that as an example here. Over the years, though, people have leapt onto the bandwagons of numerous new software approaches. They all have merits, they all have limitations, and they all need to be applied to appropriate problems.

A replacement project replaces an existing software system with a new custom-built system, a commercial off-the-shelf (COTS) system, or a hybrid of those. There are some challenges that most replacement projects share, including stuffing in unnecessary functionality, degrading the organization’s operational performance, users refusing to adopt the new system, and having such a large project that it never deploys. Focusing requirements practices on addressing these issues directly can increase the likelihood of a system replacement that delivers the desired value and is accepted by the users.

In his classic book Flawless Consulting, Peter Block described three types of roles that consultants might take on: expert, pair-of-hands, and collaborator. Each of these represents a different kind of interaction when working with clients and a different source of satisfaction for the consultant. Business analysts can engage with clients in the same three modes. This article describes some of my experiences with these three modes of consulting engagements.

 In this article we look at some quality attributes that are particularly vital to explore when specifying requirements for embedded systems projects. Quality attributes for embedded systems can be much more complex and intertwined than those for other applications. Business software is generally used in an office where there’s not much variance in the environment. In contrast, the operating environment for embedded systems could involve temperature extremes, vibration, shock, and other factors that dictate specific quality considerations.

Scope creep (also known as feature creep, requirements creep, featuritis, and creeping featurism), however, refers to the uncontrolled growth of functionality that the team attempts to stuff into an already-full project box. It doesn’t all fit. The continuing churn and expansion of the requirements, coupled with inadequate prioritization, makes it difficult to deliver the most important functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy.  Scope creep is one of the most pervasive challenges of software development.