Archive for the ‘Industry News & Trends’ Category

Aerospace Consultant recommends Contour as #1 choice for requirements management over IBM Rational DOORS.

Wednesday, March 10th, 2010

Having experienced the transition from start-up to bona fide company, we can relate to the advice given by Ralph Ewig in his blog article for Systems Engineering in the Entrepreneurial Space Industry. Here’s an abstract from his article:

To achieve the functions of “team alignment” and “customer input capture” you’ll need a requirements management tool. When choosing your tool, the most important rule is to select a tool that accommodates how you want to work, not a tool that forces you to accommodate how it works. Aerospace industry mainstays such as IBM’s Rational DOORS software are not only ridiculously expensive, but have evolved over many years to cater to their largest clients – using exactly the kind of overly formal practices you are trying to avoid.

Instead, consider web interface driven tools which evolved from the people who know software best (the software development industry). Jama Software’s Contour tool is my first choice, exceptionally capable at enabling a team of engineers to stay in synch, while also giving your customer real-time insight into how their input drives your efforts. It acts as the direly needed inbox-filter for teams suffering from “design by email” without placing any extra levels of bureaucracy between the technical team and the result of their labor. In addition, it is highly flexible to your way of doing things, and all but guarantees that no customer input will ever fall through the cracks again.

“Jama Software’s Contour tool  is my first choice, exceptionally capable at enabling a team of engineers to stay in sync, while also giving your customer real-time insight into how their input drives your efforts.” – Ralph Ewig, 15-year veteran of aerospace systems design, chief engineer at Holder Aerospace

Prior to the article, we had not met Ralph, but appreciate his unsolicited feedback on the experience he had with Contour and his recommendation of it to others in the aerospace industry.  It validates the differentiators of Contour, and our mission of building an application that our peers in product development want to use and find easy to use (instead of being mandated by management to use).

I’m always curious about how people learn about Jama, so I connected with Ralph via LinkedIn and found out he learned about Contour recently on a  project with one of our customers in Australia.  It was a desirable skill for the project team to have previous experience with Contour.  How about that?

I like to refer to it as an entrepreneurial company’s “path of bonafication” where you hit key milestones with your product that indicate you’re on the right path to disrupting the market leader’s grip on the category.  You know you are bona fide when…

  • Global deployments with thousands of users (check)
  • Fortune 100 customers adopt your product (check)
  • Top government agencies adopt your product (check)
  • Competitors buying your brand as keywords searched on Google (check)
  • Consecutive years of 100% + growth in revenue and employees (check)
  • Community of users recommending your product on their own to others (thanks)
  • Professors and universities incorporating your software into their curriculum (check)
  • And, companies listing your software as a desired skill for hiring employees and consultants (check)

It’s an interesting theme that’s occurring across businesses driven by the Web and social apps.  Where the big, traditional vendors try to win by spending millions on advertising (brute force) versus the new breed of companies try to win by building innovative software that works and helps people do their jobs faster and easier (grassroots).  We’ll see which approach wins.

The Secret to Designing Products Customers Love: Manage Requirements Effectively.

Thursday, December 17th, 2009

The Aberdeen Group just published a new Analyst report on the value of requirements management to help companies speed development cycles, improve profit margins and design products that customers love.  Every executive I know cares about product innovation, it’s the driver for greater financial performance of their respective companies.  But, few of them wake up thinking about requirements management.  What the bleep is that?   There’s an “a-ha moment” that comes when they realize the secret to innovation is managing requirements effectively.  The devil is in the details (requirements).  It’s worth the investment to get them right.

requirements_management_aberdeen_report

The key findings show that requirements management is critical to the successful development of today’s modern products.  Companies must be able to:

  • Manage product requirements throughout the development lifecycle
  • Provide visibility into requirements and their status to the entire product development team
  • Be able to truly evaluate the impact of changes on both the requirements and the design

Companies that achieve these core RM capabilities will be more efficient, see lower costs, and become more profitable with products that are in high demand from customers.

The report also includes a case study on IntraPace, the medical devices company, who is using Jama Contour to streamline their requirements management process and specification needs for meeting FDA compliance standards.

“Contour is now the best tool in our arsenal of design tools.” – Mace Volzing, manager of software development, IntraPace

After reading the report, if you want to give Contour a try, you can download a free trial with unlimited users here.  Let’s build great products.

Requirements management meets Agile development – best of both worlds.

