One of the key Roles that a Requirements Analyst plays is defining and managing the scope of a project.  Of all the tasks we perform, this is one that is fraught with all manner of complications and one that is most often mismanaged.  The ArgonDigital ROM Framework provides excellent tools and methodology for ensuring that scope and features are well defined.

Even with a structured approach, the sheer size and complexity of enterprise scale software development still has a large human or soft component associated with defining scope for these efforts.  There is a large amount of subjectivity, judgment and trade offs in the process of defining scope.  This is particularly true at the level of individual releases.  While we might get all the features that are in scope delivered eventually, a lot of the thorny issues arise around the sequence of delivery of these features.

As Requirements Analysts, we sit right in the middle of the competing factions and interests involved in defining scope – the different Business Units on one side and Development on the other side.  We are the facilitators who help all the different groups arrive at the best decisions and eventually the solution that best meets the Business Objectives.  We are the glue that holds the process together.

The ROM Framework and Methodology are the tools of our trade.  But a bland, robotic application of these techniques is not likely to get us the results we want.  The key ingredient that the Requirements Analyst needs to add to the recipe is Trust.

Simply put, if we are not trusted by ALL the constituents, the process will fail.  As stated earlier, even with the use of the ROM Framework, there is a large element of human subjectivity and judgment that needs to be managed.  As the facilitators of this process, the users must TRUST that we are indeed impartial and striving to help the group arrive at the best possible solution.  If they do not trust the facilitator, then the effort will go nowhere.

So how then do we build trust?  Besides all the obvious things that any person does to build trust with a group – be truthful, be fair, be professional, be egoless – there is one thing that I consciously do.  I try to be an advocate for the users.

Before I proceed further, let me make one thing very clear.  I do not mean to make light of the “obvious things” mentioned above.  If you are not personally trust worthy or behave in an unethical or unprofessional manner, any attempted advocacy will fail.  And mainly because the messenger is not deemed a trustworthy person.  So, let us move on to advocacy within that framework.

So what does advocacy mean in the context of requirements management and why is it important in building trust?

Being an advocate does not mean blindly fighting for the features of the users you are representing regardless of the consequences.  That is being a partisan.  And behaving like a partisan is the fastest way to lose credibility with all the other constituents who comprise the group.

Effective advocacy in a requirements setting is based on two simple activities.  And one, that is a tad more difficult.

First, understand the real needs of the constituent.  Why a feature(s) is important for them, the benefits of the feature for them and the benefits to the overall group from the feature.

Second, ensure that the justification for the feature is properly crafted.  This means ensuring that the justification for a feature is done properly.  The need is clearly documented, traced back to the Business Objective, the benefits are quantified and potential costs of non-implementation are calculated.

Third and most importantly, make sure that the argument is heard and considered.  This is the part where as Analysts we need to show persistence and an understanding of the process to make sure the right people consider the request.

As requirements professionals we all do steps 1 and 2 above – defining the requirement and understanding the need for it.  Where I find people often fail is in step 3 – ensuring that the request is considered by the right people.  It is in mastering step 3, that one truly becomes an effective advocate for the user.

If we can consistently be an effective advocate, we become a trusted partner for the user and the group as a whole.  The users trust that they will be heard and their viewpoint presented effectively.  The group trusts that any request we bring will be well considered and not a waste of their time.

This more than anything else, builds trust in you as a person and an effective member of the team.

So, go ahead and be an advocate.  Make sure that all your users are heard and their needs considered.  Fairly.  Objectively.

Then let the chips fall where they may.  You have done your job.