Posts Tagged ‘Project Management’

Contour 2.9.5 is here. See the new features to help you control scope and manage change.

Thursday, March 11th, 2010

The key enhancements in Contour 2.9.5 are designed to help teams stay connected while effectively controlling scope, managing changes and tracking approvals.

New features include:

  • Baselines – The most flexible baselining feature available on the market
  • Electronic Signatures – Capture approvals to help with compliance standards
  • Change Requests – Track versions of items within change requests
  • Inline Editing – Quickly edit items from a single view to save time
  • Permissions – Enhanced management of users, groups & permissions

See what’s new and watch the videos on the new features >

Special thanks to our growing customer community for all your great insights, you drive our product roadmap. Let’s build great products!

Let’s innovate! See the new Activity Stream in Contour 2.8. It’s requirements management software for everyone.

Thursday, September 24th, 2009

Which image best describes your current product planning and development process.  Is your team jammed up all the time?  Or are you working in fluid motion?

Is your team working in fluid motion?

Jama, the leader in requirements management software for product innovation, today announced the availability of Contour 2.8 with the new Activity Stream.

Keep a pulse on all the activities in your projects and stay connected.

What’s been added to the scope?  Which features are complete and fully tested?  Are there new bugs?  What’s everyone working on today for the upcoming release?  Now you can keep a real-time pulse on all the activities in your projects  within a single view.  No more noise.  No more hunting.  No more surprise.  It’s everyone in sync, working on what matters most.  It’s product planning and development working in fluid motion.  And, it’s available now in the new Contour 2.8.  See what’s new and watch the quick 2-minute video on the Activity Stream.

Other highlights in the new Contour 2.8:

  • Active Search:  Find exactly what you need at the moment you need it.
  • Enhanced Import:  Import requirements along with the headings, formatting and images straight from MS Word (.docx).
  • Reading View:  Work with a set of requirements or list of items in a dynamic Word-like reading pane within Contour.
  • Web Services API v2:  Build your own integrations or have Jama do it for you.  Contour is open for business.

See What’s New in Contour 2.8 >

Note:  Contour On-Demand customers, your hosted accounts are automatically upgraded.  Enjoy the new features the next time you login.

Special thanks to our customers and partners!

Thank you  for making Jama a leader in requirements management and social product development.  Thousands of users worldwide managing billions in R&D projects trust their requirements to Jama Contour.  We appreciate all the great insights, you drive our product roadmap.  Let us know what you think of the new release.  Let’s build great products!

Read customer success stories >
New to Contour? Download a free trial and take control of your requirements >
Follow Jama on Twitter >

Fueling innovation through collaboration. Contour v2.6 is here.

Thursday, May 28th, 2009

We’re pleased to announce the availability of Contour v2.6, the collaborative way to succeed with requirements management.  We continue to enhance Contour to provide unmatched flexibility, customization and ease of use for global teams that are building sophisticated products and systems.

This new release centered around three key themes:

  • Custom Reports – Output requirements and other related data into true Micrososft Word format, and run context-sensitive reports on the fly.
  • Release Management – Customize what’s viewable in your product releases and include downstream relationships for enhanced requirements traceability.
  • User Experience – Cleaner design, enhanced customization of layouts and improved email notifications

A special thanks to our growing customer community for your valuable feedback on the enhancements we’ve made to Contour.  You drive our product roadmap.  See what’s new >

Jama Contour can easily scale to thousands of users and geographically distributed teams.  Experience for yourself how it can help your entire organization capture, connect, control and collaborate on requirements like never before.  Take Contour for a trial run >

Join Jama and Ravenflow for “The State of Requirements Managment” Webinar on April 7th

Thursday, April 2nd, 2009

Join Ravenflow and Jama Software on Tuesday, April 7th at 10am PDT for the upcoming 30-minute webinar on “The State of Requirements Management” and see the latest trends in software product development.  Click the image to learn more and register.

State of Requirements Management Webinar
State of Requirements Management Webinar

The webinar is based on the findings of the State of Requirements Management survey that Jama and Ravenflow conducted with over 200 professionals last year.  Topics include:

  • What are the biggest innovation challenges companies face?
  • Where are companies getting their next great products ideas?
  • What are the top barriers to success for managing requirements?
  • Which metrics matter most when measuring success?
  • What frustrates people more – scope creep, unrealistic expectations or lack of testing?

Attend the webinar and receive a copy of the latest State of Requirements Management Report.  Then as a follow-up, you will be invited to participate in the upcoming 2009 survey to gauge how things have changed over the past 12 months – from the impact of the economy to the adoption of Agile techniques.

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.

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.

Requirements Management Q&A: An interview with James and Suzanne Robertson

Monday, March 23rd, 2009

Recently we had the opportunity to chat with James and Suzanne Robertson, requirements best practices consultants with Atlantic Systems Guild and authors of “Mastering the Requirements Process”. We appreciate them providing the following insights about the requirements management process.

James & Suzanne Robertson

Jama: How long have you been advising and teaching organizations together on the best practices of requirements definition and management?

James & Suzanne: This is almost an embarrassing question. It has been about 30 years that we have been involved in requirements. This has taken place over most of the continents, and has been extremely satisfying for us.

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

James & Suzanne: Sadly, we have seen more fashionable comings and going rather than steady evolution. It seems that each advance in the field throws out most of what we have learned and starts over. For example, it is still hard to get people to think about the client’s business and understand that before specifying the software/hardware to improve it. One pleasing aspect that has evolved is the awareness of the need for requirements. This has resulted in the involvement of a broader range of stakeholders – the users are no longer the sole specifiers of requirements. Another pleasing aspect is that the requirements people are finally beginning to learn from other fields. For example, we make use of ideas from marketing, engineering, sociology and so on. We recently spent time with Rob Austen who in heavily involved in theatre. We have also had chefs and textile experts involved in our innovation workshops.

