Posts Tagged ‘Eric’

‘Tis the season of thanks.

Wednesday, December 26th, 2007

Happy holidays everyone!

On behalf of the entire Jama Software family, I’d like to simply say, Thanks.  Thanks to our customers. Thanks to our partners. Thanks to everyone who has made an impact on our business in 2007.

It’s been a great year and it’s a wonderful time to celebrate, and we’re just getting started.

It’s our core mission to help smart, innovative companies succeed by providing a more collaborative approach to requirements management. It’s what we’ve playfully dubbed: People against Project Failure, but it’s a commitment we take very seriously. From the way we build Contour to every interaction you have with our team, we want to do everything we can to help you avoid the common challenges and pitfalls that come with the management of complex projects.

We appreciate the opportunity to work with all of you and look forward to great things next year. Have a fun and safe remainder of the holiday season.

Best success in 2008!

The Jama Backstory – How We Got Started.

Sunday, September 30th, 2007

We often are asked about the history of Jama Software so I thought I’d post on how we got started…

A few years ago, after a frustrating session working with one of our clients expensive, cumbersome requirements management tools I heard the team complaining about requirements being locked away available to only a few users, the pain of installation and how difficult it was to use. I talked with other project managers and we figured there must be a better way. We wanted the benefits of a requirements management tool – but without the overhead and hassle.

Our requirements were simple enough – the tool should be 100% web-based but offer rich functionality like a desktop application, provide a depth of features for serious enterprise product development, be easy to use and affordable – just a few simple things! You can probably guess where this is going – we didn’t find the right solution so we decided to quit our jobs and build it.

On March 13th, 2006 we started designing and building the solution. That date is easy to remember as my son was born that day. I guess he didn’t see the project plan I had put together as he was a week early. One year later we launched our first product, Contour.

The company was started sharing space with a group of financial advisor’s – not a quiet place. We’ve moved 3 times as we grew and already have filled our current office. It helps that we’ve adopted virtual systems – VOIP, Web based CRM, Wiki’s, Contour for product development etc so we can just unplug and move when we need more space. We now have customers from around the world, partners in the UK, Germany and Brazil and will continue to grow the team so we’ll likely be moving again soon.

On the product side, our road map is 100% customer driven and we’ve set an aggressive release schedule with monthly updates to ensure Contour continues to deliver the most value to our customers. I invite you to help us shape the future direction of collaborative requirements management. We recently launched our community site at http://www.jamabackstage.com, so join us in the conversation.

Openness is important to our team as both a corporate philosophy in how we do business, but also as the key driver in how we build our products for our customers. We hope this transparency is apparent in every interaction you have with our team, including this blog post.

Real World – Contour

Wednesday, September 12th, 2007

I was on a sales call last week demonstrating our requirements management solution, Contour, walking through some common scenarios when the client asked if we use our tool internally. We do, and we get this question periodically – do you eat your own dog-food and the like. After I said we did, they asked if we could switch over and look at Contour in action right now. That request hadn’t come up before, but I pulled up our instance of Contour and we walked through a few scenarios with live data.

After the call I thought about the request, with everyone saying they use their own tools that was a great way to figure out if we really did or if we were full of it. I thought it also might be helpful to post a few scenarios on how we use Contour here at Jama so you don’t have to wait for a demo.

One common scenario is capturing customer suggestions from our user community and tracking it through the development lifecycle. We use Jive’s Clearspace product for our community site. It’s a great product for fostering a customer community.

User’s post a suggestion and it’s discussed…

While Clearspace is great for fostering collaboration with our user community, we need to get the new ideas into our product development cycle and track them. For now this is a manual link but from Clearspace to Contour – but we’ve got a plug in coming that will take care of this automatically. Once an idea is identified and discussed, we create a customer request artifact in Contour and link back to the original discussion. This gives the analysis and development team the requirement in context.

Anyone on the project team can access the requirement as well as the original thread in our user community. The development team has also created a related task which shows up in the relationships section.

