I sat in on a Catalyze Community webinar today, given by Carey Schwaber, a Sr. Analyst at Forrester Research. The topic was "Ten Tips for Driving Better Project Outcomes" and was directed at the Business Analyst role, which is one way to view the Product Management role. (A recording of the webinar will be posted in a couple days.) The abstract given was:
It’s no secret that in the battle to bring effective business software to market on time and on budget, business analysts are on the front lines. What can business analysts do to improve requirements definition practices and make a difference in project outcomes? Join us as Forrester Senior Analyst, Carey Schwaber, shares a set of 10 practical tips that you can immediately put into action in your organization.
The discussion was centered around the idea of developing requirements for a new product (software typically). The tips were fairly obvious for people who spend any time thinking about project management and communication, but it was useful to hear the discussion about how these ideas play (or don't play) in practice.
Here are the tips as discussed in the webinar were done in reverse order. My favorite is #2, as this is such an important aspect of getting people to play and think about how the product is really supposed to work.
- Define the business-IT division of labor.
- Requirements need to be put together jointly.
- Joint activities frequently vanish or lose the story.
- Be part of the team.
- All roles have to be part of the team for all activities: meetings, communications.
- The team must deliver a single product, not many products delivered together.
- The alternative is too much time creating artifacts without involvement, particularly for the product manager / business analyst.
- Assess the true impact of change.
- I loved this one: "Avoid swivel-chair integration" - integration that involves entering data in one place, spinning your swivel chair to enter data on another panel.
- The drive for efficiency often takes you down the integration path.
- Understand future as well as the current business needs.
- Business changes, so requirements change, so software must be flexible.
- Remember non-functional requirements.
- This is more of the how and why of the needs, rather than the what.
- i.e. Security and Usability and Performance
- Make requirements painless for the business.
- Measure project progress in terms of requirements.
- I'm not completely sure I agree with this, since I would rather see a project network a progress measured against the critical chain. But the requirements can be a proxy for the project completion.
- Don't rely solely on text (text-based requirements).
- Maximize feedback on requirements
- Don't let misunderstandings become defects to correct.
- Invite people to requirement reviews.
- Frequent demos to likely users.
- Deliver working software incrementally!
- Invest in future project outcomes too.
- This project will impact future projects.
- Look for opportunities to fix the relevant processes.