Jama: What compelled you to write the book “Mastering the Requirements Process”? What problem did you see that the book addresses?

James & Suzanne:The book is now in its second edition. We wrote the first edition because we wanted to have one book to provide practitioners with a solid grounding in requirements gathering. We wrote about a framework for gathering requirements, one that we had used and saw success with over the years. We felt that business analysts needed something that was based on real-world experience, and was readable enough that they didn’t get bored while getting its message. We also tried to link all the scattered pieces of the requirements puzzle. For example, we found ways of discovering and involving stakeholders and connecting them to both the high-level goals and the low-level, atomic requirements. We connected the requirements to testing by using a fit criterion hereby the requirement is made measurable. We tried to reuse whatever knowledge existed and was useful (standing on the shoulders of giants), and invented only where there was a gap in the existing body of knowledge.

We tried to provide enough formality so that all the participants in the requirements process are aware of what they need to produce and why they are producing it. By giving people this structure, we wanted practitioners to make their own decisions as to where they spend their time most profitably. In other words, instead of following a fixed process step by step, the practitioner can understand what activities give the greatest value to his/her requirements effort.

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

James & Suzanne: Understand the client’s business – really understand it. Never mind the software. If you don’t understand what the client is trying to achieve with the business, then you cannot build useful software/ hardware.

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

James & Suzanne: The desire to be more agile is one that any system development team should have. The biggest single problem is that people sometimes translate “agile” to mean “unconstrained” or worse, “hacking”. On the other hand, the best implementations we have seen of SCRUM is where the team had a fairly thorough requirements and business goal orientation session before starting their sprints, and a requirements review and (where necessary update) as part of each iteration. Agile methods work well provided you keep in mind that you are building software to make the client’s business better. That sometimes gets forgotten with the emphasis on feature-oriented user stories. Clients don’t need features, they need software to make their work easier or more productive.

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

James: I would love to take one of my favourite jazz albums, or something by Pink Floyd, but practicalities say that it would have to be an opera to get the extra duration of the music. I would go for Mozart’s “Marriage of Figaro”. I suspect that Suzanne would ask for the entirety of Wagner’s Ring Cycle.

7 Essential Tips to Ensure Success with Requirements Management.

Tuesday, March 17th, 2009

As fast as things change in the software development world, it’s amazing how the fundamentals stay true to form.

Innovate or die.  Go Agile or die.  How about just get the freakin’ requirements right or die!  That might be a more accurate perspective that many development managers are taking today.  Especially during this tough economy, taking a “back to basics” approach can prove to be a good strategy.

Recently, we had an opportunity to speak with a few well respected consultants in the field of requirements management, including Karl Wiegers and James and Suzanne Robertson, and we were reminded of just how important it is to nail the fundamentals of the requirements management process – from writing good requirements to managing change requests  to prioritizing new features and requirements.  Whichever product development methodology or process you’re using, it’s critical to nail the fundamentals.

Requirements Management Tips - Download Guide

Download Requirements Management Tips

To help with this effort, we put together a new whitepaper on the 7 essential tips to ensure success with requirements management, along with a few free templates you can use right away to help you with your requirements process.  For some, these tips might be new. For others, these tips will serve as a  good reminder of the fundamentals that are easy to lose sight of during the heat of a project. You can download the requirements management resources directly from our web site.   Feel free to share these with others and add links your favorite templates.

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?

Customer Needs – The tip of the iceberg.

Thursday, May 22nd, 2008

Here at Jama we take a pretty open approach to the development of Contour, our collaborative requirements management / project management software and incorporate customer feedback, input from our advisors as well as research and planning we perform internally. We often invite smart people to have lunch with us to give us feedback on our vision for Contour and insight into what would be the perfect tool to help them. We trade sandwiches for market insights.

Yesterday, Lori Schmall, COO of Grist joined us. Grist is a Seattle based on-line media company focused on the environment. Time magazine recently named Grist the top green web site.

While we like to think and act green as a company – she was quick to point out a few plastic water bottles scattered around the conference room – I think we’ve got some work to do.  Lori’s past life was in senior management at a Fortune 500 technology firm dealing with scenarios that are near and dear to our heart – enterprise product development and project management.

We focused first on our sales presentation.  We’re constantly refining it to better speak to the value of our product, keep the flow engaging and eliminate the bullet points (we believe in a bullet point free world). This reminded me I need to revisit http://www.presentationzen.com/.

Our takeaways from this discussion:

  • Get the audience involved as quickly as possible. This helps keep everyone focused and involved in the presentation
  • Use stories to illustrate points, it’s much more interesting for everyone
  • A little humor never hurts, we all can relate to funny scenarios that we live through

We then turned to the pain of project management. Lori offered up a nice, simplified definition of requirements management: “Delivering what the customer wants”.  This speaks to the broader set of functionality that’s available within Contour.

For Lori, the #1 one pain point is when the team loses sight of what’s important to the customer.  On long, complex projects when things change, it’s easy to get disconnected from what the stakeholders are expecting.  She gave a great metaphor. It’s like an iceberg – the customer defines what they want, but it’s just the visible tip of the iceberg. The development team then has to create and manage through the supporting structure underneath the surface – the mammoth, complicated task of defining use cases, tasks, coding, testing, documenting, deploying to get to the end result of what the customer wants.

The key themes were:

  • Visibility into the project – understanding what the status is at all times and who’s doing what
  • Alignment – keeping everyone on the same page.

Continuing the metaphor, these strategy sessions with outside executives help us come up for air once and awhile, and keep us focused on the big picture of the value we deliver to customers.  Thanks Lori for your time.

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