When we deploy version 2.0 and we generate our Features by Release report, we’ll be able to see the source of the new features which enables us to credit Ryan for the enhancement to the user profile page – or close the loop with anyone who provided input.

Contour enables us to feed ideas from our users right into our product development cycle. In addition, visibility by the entire team and end to end traceability helps us get it right the first time, with minimal overhead as fast as possible.

REG Developer ALM Interview

Saturday, August 18th, 2007

David Norfolk of Reg Dev recently interviewed Barry Gilbert from Xeau, our European distributor of Contour.

They discuss the benefits and challenges of ALM, the need for lightweight tools and how MS office is often the default requirements management tool.

The full article is posted at http://www.regdeveloper.co.uk/2007/08/11/barry_gilbert_xeau/.

Top Customer Benefits of Contour

Tuesday, April 24th, 2007

While Contour is relatively new – we just released this year, it’s already gained significant traction in the requirements management space. We’ve heard quite a bit from our customers about the benefits they are seeing. What is especially interesting to us are the benefits customers experience that we didn’t anticipate. It’s great to see that our vision of an easy to use but functionally solution is making life easier for real world software teams.

I’ll be posting on these benefits over the next few days…

1. Project Teams that Truly Understand Project Objectives

We’ve been told that the immediate benefit to using Contour is the entire team gets in sync with the project. As the team starts entering requirements into a shared repository that’s visible across all project roles great discussions start taking place. People have told us that these early discussion and clarification are helping create a better, broader understanding of key requirements and reduce confusion and mistakes later in the project. We’re often told how costly mistakes are to fix once code has been written, or a product released so it’s great to see these caught early in an iteration when it’s just a text change.

2. Find Stuff Fast

One of the biggest pains in large software projects is the number of artifacts and “stuff” created by the project team. Requirements, design documents, notes, test cases, research, story cards can quickly become a nightmare to organize. Project teams are using Contour as the central hub of the project, using Contour to store not only project requirements, but all types of project artifacts. Some teams store items as attachments, others link to items in Wiki’s, Intranets and document management systems. The benefit comes from creating relationship links between items. Users can immediately see how the item they are working on relates back to high level requirements as well as other project artifacts – and access those items with a click.

More to come…

European Launch Update

Monday, April 23rd, 2007

castle

I just returned yesterday from our European launch of Contour which overall was a great experience and am a bit jetlagged at the moment. We traveled through 5 countries, met with prospective customers and did a whirlwind press tour in London. Articles are just starting to appear this week and we’ll post links as they are published. It seems that there is a big gap in the requirements managements space for a usable, web-based product.

Overall our message of the benefits of usability, collaboration and open architectures was well received. Everyone we spoke with understood the benefits of requirements management understood the problems trying to managing software project with email and spreadsheets.

Xeau (www.xeau.com) who is the distributor for Contour in Europe did a fantastic job of coordinating the launch and getting the press involved. We look forward to a great relationship and are in the process of kicking off a number of projects with European companies using Contour.

RM Book

We had our own “roaming Nome” as Karl Wiegers “Software Requirements” very big and very heavy book got stuck in our laptop bag somehow – Kevin thought that was a heavy laptop :) . Here it is arriving in the baggage carousel in Frankfurt Germany.

Jama Welcomes Kevin Thomson

Thursday, March 29th, 2007

This post is overdue by many months, but we are excited to have Kevin Thomson join us as our  Director of Sales.

Kevin comes to Jama with 12 years of technology sales experience.  Most recently, Kevin spent six years at WebTrends, Inc., a web analytics software provider leading a team of 10.  During that time, Kevin held positions as Senior Account Manager and Sales Manager.  Prior to that, Kevin spent four years as a Senior Territory Manager with Tut Systems, Inc., a maker of carrier-class end-to-end digital video encoding, processing and distribution products. 

Kevin graduated from Oregon State University with a BS in Political Science and knows more than the rest of us combined about world history.

