Volume 2 :: Number 3 :: 2008
President and Principal Consultant
EBG Consulting, Inc.
In this issue:
|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.
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.
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.
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.
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.
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|
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:
Visit our archive to read our prior issues.
|Publication & Reprint Information|
Success with Requirements is a trademark of EBG Consulting, Inc.
© 1993-2013 EBG Consulting, Inc. All Rights Reserved.