EXPERT RESPONSE
I hear frustration in your question, the kind that comes with trying to do your job in an environment that is not, for whatever reason, cooperating. Let's have a look in an effort to help you discover some different approaches. Approaches that not only recognize the challenge, but also look at possible ways the project is being affected (impact), possible causes (root cause), potential ways to solve at least part of the problem (possible solution) and those things that get in the way of a solution (barriers). Not knowing the specifics of your situation, but having worked in many an environment that challenged effective requirement definition, I am confident that some of the following will hit the mark and give you some new avenues to consider. (Click the picture for a larger view.)
Establishing a less challenging environment
If you are responsible for requirements, knowing what you need to do the job will take you a long way. Arm yourself with the "fundamentals" (product vision, project success criteria, defined roles, basic set of requirement techniques). Here are a few suggestions of how to compensate.(Click the picture for a larger view.)
Time and time again, I have leveraged a facilitated interaction to not only get what I needed as a requirement analyst, but to also get what the sponsor and project team needed (but could not articulate). The goal is to get "a foot-level deep" understanding of the product/project so you can do your job of defining the requirements and others have a context within which to do theirs.
Staging one of these encounters requires preparation and insight. You will need to:
- Determine the goal of the session along with the rules of engagement (be on time, silence implies consent,…)
- Create an agenda that reflects the goals of the session.
- Identify an experienced facilitator who is perceived as unbiased.
- Find an appropriate facility (projector, whiteboard,…)
- Identify/notify participants.
- Determine requirement techniques (vision statement, context diagram, use case diagram,…) to be used during the session.
- Determine who will do what during the session (facilitate, take notes,…)
- Determine how follow-up will be orchestrated.
Since the success of the session is directly proportional to the quality of the preparation, make the best of your captive audience! (Hint: If some of the participants are remote, just provide them with a chance to speak but hold them accountable for their own participation.)
Changing perceptions
Changing a perception is strictly a "people" challenge. Here are a few insights that may help.
- Terminology is a major culprit. Speak to the definition of what you are trying to convey instead of using a label or term that may hold a different meaning for the other person. Sometimes there is violent agreement, but because the terms are different there is apparent (but not real) disagreement. Sometimes just the opposite is true.
- Asking why (multiple times) may eventually lead to a condition that you can do something about. For instance, let's take a sponsor who does not provide a clear product vision and ask a series of "whys."
- Why didn't Sponsor provide a clear product vision?
He did not have time.
- Why didn't the Sponsor have time to create a product vision?
Because he did not realize it was important to the development team.
- Why he did not realize the project vision was important to the development team?
Because no one talked with him about how IT can help achieve a business objective.
You get the idea. Maybe this is a perception that a little quality talk can fix.
Summary
Being successful with requirements definition depends on knowing what you need to get the job done. The fundamentals are essential even if you have filled the gaps with your own creation and seek validation. You have legitimate expectations of other members of your project team as they have legitimate expectations from you. By clearly stating expectations as the project moves forward, your needs as well as those of other project team members are highlighted. Similarly, when a need is fulfilled (product vision is agreed to, requirements are provided and so forth), trust is built. In my experience, the location of the project team members is less important than their attitude and their ability to deliver what is needed in a timely way. It is important, however, to have some face time early in the project to avoid the "us versus them" syndrome. High-trust teams, colocated or not, do succeed because they just will not have it otherwise.
|