Welcome Aboard! (Belatedly)

Jama Headed to Europe

Wednesday, March 21st, 2007

A few of us from Jama will be headed to Europe for the official launch of Contour  in London on April 17th.  We’re excited to be working with our partner, Xeau who brings years of experience in the requirements management space.  More information on Contour in Europe can be found at www.contoureruope.com.

We’ll also be traveling through Germany, Belgium and Amsterdam to meet with Contour users and sample the local beer :) .  If you are located in one of those countries and are interested in having us drop by to meet in person and talk about Contour, drop us a line.

We’ll post updates and photos to our flikr stream so stay tuned.

Impact Analysis

Monday, January 29th, 2007

With the release of Contour 1.3 users are able to see immediately the project artifacts – and team members working on those items that may be affected. This is one of the primary benefits or implementing project traceability.

For example, if I am a business analyst and I’m about to make a change to a requirement, Contour shows me that Sue is currently working on a design document, Alan is working on a test case and Lisa has already completed the help page. I instantly know who and what may be affected.

If my change is substantial, I can contact the group beforehand to discuss – or I could make the change and have Contour notify the group with a link to the changed item. Everyone stays up to date and current on the latest requirement.

With so many relationships to track on a project – this helps everyone stay on top of who is working on what at any given time. I find that if team members can’t figure this information out in less than 30 seconds, they either make the change and don’t notify anyone or put off making the change. Both of these are bad decisions – and add unneeded risk to the project.

Of course this requires the relationships to be created within the project – but hopefully this feature provides another reason to start implementing traceability.

Impact Analysis

Demystifying Traceability

Tuesday, January 9th, 2007

The latest release of Contour, our requirements management tool, incorporates some new features that got me thinking about traceability.

At Jama we use relationship and traceability interchangeably. To us the term “relationship” is much easier to understand than “directional trace” even though it may not be technically correct. (Contour can be set to use whatever term you like).

Traceability sounds complicated, especially if it’s bi-directional traceability. I think that for many organizations the vocabulary is a barrier to understanding and implementing traceability. If it’s not easy to talk about, one would think it’s a pain to implement.

What is traceability?

Traceability is setting up relationships between items in your project that provide value to the team. A common scenario is to setup a relationship from the stakeholder request to the requirement and from the requirement to the design document.

Bi-directional traceability simply means the link goes two ways. If you can see that a requirement is related to a story card, you should see that the story card is related back to the requirement.

These relationships provide quite a bit of valuable information. First, if the project team needs to change the design, they know immediately which stakeholder to talk with. If the stakeholder changes their mind about the requirement, the team knows the exact requirement and design document that need to be updated.

I mentioned the “add value to the team” part because you can get carried away with setting up relationships. For some teams, such as those developing life critical systems, tracing to the code level is critical. If something was changed in the software that’s flying the plane I’m in, I want to be absolutely sure the project team knew every line of code that was affected and what needed re-testing.

For the majority of teams, I suggest tracing between the most critical items on the project. For example, if you are on the hook for an RFP or contract with a client, trace from those items to features and on to use cases and test cases. This required minimal time to setup and provides a great way to demonstrate that the software or product your team is building fulfills the original requirements – and was truly tested, especially if you integrate with an automated test tool.

I suggest tracing to change requests as well. This way every feature being developed ties back to either the original contracted scope – or a change request. This is a great guard against dreaded and costly “scope creep”.

Another challenge with traceability is it’s cumbersome to track manually. Unfortunately many of the enterprise RM tools continue to complicate things and make traceability difficult. For the most part these are old applications that have been bought and sold over the years so they’ve missed opportunities for usability updates.

Of course I’m biased toward our own tool, Contour, but we’ve worked to simplify the traceability process. Our goal is to enable more teams to benefits from trace relationships.  We’ll continue working with users and continue improving the process of linking items.

This post is getting long so I’ll come back to discuss the new features – “Impact Analysis” and “Changes with Impact” in my next posts.

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