One of the key points that enables James’ approach is “tight collaboration†between the program manager and the developers. He talks about the miracles that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on.
Communication / Requirements / UX
Posted on:
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 […]
Requirements
Posted on:
Requirements mess article in CIO magazine
Btw, here’s a link to the article in CIO magazine, that I mentioned indirectly in my previous post about the requirements mess. This really is a great article – it includes 3 case studies of how different CIOs dealt with the problems on their teams.
Communication / Project Management / Requirements / Writing
Posted on:
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 […]
Software development / Usability / UX
Posted on:
User Centric Design Yields (Not So?) Obvious Features
An application lives or dies by its ability to allow users to achieve the goals that drive the creation of (or purchase of) the software.
Requirements / Software requirements specification / Writing
Posted on:
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
Requirements / Software requirements specification / Testing
Posted on:
How To Deal With Untestable Requirements – Rewrite Them
The premise behind the rule that requirements must be testable is driven by the goal of avoiding ambiguous language in your requirements. Statements like “the application must have a clean user interface†or “search response times must be fast†are also untestable, but more because of language than anything else.
Outsourcing / Requirements
Posted on:
Fixing the Requirements Mess
“71 percent of software projects that fail do so because of poor requirements managementâ€