 |
|
At iRise, we have been preaching for many years that words by themselves do a poor job of defining the requirements for software applications. So, it’s refreshing to see someone else – especially a Forrester analyst – pile on to the discussion.
Tom Grant, a senior analyst in the Technology Marketing group at Forrester, published a research document this week titled “Improving Your Product Management Tools”. While the note is targeted at product marketing and management professionals, the roles and tasks performed by these workers have significant if not total overlap with business analyst and usability professions.
The problem is actually double-edged. According to Tom, “most product managers rely on tools – predominantly Microsoft Office – that do not adequately support them.” And while there are tools specifically designed to handle product requirements, the majority of technology companies do not embrace them.
Tom further identifies 6 functions needed to address the requirements challenges for product managers and describes the shortcomings of trying to use Microsoft Office, Web 2.0 tools and CRM systems:
- Collection
- Analysis
- Prediction
- Connection
- Communication
- Updates
By the way, iRise was mentioned as one of the tools for the Communication function which Tom defines as modeling or simulating use cases to communicate to stakeholders.
Tom’s research also pointed out that innovators are more than twice as likely to adopt requirements tools. He examined companies based on their size, company age and product delivery and found that requirements tools were adopted at a much higher rate in companies that were 1-5 years old, smaller than 500 employees and who used software as a service (SaaS) delivery.
The full 16-page report is available from Forrester for $279 and is worth a read for anyone involved in defining and managing requirements. You can also read Tom Grant’s blog at this link and he welcomes feedback.
|
|
|
|
|
|
Carey Schwaber, Senior Analyst from Forrester Research presented at the iRise-sponsored June Catalyze community webcast last week.
In addition to presenting her top 10 list of ways to improve project outcomes for business analysts and others involved in software definition, Carey answered nearly 20 questions from the audience. If you missed the live broadcast, you will definitely want to listen to the webcast recording so you can hear Carey’s unique perspective on the role of business analysts, software definition and requirements.
For a sneak preview, here is a peak at Carey’s top 10 list:
- Define the business-IT division of labor
- Be part of the team
- Understand and communicate impact
- Define future as well as present business needs
- Remember non-functional requirements
- Make requirements painless for the business
- Measure project progress in terms of requirements
- Don’t rely solely on text
- Maximize feedback on requirements
- Invest in future project outcomes too
The webcast was recorded and can be viewed in the iRise Media Center, and the slides from the presentation have been embedded below.
|
|
|
|
|
|
Catalyze Webcast – “10 Tips for Driving Better Project Outcomes”
Featuring Carey Schwaber of Forrester Research
Thursday, June 12 @ 10am Pacific/1pm Eastern
Register for the webcast here.
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 line.
- What can business analysts do to improve requirements definition practices and make a difference in project outcomes?
- What skills do business analysts need?
- What roles can they play?
- What tools should they use, and what role should those tools play?
Don’t miss this valuable online seminar sponsored by iRise and featuring one of the industry’s leading experts on the subject of requirements definition, Carey Schwaber, a senior analyst from Forrester Research. Carey has talked with hundreds of organizations that use a variety of requirements definition tools and methods. From this experience and accumulated knowledge, she has developed a set of 10 practical tips that you can immediately put into action in your own organization.
If you cannot make the live webcast, the recording will be uploaded to the iRise and Catalyze websites by June 16.
|
|
|
|
|
|
Emmet Keeffe, iRise CEO and Co-founder, had an opinion piece published this week in SandHill.com. SandHill.com is the premier destination online destination for strategic information on the software business. The site and its newsletters are read by thousands of top software industry executives every week.
Emmet talks about “The Requirement Challenge” and why ”Accurate Specs are Key”. He finishes with “The Benefits of Visualization” which I am paraphrasing below:
- Business people can fully experience the product and make changes early in the process, saving significant time and downstream costs.
- Developers can catch design and functional errors before an application goes into production.
- The process can speed through multiple rounds of functional visual edits to quickly reach decisions on business needs and customer experience.
- Managers can increase final adoption of system with upfront agreements of the application’s process flow, experience and visual look and feel.
- User experience professionals can rapidly iterate proposed designs directly in front of customers, dramatically improving customer experience.
- Software sales teams can demo potential products to customers to get feedback before actually developing the application.
- The professional service teams can test a potential product for possible needed changes to speed implementation and integration.
- Sharing visualizations with global sourcing partners is not only easier but cheaper. Visualizations eliminate confusion with global development teams because everyone is speaking the same language.
- Resellers can sell a solution by showing a visualization of what a specific application could do when integrated into the customer’s environment
He wraps up by repeating his vision, “by 2020, all business software will be visualized before its built, just the same way that every car, airplane and semiconductor are visualized today.”
The entire piece is worth a read and can be found at SandHill.com.
|
|
|
|
|
|
I ran across an interesting blog post this week from Chris Woodill on how to be an effective stakeholder. This post intrigued me because it examined the project team/stakeholder relations dynamic from the stakeholder angle rather than the putting all of the onus on the project team. I have summarized some of Chris’ vision of the expected stakeholder roles and his counsel to stakeholders on “how not to drop the ball”.
“Good” stakeholders need to:
- Make decisions – making decisions is the stakeholder’s primary responsibility
- Approve documents – timely approvals of decisions and documents
- Offer opinion and feedback -provide actionable feedback that can be translated into actions, revisions or improvements
- Solicit feedback - help explain, sell concepts and capture feedback from the broader community
- Support the team externally – evangelize the project, boost team confidence and help get organizational buy-in
- Maintain a high bar of expectations – demand excellence from the team
In addition, “good” stakeholders should:
- Be prepared for all meetings – take the time to do your homework before all meetings
- Make decisions and offer feedback in a timely manner – don’t delay the project by being late
- Be nice to the team – don’t bully the team
- Articulate requirements clearly – if you are the domain expert, you need to provide clear and complete requirements to the team
- Embed themselves into the team as much as possible – refrain from making us and them distinctions
Being a “good” stakeholder can make a massive difference in the success of a project and minimize project risk at the same time.
If you’re on a project team, you may want to forward this to your stakeholder. If you’re a stakeholder, you may want to look in a mirror and ask yourself “am I a good stakeholder?”.
|
|
|
|
|
|
There is a new study out by IAG Consulting that confirms many previous studies and the gut-level feeling that most of us have around requirements, namely that companies with poor requirement gathering processes are going to have more project failures than successes. In fact, the new IAG study points out that companies with poor business analysis capabilities will have 3 times as many project failures as successes. The report also went on to state that effective business requirements are a process and not a “deliverable”.
One of the more telling graphics pointed out that the competency of the business analyst team had a significant impact on successful projects. Companies in the lower 3rd of competency classified only 10% of their projects as successful or unqualified successes. On the other hand, companies in the upper 3rd of competency described more than 70% of their projects as successful
IAG also quantified the inefficiency of poor requirements using an average project size of $3 million. Companies with poor requirements processes will:
- Be on budget less than 20% of the time
- Be massively over budget in time and budget about 50% of the time
- Spend about 75% per project more than companies who follow best requirements practices
The survey focused on larger companies with development projects with budgets in excess of $250,000 and that delivered significantly new functionality and the average project size in the study was $3 million.
The Executive Summary is available from the IAG website. The full text report can also be downloaded by registering at the IAG Research Library and the press release on the study can be found here.
|
|
|
|
|
|
Are you having trouble communicating with your stakeholders? Do you want to improve how you gather requirements?
If so, you should join the Catalyze Community monthly webcast on February 14th with Barbara Carkenord from B2T Training as she explains how to design a sure-fire strategy for developing a communication plan.
Both business analysts and usability professionals will be more effective when they think ahead about how best to communicate with their stakeholders. This presentation provides attendees with a communication planning technique that can easily be used on any project.
Webcast Details:
- Date and Time — Thursday, February 14 at 11am Pacific/2pm Eastern
- Registration — Sign up at this link
- Recording – If you miss the live broadcast, the recording and presentation will be posted in Catalyze by February 18
Barbara is the President of B2T Training and has over 20 years experience in business analysis. Barbara has an MBA from University of Michigan and is a Certified Business Analysis Professional (CBAP).
|
|
|
|
|
|
I ran across an interesting presentation (”Sketching in Code: Using Prototypes to Visualize Interactions“) that David Vreba, Director of Technology at Adaptive Path, delivered at the UXWeek conference in August.
In particular, two slides in David’s presentation with the titles “Why Prototype?” caught my attention. These slides sum up in a nutshell why prototyping is so important:
- Visualize your requirements – save a lot of time and effort by not creating so many paper-based requirements that are difficult to review
- Get to market faster – generate a lot of cash by getting a better product to market faster.
Effective prototyping can reduce cycle times throughout the entire software development lifecycle.
David also presented 5 key reasons to prototype including:
- See problems more clearly
- See some problems at all
- Gain buy in from stakeholders
- Foster collaboration
- Help everybody understand what is possible
I think #2, “see some problems at all“, is one of the more overlooked reasons to prototype. In many cases, stakeholders may not even be aware of problems with usability, flow and design until you actually show them what you had in mind. This is because reams of text-based requirements written down on paper do not come close to showing someone what you meant.
Point #4 – “foster collaboration” – is probably the least expected side benefit of prototyping. Without even knowing it, sharing a prototype gets groups talking that may have never talked in the past. This then facilitates better communication throughout the rest of the project and has carryover benefits into the next project and beyond.
Most people need to visualize something and even better try something to truly understand it. And it is much better to show them early in a prototyping phase than near the end of the development lifecycle when the final product is almost complete.
You can learn more about David Vreba’s presentation, and download the slides and audio at this link.
|
|
|
|
