I attended training on making compelling presentations last year – and one thing that was stressed was the use of imagery to drive points home. Although there have been images in my posts to date, they have been utilitarian – not sources of imagery. I need to do better with […]
Active Listening and Cultural Cues – When No Means Yes
Without good communication skills, you won’t understand what the stakeholders want. And you won’t structure and describe the requirements in a way that the developers will implement what you intend.
For a given project, there are three sets of requirements – the requirements you are given, the requirements you document, and the requirements that are interpreted by the delivery team.
A Picture Is Worth A Thousand Requirements
Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.
OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat –
It’s not business, it’s just personal
Having the best powerpoint presentation (thanks to Presentation Zen and Beyond Bullets, this is possible) is not sufficient to persuade. We have to craft personal messages. We have to be interactive, and adapt our presentations as we present – maybe even discard them entirely, and craft the key points of our messages into a conversation lead by the people to whom we are presenting.
More on talking to your audience
I was reading ok-cancel today, and saw an article about getting UI designs ‘through the gauntlet’ of different groups of people at the client. Kevin and Tom consistently provide great insights on how to thrive in the HCI world, providing insights both in how to navigate customer-politics and processes, and […]
Intimate Domains – navigating areas of expertise
People who elicit and manage requirements – product managers, business analysts, program managers, and others – also orchestrate and communicate with their clients. In an enterprise software project, the requirements manager (RM from here on out) has to communicate with people across the client organization. To pass along information, gain […]
Stop Wasting Your Time – Don’t Bother Writing Functional Specs
Don’t do it. Don’t use a functional spec to get superficial agreements and navigate the beurocracy that accompanies large projects. Don’t validate the specification trivially. Don’t deploy with a waterfall process (the spec is done, whew, now – on to design) and never revisit the spec. Don’t work with new developers, or remote developers, or anyone else who doesn’t have the context of direct eyeball-to-eyeball conversations with the customers. Also don’t hire any programmers without complete domain expertise in the customer’s business
Fixing the Requirements Mess
“71 percent of software projects that fail do so because of poor requirements managementâ€