Monday, December 14th, 2009

Want to adopt more lightweight agile methods for software development?  But you can’t throw the book out and go pure Agile, because your company needs to maintain proper requirements management practices for product planning, requirements traceability, requirements specification documents and tight change control.  No worries.  The JIRA Connector for Contour brings these two worlds together, by connecting business teams responsible for product requirements and planning with development teams responsible for implementation.

frank_hero

The JIRA Connector for Contour has been selected as Atlassian’s Plugin of the Month for December.  Join Frank Charron, Jama’s development manager, and watch the recorded webinar on how to succeed with proper requirements management on the product planning side of the house, while providing the developers and QA testers the freedom to work within JIRA for agile project management, tasks and defect tracking.

This hybrid approach is proving to be very successful for many organizations, especially those in industries such as medical devices and aerospace where requirements management is critical to meeting compliance standards.

Watch the webinar on Atlassian TV >

Demystify requirements traceability – 5 tips for connecting everything and everyone together.

Friday, December 4th, 2009

What is requirements traceability?  Why is it important?  What are the benefits?  Requirements traceability helps you stay connected, manage change and improve quality.  Learn how to master it with these resources.

Requirements Traceability Resources

Born out of disciplined systems engineering practices, traceability can sound technical and complex, but it doesn’t have to be.  For specific industries such as aerospace or medical devices, traceability is mandated to meet specific compliance regulations.  Regardless of your process and industry, if your team is building sophisticated products, traceability could very well be your ticket to better results.  In fact companies with mature requirements management and traceability practice achieve 75% higher success rates.

What you’ll learn:

  • Demystify traceability, impact analysis and related concepts
  • Get 5 practical tips on how to put traceability into action
  • Learn how to automate the process using Contour to save time & improve quality

Download the new requirements traceability whitepaper from Jama Software and get other requirements resources all in one place.  Let’s build great products.

System Engineering: Top Design Tips to Increase Profit Margins & Speed Development

Thursday, November 12th, 2009

The Aberdeen Group today released an independent research study conducted by Michelle Boucher, product innovation and engineering analyst, that examined the best practices of companies building smart products.   The 27-page report summarizes the results of a detailed survey conducted with over 150 organizations early this year. The report, co-sponsored by Jama Software and IBM, reveals the leading strategies for system design that lead to greater profitability while reducing the risk of excess cost.

“Requirements should be linked to higher level system functions as well as to the overall customer need it meets.”

The paper is title, “System Engineering: Top 4 Design Tips to Increase Profit Margins for Mechatronics and Smart Products“, but has broader impact and value to any company building products with complex requirements that can change during the development process.  The research finds that what is making the difference for successful companies is how they:

  • Capture what their customers want
  • Manage those requirements effectively throughout the product lifecycle
  • Take advantage of system engineering best practices

The key findings of the report demonstrate the financial gains and overall value that requirements management and system engineering best practices deliver to enterprise organizations.  Best-in-Class companies:

  • Earn 2x higher profit margins
  • Achieve 6x faster development cycles
  • Meet product launch deadlines 20% more often

Request a complimentary copy of the complete report from Aberdeen’s web site.  To put these industry best practices into action, explore Jama Contour.

What’s it mean to be a beloved product?

Friday, September 25th, 2009

We were brainstorming the other day around this concept of “beloved products” and how few of them there really are.  Being a visual person, I had this image of Maslov’s hierarchy of needs in my head and was curious to map out a similar hierarchy but in the context of customer satisfaction and the different levels of belovedness (there’s a new buzzword).  This was what I came up with.  Click on the image for .pdf version.

Are your products beloved? Where do you fit on the hierarchy?


Explanation of the different levels:

Level 0 – Failure: At the baseline, you’re just trying to avoid joining the crowded graveyard of failed projects and products that companies waste billions on.  Think Microsoft Bob or Pontiac Aztec. This is where 60%+ of development projects & new products get buried.

Level 1 – Functional: At this level, the simple question is, “Does it work?”.  Functionally, when the engineers can answer “yes”, they mean it’s met the basic set of functional requirements and it’s considered OK to launch.   However, the reality is in most competitive markets, OK doesn’t cut it with customers.  The “Sure, it works…kinda…” is quickly followed by a “BUT…”  But, it’s too slow.  But, it’s clunky.  But, it’s way too complicated.  But this, but that.  To advance to the next level, you need to reach the “No Buts” zone (don’t get cheeky)  – it needs to be a product that’s functional AND user-friendly.

