Success with Requirements

Volume 2 :: Number 3 :: 2008
ISSN: 1936-3583

Welcome to our Newsletter

The bedrock of any great team is trust. Yet, trust is something that doesn't happen automatically. It needs to be built early on in any project and requires continual care and feeding. I have found that good requirements practices, applied from the start of any project, enable trust. In this month's eNewsletter, I share characteristics of trust and how good practices will help you build and sustain trust in your teams. I hope you find it useful.

I welcome your reactions. Please let me know what topics you'd like to see me address in upcoming eNewsletters, too!

~ ellen

Ellen Gottesdiener,
President and Principal Consultant
EBG Consulting, Inc.
http://www.ebgconsulting.com

In this issue:

Building Trust with Good Requirements Practices, Part 1

Latest EBG Publication in Crosstalk

Upcoming Events

Resources of Interest

EBG Agile Offerings

Archive Issues

Building Trust with Good Requirements Practices, Part 1

To work together effectively, the members of a team need to trust one another.

When you're developing product requirements, the issues at play include meeting deadlines, controlling cost, delivering the solution, incorporating changes, and ensuring quality. There are plenty of opportunities for trust to break down. Without trust, there may be hidden agendas, rumors, gossip, whining - even subversive behavior.

Johann Rost (2004) reported subversive behavior by team members, such as lying, withholding or delaying access to information, providing misleading or vague answers, and supplying poisoning ideas. Clearly, these projects are suffering from lack of trust which can result in project churn, team turnover, low morale, and unhappy customers.

Understanding Trust

It doesn't have to be that way.

Reina and Reina (2006) identified three types of trust needed in organizations:

Contractual trust. As you might expect, this kind of trust is based on an unstated "contract": you will look out for my best interests, and I will look out for yours. If things change, we will renegotiate. Ultimately, we are jointly responsible for our success.

Communication trust. This kind of trust calls for honest and frequent communication. Team members share information, tell the truth, admit their mistakes, maintain confidentiality, and seek and provide feedback. Their actions are consistent with their words, and vice versa.

Competence trust. Team members respect one another's ability to get their jobs done. They promote mutual learning and development of everyone's skills and knowledge.

Laying the Foundation for Trust

The time to build trust is at the beginning of a project, when you decide what to build - the process Frederick Brooks called "the hardest single part of building a software system." This is when the team charters the project, defines its vision and scope, identifies stakeholders, and begins to elicit requirements.

What practical steps can you take to build trust in your team early on? Let's take a look.

Define the Product Vision and Scope

One way to build trust is for the stakeholders to define a product vision statement. This document tells team members what they need to build, for whom they need to build it, and how it's different from what exists today.

Your vision statement builds contractual trust by establishing shared goals for business and technical staff. If the team can't agree on this document, you're not ready to plan and build the product.

Involve the Stakeholders

A first step for defining requirements is to identify stakeholders and other sources of requirements information. This includes a wide variety of people: product owners and champions, developers, subject matter experts, business analysts, project managers, and specialists in testing, QA, auditing, regulatory issues, training, sales and marketing, and so on.

You build communication and contractual trust by planning how and when to involve stakeholders. You sustain these types of trust by following through and collaborating to explore, discover, and acquire sufficient requirements to begin development. Stakeholders also need to address, early in the project, how to develop the team members' skills - thereby promoting and sustaining competency trust.

Keep a Glossary

The glossary defines the meaning of the business terms in your product domain. Project teams need to speak the same language, building competency and communication trust.

Set Criteria for Prioritizing Requirements

Software teams need a method for evaluating and filtering requirements. This practice builds contractual trust and eases communication.

For low-risk, simple projects you can prioritize requirements by assigning a general rank (such as high, medium, and low). For larger, more complex projects, you should precisely define the business value of each ranking.

Deciding What to Build Can Build Trust

A team's ability to explicitly establish and sustain the three types of trust - contractual, communication, and competence - at the start when they are deciding what to build - is an early and critical indicator of project success.

In a later newsletter I'll talk about other proven methods for building trust as you elicit requirements for your software projects.

~ ellen

References

Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements, GOAL/QPC, 2005.

Gottesdiener, Ellen. "You Know When It's Not There: How Trust Enables and Enhances Collaboration," Cutter Journal, Vol. 20, No. 8 (August, 2007)

Reina, Dennis S., and Michelle L. Reina. Trust & Betrayal in the Workplace: Building Effective Relationships in Your Organization. 2nd edition. Berrett-Koehler Publishers, 2006.

Rost, Johann. "Political Reasons for Failed Software Projects." IEEE Software, Vol. 21, No. 6, November/December 2004, pp. 104, 102-103.

Latest EBG Publication in Crosstalk

We are pleased to announce our latest feature article, "Good Practices for Developing User Requirements" in the widely distributed Software Technology Support Center's Crosstalk Journal. You can read the issue online here.

Upcoming Events

1. Mary Gorman will deliver two full-day tutorials and a presentation at Business Analyst World/Project World, Toronto (April 14-19, 2008).

2. Mary will deliver two full-day tutorials and a presentation at Business Analyst World/Project Summit, Philadelphia, PA (April 28-May 1, 2008).

3. Paul Reed will be delivering a full-day tutorial and a presentation at ProjectWorld/World Congress for Business Analysts, San Diego, CA (June 24-27).

Resources of Interest

Each month we'll provide a few resources we think are worthwhile. The resources below are related to this month's topic on requirements and trust.

We welcome you comments and suggestions for future issues!

Read more about building trust in this article by Dennis and Michelle Reina (referenced in this eNewsletter's article).

In his classic 1986 essay "No Silver Bullet" Frederick Brooks explains why the "soft stuff" is so hard in software engineering.

Making decisions explicit and using a collaborative process to reach them is essential for building trust. I discuss the why's and how's in my article "Decide How to Decide."

EBG Agile Offerings

EBG offers training and coaching services in using agile techniques for our clients transitioning to, as well as currently using, agile methods:

Training: Agile Requirements: Collaborating to Define and Confirm Needs builds skills in the agile method of developing requirements - the basis for delivering business value to customers on agile projects.

Coaching & Facilitation: Agile Jump-Start is great for launching new teams on a solid footing with an expert coach, and is also highly effective for teams transitioning to agile.

Archive Issues

Visit our archive to read our prior issues.

Publication & Reprint Information

I invite you to reprint material from Success with Requirements in other electronic or print publications provided 1) the following copyright notice is used, "Written and edited by Ellen Gottesdiener, copyright EBG Consulting, Inc., [year]. All rights reserved." and 2) a link to http://www.ebgconsulting.com/ is included in the credits.

Please send us copy of the publication that includes our reprint, along with a cover note referencing that it is a reprint.

Success with Requirements is a trademark of EBG Consulting, Inc.