Image for post
Image for post

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. This article describes these three modes of engagements based on my experience as a business analysis and process improvement consultant.

Mode #1: Outside Looking In

As an expert, you’re working with a client who has a problem and wants you to fix it. I’m working in the expert role when a client brings me in to deliver some training, perform a process assessment, review a project’s requirements, or advise how to improve their BA processes. …


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? …


Image for post
Image for post

I learned a powerful life lesson from a date that did not go well. The poor date was entirely my fault; I make no excuses. I was not in a good state of mind, distracted by thoughts of another woman who had just dumped me. I wasn’t focused on Chris during our date, even though she was much more my type.

I’d known Chris for several years; we worked at the same company. We had joked around with each other and even flirted a bit. I thought she was cute and funny so I asked her out. But I wasn’t good company that night. …


Image for post
Image for post
image adapted from www.admissions.uga.edu/blog

I’ve worked with some software organizations that always meet their delivery schedules. When it becomes clear that the project won’t finish on time, the team enters a “rapid de-scoping phase.” They defer some planned functionality, whiz through testing, and release on schedule a crippled system with quality problems that provides no value to anyone. Then they declare success because they delivered on time. Yes, they delivered something on time, but it bore scant resemblance to expectations.

Defining your product’s release criteria is an essential part of laying the foundation for a successful project. Release criteria must be realistic, objectively measurable, documented, and aligned with what quality and success mean to your customers. …


Image for post
Image for post
Photo by You X Ventures on Unsplash

Technical peer reviews are a powerful software quality practice. In a review, a group of people examine a work product for defects and improvement opportunities. I’ve been a big fan of peer reviews since about 1988 and would never work in an organization that didn’t practice them routinely.

Any type of software work product can benefit from review: requirements, designs, code, tests, plans, documentation, process descriptions. Yet teams often have difficulty getting a review process going. In this article I describe the symptoms of seven common review problems and some solutions.

Sin #1: Participants Don’t Understand the Review Process

Symptoms: Software developers don’t instinctively know how to conduct and contribute to software reviews. Review participants may have different understandings of their roles and responsibilities, and of the review steps. Team members may not know which items should be reviewed, when to review them, or what review approach to…


Image for post
Image for post

Software development teams and managers want to know what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for improving their project requirements. I’d love to provide a precise answer — but I can’t. As with so many questions consultants hear, the correct answer is, “It depends.”

Regardless of the life cycle your projects follow, success demands a solid foundation of well-understood and clearly-communicated requirements. This article explores some of the factors that influence what ROI an organization can expect from better software requirements.

The Investment

To determine the ROI from any activity you need to know both what you invested and the resulting benefits — reduced costs, accelerated schedules, higher quality, increased sales, whatever. Unfortunately, few software organizations collect this sort of data. It’s not hard to track the money and time your organization spends developing improved requirements. Measuring the payback is trickier. Let’s look at both sides of the analysis. …


Image for post
Image for post

When I began my graduate studies in chemistry many years ago, I quickly realized it was impossible to do all the work I absolutely must do. I had to learn to prioritize the competing demands for my time, to make sure I worked on the most important tasks first. This strategy minimized the downside from those activities I didn’t manage to finish.

Every group also needs thoughtful ways to prioritize their seemingly infinite backlog of project requests. …


Image for post
Image for post

I once facilitated a project retrospective for a website development team that included several software developers and some visual-design and human-factors experts. One of the visual designers complained that she never knew the status of the software side of the project.

“What do you mean?” asked the lead software developer. “I sent you emails all the time with status updates.”

“Those emails didn’t do much for me,” the visual designer replied. “I figured you’d walk over and talk to me about important issues. I felt like you had excluded me from the loop.”

The software lead and the visual designer obviously had very different communication expectations. Problems arose because each party communicated in the way that was most comfortable and natural for them, without regard to whether that met their counterpart’s needs. Consequently, important information was not exchanged and feelings were hurt. …

About

Karl Wiegers

Author of 12 books on software development, project management, design, consulting, self-help, and a forensic mystery novel. Guitars and wine fill the voids.

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