Level 2 – Useful: This tier is where good products hang out.  It’s where usability and information architecture make their home.  As the last decade has proven out, companies can be extremely successful building good products that people find useful.  Think Craigslist, it’s ugly as sin, but millions find it extremely simple and useful every day to sell junk, swap houses, find employees and services.  As a parent of 3 little ones, can’t tell how much baby gear we’ve bought and sold on Craiglist, it’s genius for that.  As a business, you could stop right there, your product is good.  But it isn’t great.  It’s missing a strong emotional appeal – it doesn’t evoke belovedness (the word is growing on you, isn’t it?)

Level 3 – Beloved: Now, this is where magic happens.  Loyalty is earned.  People rave about your product to others.  There’s an emotional connection to it that customers feel and they can’t live without it.

Is reaching this level the appropriate goal for every product? Do you need to build a beloved (great) product to have it be considered a success?  It’s probably not realistic and maybe not even necessary for many markets.  As Seth Godin pointed out a few months ago on his blog, smart marketers at Apple strive to build products people love, smart marketers at American Airlines ought to just work on building an airline that isn’t annoying.  I’d fly Annoyance Free Airlines.  Sign me up for that frequent flyer program.  Do they offer non-stops flights in/out of PDX?

The point is that it depends on the market, the status quo, the other competitive options available and the complexity of the problem you’re trying to solve.  Customers have different levels of tolerance for different things.  Often it’s more about the expectations set by a company.  If you promise great, then I expect great.  If you promise not to suck, then I’ll be delighted with something that’s just useful.

AT&T’s had a recent campaign that was based on this type of scenario in wireless service.  They promised you, “the fewest dropped calls.”  Essentially saying, our promise to you is that “we suck less” than the competition.  And, in fact in the market of wireless coverage, that would be enough to win, except that in their case the message didn’t match the product experience because people experience dropped calls, a lot of them, so AT&T dropped the campaign (pun intended).  Oops, sorry… did we mention we’re 3G now, or is it 4G?  who cares, just work.

No one said building a beloved (great) product was easy.  Which is why we all ooh and aah so much when it’s actually achieved.  And, even then it’s not perfect.  Like millions of other raving fans, I love my iPhone.  Love it.  Addicted to it.  But, I hate the battery life, which is insignificant.  Because of all it’s features, apps and simple UI that I love, I can easily tolerate charging it 2x per day.  It’s a small inconvenience to pay for all it’s other genius conveniences.  Even a beloved product has room for improvement.  A product, especially one involving technology and software, are never done.  It’s always evolving.  Now, if Apple nails the battery situation like they have video, voicemail, music, photos and everything else, we’ll have to create a new level 4 beyond Beloved… maybe Epic or Iconic or Supergalatic?

Innovation in Action: 5 reasons why a central hub of product intelligence speeds productivity.

Tuesday, September 15th, 2009

In the world of product development and specifically requirements management, you hear a lot about building a “central repository of requirements” or a “single system of record”.  But, why does that matter?  What problem does that solve?  What’s the real value in creating a central hub of product intelligence?

First, let’s define central hub of product intelligence.  What are we really talking about?  Naturally, we think of the data (a.k.a. artifacts or items) – the ideas, feature requests, requirements, design specifications, analysis documents and reports, release plans,  defects etc. – all the data that explains the scope of the product the team is building.  The difference in why we use the word “intelligence” instead of data is that product intelligence expands beyond the artifacts.  It also includes 2 other important related categories of information that support the social nature of the product development process.

  • Conversations – There is an ongoing dialogue throughout the product development lifecycle.  Customers provide feedback.  Analysts capture insights.  Teams discuss requirements.  Managers communicate decisions.  Organizations make commitments.  By including the conversations in context to the requirements and other data, your team will have the complete story of what customers need and understand the discussion for how your team arrived at the requirements you have.  The context is huge.  Without context, you have higher risk for misinterpretation and defects later on.
  • Relationships – Often referred to as traceability (the upstream and downstream relationships between requirements and other items) – the links between the data and the people who own the data are important for understanding all the dependencies and creating a dynamic environment where you can intelligently manage and communicate changes when they occur.  As a practical example, for developers working on detailed functional requirements, having the visibility to look upstream to the high-level business requirements and original feedback from the customer is huge in proving them full context to what they’re on the hook to build.

