Image for post
Image for post

Rather than building software systems in-house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they lack in-house, to augment their internal staff, or in an attempt to save money or time. The outsourced development supplier could be located physically nearby, on the other side of the world, or anywhere in between.

The role of a business analyst (BA) is even more important on these projects than on a co-located project. If the team members are all in one location, developers can walk down the hall to ask the BA a question or to demonstrate newly developed functionality. …

Image for post
Image for post

When customer expectations are high and timelines are short you need to make sure your project team delivers the most valuable functionality as early as possible. Prioritization is the only way to deal with competing demands for limited resources.

Stakeholders on a small project often can agree on requirement priorities informally. Large or contentious projects with many stakeholders demand a more structured approach. You need to removes some of the emotion, politics, and guesswork from the process. This article discusses several techniques teams can use for prioritizing requirements and some traps to watch out for.

Two Big Traps

Be sure to watch out for “decibel prioritization,” in which the loudest voice heard gets top priority, and “threat prioritization,” in which stakeholders holding the most political power always get what they demand. These traps can skew the process away from addressing your true business objectives. …

Image for post
Image for post

As a consultant and author, I often receive emails posing questions about the challenges people face dealing with requirements issues on their software projects. Here’s a question on an issue many teams encounter: replacing an existing software application.

George’s Question

“I am responsible for implementing a new system to replace a mainframe application that has been in production for a very long time. We have no documented requirements for the current system, the original developers are long gone, and our user community has since been changed out.

“Does it make sense for us to document the requirements of the current system as a prerequisite to documenting the go-forward requirements? Or should we disregard what we now have in production and document the go-forward requirements from scratch? …


Karl Wiegers

I’ve written on software development and management, consulting, self-help, chemistry, military history, and a mystery novel. More info at

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store