Posts Tagged ‘business analyst’

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 >

Tags: , , , , , , , , , , , , , , ,
Posted in Company, Industry News & Trends | No Comments »

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.

Tags: , , , , , , , , ,
Posted in Industry News & Trends | No Comments »

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 >

Tags: , , , , , , , , , ,
Posted in Industry News & Trends | No Comments »

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

Tags: , , , , , , , , , , , ,
Posted in Industry News & Trends | No Comments »

Requirements Management Q&A: An Interview with Laura Brandau, editor of Bridging the Gap blog.

Monday, March 30th, 2009

Continuing our series of industry perspectives, I recently chatted with Laura Brandau, an experience Business Analyst and editor of Bridging the Gap blog.

Jama: Laura, how long have you been advising organizations on the best practices of requirements management?

Laura: I have been involved in various aspects eliciting, defining, reviewing and verifying software requirements for the last 7 years and established business analysis practices in two organizations over the last 4 years.  As a BA consultant, I’m always looking to help organizations improve the value delivered by technology solutions and a core competency is getting the requirements right.

laura_bridging_the_gap

Jama: During your experience, which aspects of the software development process have you seen evolve over time and which aspects have remainded constant?

Laura: What has remained constant is the core challenge of bridging communications between business and technology teams.  Individuals on both sides tend to have very different perceptions about what success means and how to get there.  The best software development teams engage the business in understanding what they want and need and are proactive in offering up solutions.  The best business teams are clear with their requests, communicate how they perceive value and are open to alternatives.  In successful organizations there are some powerful communicators (project managers, product managers, business analysts, architects, technology managers and the like) facilitating this level of communication.

What has changed, at least in my experience, is the delivery mechanism for requirements.  We are seeing things shift from large, difficult-to-consume requirements specification documents to smaller components, such as use cases and user stories.  Another significant change is in the proliferation of available tools and services.  When it comes to smaller projects, organizations are much less likely to invest in building software applications from scratch than they were a few years ago.  The cost of building versus the value of buying or leasing is tipping.  This changes software development cycles, especially the requirements process, significantly.

Jama: What compelled you to start your Bridging the Gap blog?  What specific gap did you see between IT and business that needed to be addressed?

Laura: I am passionate about being a business analyst and wanted to make a contribution to the profession by sharing my experience and perspective.  The gap I saw was that our profession focused more on process and deliverables and less on the proactive communication, leadership skills and professional talents necessary to achieve valuable results through technology projects.  BAs can and should be leaders in their organizations by helping the business understand what they want and need, and facilitating the delivery of the best possible solutions.  To achieve this level of business architecture/analysis, emphasis needs to be on the partnership and collaboration over and above the process.  I address these ideas in my blog by sharing my experiences and providing practical insights.

Along the way, I’ve been lucky to cross paths with many people who share many of my views and professional values.  So what started as a bit of a soap box has become a more collaborative blog.  As such, my focus with Bridging-the-Gap.com is to provide a forum for sharing perspectives.  Some tactics I’ve implemented so far are linking to relevant, topical resources and initiating a guest post program.

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

Laura: Agile represents many significant shifts in the requirements process and there are whole books written on this topic.  I’ll speak to just 2 of the core differences I have experienced.

First, requirements become fully integrated with the delivery cycle.  In traditional methodologies, requirements were specified upfront and the problem of delivering them iteratively was left to the project management and development team.  Often times, the testers felt the brunt of this problem as it was never quite clear what requirements could be tested in a given iteration.  Agile pushes this activity back to the product owner or requirements manager.  Aligning requirements with delivery eliminates questions about what “done” means and those dangling requirements at the end of a project.  But, as an organization implementing agile, recognize that you need to establish a new set of accountabilities for the person(s) in charge of requirements and that fulfilling these objectives incurs some additional overhead.  The delivery efficiencies seen by agile teams are not free.

A second fundamental challenge organizations should prepare for is maintaining a focus on value while managing requirements in a highly iterative agile cycle.  Traditional methodologies support fairly long runways for upfront definition of a product concept, project planning and requirements analysis.  In agile, emphasis naturally shifts to delivering working software in the next 2-4 weeks.  It is an understated challenge to maintain this delivery momentum and create valuable working software.  Under pressure to define requirements and make good decisions quickly for the current or upcoming sprint, it’s easy to side step the big picture planning and prioritization activities that keep us focused on value.  I’m encouraged that we’re seeing a lot more about getting the requirements right in agile within blogosphere discussions, particularly from Mike Cottmeyer’s and Dean Leffingwell’s series of posts on the product owner role.

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

Laura: It would have to be a mixed CD of sorts.  I have rather eclectic music tastes and the CD would have a bit of everything – from country to hip hop, some classic rock and roll, jazz and blues.

Jama: Thanks Laura for the insights.

Tags: , , , , ,
Posted in Industry News & Trends | 1 Comment »

Requirements Management Q&A: An Interview with Jonathan Babcock, Business Analyst

Thursday, March 26th, 2009

One of the bloggers we respect and follow in the software development community is Jonathan Babcock.  Recently, I had a chance to chat with him and get his insights on a few questions relating to requirements management, the business analyst role and his experience working with various teams and projects over the years.

jonathan_babcock_practical_analyst

Jama: Jonathan, how long have you been advising and teaching organizations on the best practices of requirements management?