Why This Matters:

There’s many reasons, but let’s look at these top 5.

1.  Information silos kill productivity – 42% of employees accidentally use the wrong information at least once a week.

2.  Employees and information are fluid – they flow in and out of teams and projects constantly – what info gets lost in transition?

3.  Employees spend 25% of their time just looking for information.

4.  Employees waste 20 minutes a day or more recreating information that already exists.

5.  The total information we’re inundated with grows 66% every year, so this problem will only get bigger over time.

It’s estimated that employees at U.S. companies waste over 5 billion unproductive hours annually just looking for information. – Searching Kills Employee Productivity Blog

It’s such a simple concept – capture all the relevant product intelligence in one place.  Wow, that’s a breakthrough idea, right?  The reality is that it’s difficult to eliminate this problem completely – it affects every organization on some level.  We’ve worked at start-ups with 10 people in the same office and Fortune 100 companies with 75,000+ employees worldwide, and it exists at both.  The question isn’t whether it’s an issue in your company.  The more important question is, “What’s the full impact it’s having o your team and their productivity, and could a better solution make a significant difference?”

Solutions range from using back of the napkin/whiteboard to Word/Excel documents to Wikis to specialized requirements management software.  You may use them all, we do.  The solutions you choose will depend on your organization and the complexity of products you’re building.  One of the decision criteria to use to gauge whether you need specialized software is to determine what degree your team suffers from the Silo Effect.  Borrowing from the infamous Cosmopolitan quiz style, use the list of questions below to determine whether your team is at risk.

Take the Silo Effect Quiz:

[Yes]   [No]  – Do you have duplicated sources of data and multiple versions of requirements spreading across your organization like the Swine flu?

[Yes]   [No]  – Do you have departments that are disconnected and unaware of what the other is doing?  Is the right hand talking to the left hand?  Be honest.

[Yes]   [No]  – Do you operate in an industry with compliance standards, where detailed version history and specific requirements documentation are required for approvals?

[Yes]   [No]  – Do you spend more than 20% of your time hunting around for the latest product information and requirements specs?

[Yes]   [No]  – Is visibility into the product development process limited for stakeholders?  Hint:  if you’ve heard or use the term “black box” in a meeting recently, then mark “yes”.

[Yes]   [No]  – Do you have communication gaps or blind spots related to customer commitments, feature requests or other insights into what your customers need?

[Yes]   [No]  – Do you have frequent transitions of staff in and out of product teams?

[Yes]   [No]  – Do your business analysts match the 27 points of compatibility with your engineers?  Sorry, ignore this one.  We got carried away by the style of these quizzes.

In all seriousness, if you answer “yes” to 2 or more of first 7 questions above, then it’s probably time to evaluate other options to help you eliminate the silos and bring it all together into a central hub that’s accessible, searchable and reportable.

The Productivity Gains from Eliminating the Silo Effect:

  • Save time and money that’s wasted searching for information
  • Reduce costly guesswork, rework and related defects
  • Eliminate redundant research and duplicate projects
  • Shorten ramp-up time of new employees to the team
  • Give complete context to the goals and scope to everyone involved

Keep in mind, having a central hub of product intelligence isn’t the end-all-be-all solution for fueling innovation.  It’s just one capability in a list of many that are required to successfully plan and build products that work.  If you have a broken development process, a central hub won’t solve that.  If your team doesn’t have the right skill sets, it won’t fix that either.  However, what we’ve found over the years is that of the myriad of challenges we face managing product development, bringing all the relevant product intelligence together in a central hub is one of the immediate and practical steps an organization can achieve right away to speed productivity, reduce costs and improve quality.

Moment of Zen:  Sometimes the first step is the most valuable one to take.

Learn more:

See how other companies have benefited from using requirements management software to build their central hub of product intelligence.  Read their stories >

Based on the requirements maturity of your organization and how you scored on the Silo Effect quiz, if you’re in need of a better solution, you may want to  check-out Contour as an option >

Capturing the RIGHT product requirements isn’t child’s play…but should it be?

Tuesday, August 25th, 2009

What are the real problems you’re solving for your customers?  Which features will entice customers to enthusiastically buy your product?  Do the ideas being discussed in your online forum match your company’s DNA and product strategy?

