Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Team X has been working on an application and the big release is coming up.  Many of the company's applications will integrate with this service and be dependent on it.  The Team makes the decision that the product needs to be "rock solid", because if it goes down, so do all the apps that are using it.  The company as a whole does not do any standard quality assurance, and the Team believes that this is an issue.  They feel that due diligence includes QA for this service as well as other products being developed across the organization.  They want to begin investigating tools since testing would need to begin asap.  How should their needs and concerns be communicated?  How should the tool selection be conducted and a decision made?

...

ISDA Communication Strategy v1.ppt

June 20, 2008

Identify the SCOPE of the issue
Identify a subject matter expert - internal or external
    Get the right people involved - look outside your own team
Be clear about what you need and for how long
Communicate this to your manager
    They should communicate back to the leadership - people who make the final decisions
    Socializing the problem
    This is how you get resources an communicate who is doing what
Manager can step in when there is a resource constraint or when ther is cost associated with the problem
Clearly identify who is responsible for what
    Decisions
    Work
    Prioritizing
Make recommendations based on research by the group - be able to support your argument
Sometimes making a decision is more important than the decision itself
"What is good enough"? (hard to calculate ROI on much of what we do)
Resistance to having things go "higher up the chain"
SME and manager can present recommendation to leadership team - opportunity for feedback
Be accountable
Sometimes a recommendation or decision goes against policy or the policy hasn't been clearly defined yet "road block to decisions"
Is there a stigma to "good enough"?  Do we shoot too high?
Neglecting the "let's try it" scenario - experimentation or pilot allows for better requirements gathering
Talk to the customer
Resistance to raising expectations
Don't make promises - focus on the business problem you are trying to solve
Don't avoid conflict