Sympriser

Intelligent dialogues require trustful relationships.

In the previous post “Most Requirements are just Design Decisions”, we invited BAs to rethink the rigidity of software requirements.

Relevant environmental changes or new knowledge should trigger corresponding requirements adaptation. Leading this process, a BA adds more business value to their organisations.

Unfortunately, requirements are just requirements for many BAs. They don´t have the opportunity to participate in the intelligent dialogues where strategic design decisions are made.

Effective collaboration between the IT function and other business functions can be a complex and difficult issue in many organisations. This represents a critical credibility problem that must be addressed both by IT executives and IT professionals.

The perceived credibility of an IT professional goes beyond his or her personal competence and integrity; it is grounded in trustful relationships.

Principles

Now I invite you to reflect on your professional relationship style. Is it effective to create and nurture trustful relationships? Here are some principles I have used over the years with good results.

Be a Good Citizen at Workplace. Genuine citizenship behaviour means to me to actively respect all fellow professionals and executives and foster a positive, constructive and productive work climate.

It is also important to have a clear view of what is bad workplace behaviour. David Maister highlights “20 bad workplace habits” from Marshall Goldsmith´s book “What Got You Here Won’t Get You There”.

Reach Out and Touch. Try to see where you and your clients fit in the whole picture. Be open to learn, understand and appreciate their values, interests and the language they use. Then, get closer to them.

Promote Dialogue and Empowerment. I found myself many times eager to present solutions to users as soon as I grasped the most salient problem issues. I learned through experience that rich and frequent dialogues are key elements for more fun and effective processes, that generate better quality solutions and results.

Give Consistent Care. Respond quickly, reliably and honestly to your clients demands. Make sure you consider thoroughly how all your actions will affect their actions. Always be in the front with your clients during major software transitions.

Do these principles resonate to you?

Share with us your thinking about this critical issue for our profession.

I thank Raven Young for indicating David Maister´s post, that inspired me for this post.

This article was originally published at Better Projects.

The language we use both reflects and influences our thinking.

The term “requirements” has its roots on bureaucratic thinking, that supposes a static and impersonal business world where specialists would be able to uncover, extract and document the definitive specifications for software systems.

Jeff Patton in his post “Requirements considered harmful” alerts us that most requirements are just design decisions. He shows how typical behaviours like asking and giving requirements can be dysfunctional because they justify avoiding responsibility and stop collaboration on a critical success factor for software development projects.

Recognizing that most requirements are just design decisions, gives us a better chance to design and deliver more effective software solutions if we (a) carefully treat them as design products and (b) are ready to adapt them quickly to new circumstances.

Carefully defining requirements as a product of a design process means we should (1) use a collaborative process involving all relevant stakeholders, (2) reflect about the requirements under different perspectives: market, business, users, system and (3) use the most adequate tools and language to express the requirements in a common framework comprehensible to everybody in the team.

Being ready to adapt the requirements means being agile to sense and respond to relevant environmental changes and being open to incorporate new knowledge generated by the organization. The capability to learn and innovate, quickly adapting and creating changes is critical for leadership in the marketplace. Business software should enable these changes and not prevent them.

I know there are situations where requirement changes are beyond our sphere of power and influence. However, as responsible professionals, we should not just let requirement decisions hide under processes, documents and signatures. It is healthy to foster reflection on the what and why of software requirements. As Business Analysts, we should lead this process and help our organizations expand their possibilities.

This article was originally published at Better Projects.