These are questions that many people in our industry work, and work, and work, really hard to solve every day.  But, maybe more work (as we normally think about it) isn’t the answer.  Maybe it’s time to play.  Seriously.  Skip the urge to round up the whole team in a stuffy meeting to debate it out, the next time you have uncertainty on your product plans.  Bring in some Legos, take your team outside to play a game or experiment with a few of the creative techniques that others are using to spark new insights, prioritize features and elicit the right requirements.  There’s tons of research on the study of how children learn through play – how it sparks creativity and enhances problem solving skills.  Yet, in the corporate environment, play isn’t a norm.  But, that may be changing.

Think this sounds crazy or too ethereal?  Maybe…maybe not.  Skepticism is understandable, but there are some very smart people at some very successful organizations challenging the myth that play and work don’t belong together.  In fact, they’ll tell you just the opposite, and they have plenty of research and success stories to back it up.  They suggest you should encourage collaborative play at work, and that specific to product development, it can make all the difference between creating the right product or missing the boat completely.  Undoubtedly, one of the toughest challenges of innovation is accurately understanding what customers really want, need and value most (translation:  what they’ll gladly pay you for).  Even when you ask customers, they often struggle to clearly articulate their needs.  So, what do you do?

My goal of this article is provide you 2 groups of links – the first is a list of books and resources with creative techniques to inspire innovation; the other includes resources for mastering requirements fundamentals.  This summary of resources is the intellectual capital of others based on their many years of experience and expertise.  As a point of disclosure, Jama has no financial interest in these resources – so the purchase of books, training courses, etc. have no impact on me or Jama.  The resources I highlight are ones I read, and I respect their content.  This article intentionally excludes software tools (sorry sales team and partners), I wanted it to focus on educational resources.  I obviously believe in the value of tools, but we won’t cover that here.  Since time is a real constraint for all of us, I’ve invested 10 hours pulling together this list – so you only have to spend 10 minutes to learn about them.

Creative Techniques for Sparking Ideas and Uncovering the Unspoken Customer Needs

Resources for Mastering Requirements Fundamentals

In summary, whether you use these resources or others, there’s 5 things that I’ve learned to be true over the years:

1.  There is no silver bullet technique for magically eliciting requirements.  You have to test different techniques, try different interview questions and learn which combination works best for each situation and audience.  And, it will change from project to project.

2.  Customers know what they like and what frustrates them, but they don’t know how to perfectly articulate their needs.  That’s your job to figure out.  You can ask direct questions, but usually the “a-ha” occurs during more authentic conversations and your observation of the unspoken problems they’re experiencing.

3.  Not to be dramatic, but the stakes are high.  The difference between getting requirements right or wrong can make or break your business.  No amount of beautiful design or agile engineering will compensate for the fact that you aren’t solving a real problem customers care about.

4.  The task of understanding the needs of your customers and capturing their collective voice isn’t owned by one person.  It’s a shared responsibility and its valuable to have a high level of collaboration continue throughout process.

5. When work is enjoyable, people perform better.  Thus, there’s merit in having the lines between work and play blurred.  It’s not a coincidence that some of the most successful and innovative companies in the world have high employee retention, fun corporate cultures and loyal customers who love the products they build.  That isn’t by luck, it takes work to have work feel like play.  Enjoy the journey.

For it to flourish, innovation’s future lies in a less disjointed approach – we’re already seeing signs of it becoming more holistic and collaborative.”  – Tim Hulme, business strategist at IDEO and author of The Future of Innovation

I’m sure I’m missing some really valuable resources, so please let me know others you’d like to share, post a comment here or email me.  Thanks to those who shared their insights and resources with me earlier to include in the article.  Feel overwhelmed by the list?  Just commit to trying one new technique this month and take it from there.  Let’s build great products.

For customer success stories, visit: http://www.jamasoftware.com/customers
For more info on Jama, visit: http://www.jamasoftware.com

State of Requirements Management Webinar Wrap-Up

Thursday, April 16th, 2009

Thanks to everyone who tuned into the webinar last week that we co-presented with Ravenflow.  If you missed the event, here’s links to the content below.

To view and download the slides on Slideshare:

To download the presentation as .pdf

To download the full report as .pdf

To watch the replay via Microsoft Media Player (requires v9 or higher)

During the presentation we took a few live polls and I’ve compiled the data in our Daytum account, you can view the stats on how topics such as:

  • How often teams elicit requirements from their customers – 38% said only at the start of a project.
  • Is change management an issue for your team? – 83% said yes.
  • Is  your team in sync on how you measure success? – 70% said no.
  • Which development process do you use? – 57% said they aren’t purists and use a mix.