Jonathan: I’ve never formally held a position of teaching organizations, but I’ve been a business analyst for several years now and have had opportunities over the course of that time to mentor Junior analysts, and especially over the past three years, to help shape some of the business analysis and requirements management processes at my current company.  Additionally, I’ve been sharing what I’ve learned via my blog for a little more than 2 years.

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

Jonathan: Probably the most obvious evolution has been the general shift in focus from the heavier, document-centric development methodologies to more agile development practices.  From a business analyst’s perspective, we’re seeing increased emphasis on requirements modeling and prototyping as an alternative – or at least a supplement – to the big document of “system shalls”.

In terms of things that have remained constant, I think we’re still seeing that not getting requirements right is a leading cause of project failure, and that lack of effective cross-team communication and collaboration is still a leading cause of not getting requirements right.

Jama: What compelled you to start your blog JonathanBabcock.com? (note: now called PracticalAnalyst.com)?  What problem or gap did you see that your blog addresses?

Jonathan: I started the blog primarily as a means to network and as a repository for lessons that I had learned.  I knew that putting my ideas out there for public consumption would drive me to make sure that first, I really believed what I was saying, and second, that I was expressing my ideas clearly.

If there’s a particular gap that I’m trying to address with my blog, it’s that while there are lots of books and other blogs of conceptual stuff out there by managers, methodologists and industry thought leaders – who have all kinds of ideas about what the analyst should do, how it should be done and where the analyst fits into methodology  “X” – there isn’t nearly as much content available for analysts by analysts.  I like to hear what’s working and what isn’t from my peers who deal with the same types of things on a daily basis, and I think lot of other BA’s feel the same way.  That’s the perspective I can provide.  I am basically trying to write the blog that I wish had been around when I first began as an analyst.

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

Jonathan: If it had to be just one, it would be to strive to satisfy ALL your customers.  As business analysts, we work with the IT delivery organization to deliver products that satisfy business needs.  That’s the obvious part.

What’s less evident, but perhaps equally important is that we also work with the business to meet the needs of the IT delivery organization (sort of a “help me to help you” scenario).  As consumers of the business analyst’s products, the designers, developers and QA folks are also very much a business analyst’s customers.

I think focusing on the consumers of our deliverables as customers gets us to the point where we acknowledge that writing a bunch of requirements statements and tossing them over the wall is not meeting the internal customer’s needs.  It drives us to the type of collaboration that results in good requirements and successful projects.

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

Jonathan: One of the key tenets of becoming more agile is learning to embrace change throughout the life of a project.  Competent and consistent requirements management is a critical factor in keeping up with and managing change.

I think agile adoption has spurred changes in requirements management tools as well.  For example, we’re beginning to see more integrated and stand-beside requirements definition tools included under the requirements management umbrella.  Because agile asks us to focus on getting working software out the door and less on exhaustive documentation, our requirements don’t always “look” the same as they have in the past in that modeling and rapid prototyping become more widely used means of requirements capture.

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

Jonathan: Hmm… that answer would probably vary from day to day.  I’m on a bit of an Irish music kick here lately, so it would come down to a greatest hits album from either U2, The Cranberries or The Corrs… and The Best of U2 (1980 – 1990) probably wins out in the end.

Jama: Thanks Jonathan for the insights.  You have to respect the music choice too, cant’ go wrong with U2.

Tags: , , , ,
Posted in Industry News & Trends | No Comments »

The State of Requirements Management Report – over 1,500 downloads and counting…

Wednesday, July 30th, 2008

What’s the link between requirements management and product innovation? Where are companies getting their next great product ideas? What are the real challenges and barriers to success? Agile, Waterfall, Iterative – which processes are teams really using?

These are a few of the questions we explored in a recent survey with product managers, project managers, business analysts, development directors and executives responsible for the planning and development of new software products and systems at their respective companies.

Download the full report, “The 2008 State of Requirements Management Report” and discover the latest trends in software product development.

A snapshot of the findings:

  • Challenges: There’s no substitute for fundamentals. The top 3 challenges to innovation were: gaining a clear understanding of customer needs, documenting all the requirements and ensuring what’s being built is what was planned.
  • Metrics: Which success metric is most important? Revenue? Buzz? Time to market? Customer satisfaction is #1 to business analysts and project managers; revenue was most important to product managers and executives. Team alignment to same goals and metrics is key.
  • Risks: Beware of scope creep. Scope creep tops the list as the #1 cause for project failure. Followed closely by “missed or poorly defined requirements” and “unrealistic schedules and expectations”.
  • Processes: There’s a lot of mojo around Agile processes, in fact we use a modified Agile process ourselves, but only 6% of organizations have shifted to being a pure Agile shop. Most organizations are using a mix of processes, so it’s important that the tools you use be flexible to work for different processes.
  • Tools: Over 80% of professionals still manually use MS Office to capture and communicate requirements using basic documents and spreadsheets. When you think about it, those are the same tools our kids use to do their homework. However, when asked which tools they plan to use or would like to use this year, Requirements Collaboration and Management tools top the list.

Join over 1,500 other professionals and download your free copy of the report.

Let us know what you think. Are the survey results surprising in anyway? Does the report validate things you already knew? How do these trends map to what you’re doing at your company?

Tags: , , , , , , , , , , , , ,
Posted in Industry News & Trends | No Comments »

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