Requirements Management Q&A: Insights from Rob Beckmann, editor of Requirements Networking Group

Thursday, April 2nd, 2009

Continuing our series of interviews with industry experts, I recently chatted with Rob Beckmann, the co-founder and editor of Requirements Networking Group, aka RQNG.

Requirements Networking Group

Jama: Rob, how long have you been educating folks on the best practices of requirements management?

Rob: I have over 30 years experience in the IT field in various roles.  At Caro Systems Inc., my focus during the last 10 years has been on the business architecture and requirements management challenges of our clients.  I have advised and mentored on business architecture, requirements management and elicitation, and development methodology.  Over the years, we developed some best practices that we share with our clients.

Jama: During that time, which aspects of the software development process have you seen evolve over the years and which aspects have remained constant?

Rob: “The more things change, the more they stay the same”.  I’m not sure who originally penned that phrase but it is certainly true in this case.  Back in the latter half of the twentieth century some of the smarter people I had the priviledge of working with were employing concepts that we would attribute today to Unified Process and Agile methodologies – we just didn’t call it that back then.  The more prescient among us drove projects with the notion of delivering incrementally and frequently – in order to maintain interest and elicit feedback from the business community as early and as often as possible.

What has really changed over the years has been the growing recognition that this is a better approach, but we still see a lot of software development relying on a Waterfall methodology.  Organizations that make an effort to adopt a UP or Agile approach will often fall into the waterfall trap and focus on one discipline or skill (usually requirements, in the early adoption phase) versus applying the approach to all disciplines and ensuring their teams deliver real working software in short iterations.  Organizations definitely have their challenges adopting such an approach, the biggest being their social and corporate cultural concerns.

Jama: What compelled you to start the Requirements Networking Group (RQNG)?  What problem did you see that the community web site helps address?

Rob: Studies such as the Chaos Report by the Standish Group certainly made the case that the root cause of many software development projects can be laid at the feet of poor requirements.  We were also especially struck by the lack of consistency and varying quality of expressed requirements from various organizations.  Each organization also had their own definition for the “business analyst” role and the skills needed in order to perform that role.  This got us thinking about establishing an online forum where ideas could be shared and provide people with access to information and guidance.  In July 2006, we launched the Requirements Networking Group  in partnership with Richard Matthews of iONGs.  Since that time, we have attracted nearly 12,000 members and the response has been exciting – exceeding all our expectations.

Jama: If you had one fundamental tip to provide people, what would it be?

Rob: Active participation from stakeholders in a project is key to that project’s success.  It won’t guarantee success, but without it I can guarantee it will fall far short of what it should achieve or simply fail.  Every project that I have been part of that has been acclaimed a great success has always enjoyed the active participation of one or two well respected individuals who could represent the stakeholder community and clearly express a vision for the software product under development.  These people were committed, worked with the project team on a day-to-day basis and took ownership of the system.  So, my tip would be to find the one or two people in your organization who are likely to be the most unavailable to you because they are so knowledgeable, well-respected and in high demand – and convince your management that they are critical to your project’s success.

Jama: What’s your perspective on the role of requirements management for organizations adopting newer Agile development methodologies?

Rob: A project organized along agile lines is geared to delivering functionality in very short cycles so that immediate and frequent feedback on the functioning system can be received and cycled through future iterations of the software product.  This is very different from traditional waterfall approaches. Instead of “completely” documenting all the requirements up front before any analysis, design or coding effort takes place, the requirements will also evolve into more concrete needs as the development sprints execute.

The activities to express the detailed requirements must be planned to ensure they mesh with the sprints that will build to them.  Feedback from prior sprints must also be taken into consideration to ensure important features are addressed at the appropriate time.  This also impacts other activities, such as testing, to ensure they are planned in accordance with feature delivery.

Jama: Bonus question – If you were stranded on an island and had only 1 album with you, which would it be?

Rob: I like many genres of music (I’m even starting to develop a taste for classical music!) but I am especially partial to the blues so I would have to say a good anthology mix of Muddy Waters’ music would be my choice.

Jama: Thanks Rob for taking time away from your busy schedule to share your thoughts with us.

© 2007-2010 Jama Software. All rights reserved.       Contact Us  |  Privacy  |  Sitemap  |  Preferences  |  Enjoy the Journey