Requirements Start With an IDEA

 

Situation: You Need a New Way to Deal with Project Requirements.

Requirements are those tricky, slippery things that define the success or failure of your project.  I recently ran across Jama Software, builders of software that seems to take an interesting approach to requirements gathering and management.  In this interview I spoke with Eric Winquist, CEO of Jama Software, a young startup gaining momentum in the collaborative requirements management space. 

Dave:  At Jama, you talk a lot about “fueling innovation through collaboration”.  Is that just a way of describing ways to easily change and understand the impact of requirements?  Or does your tool actually spur innovation in some way?

Eric Winquist, CEO of Jama Software:  We’re finding it does both.  First and foremost, Contour, is about making requirements management easier and helping teams manage complexity found in developing software applications or systems, designing new products or whatever their projects might be.  

Contour provides companies with a central location to store and collaborate on ideas, research and features which helps them innovate faster and more successfully. 

For 70% of enterprise organizations, innovation via new product development is a top strategic initiative; yet, the majority of these projects don’t end successfully.  Why is that?  When we founded Jama a little over year ago, we looked to answer this question.  From our personal experience in managing software development projects and the insights we gained from customers, we consistently saw a gap between the requirements definition phase and the ability to successfully deliver on them. 

When we created our tool, we built it on a core philosophy that by unlocking the requirements and getting the entire organization collaborating on the projects through a Web-based environment, project teams will increase their success rates.  When companies adopt this open collaborative approach to RM and innovation overall, it fosters new ideas and a cultural shift toward greater accountability to the goals of the projects across the entire organization.

Dave:   For most PM software vendors, the focus is at the Enterprise level these days, mostly on cross-departmental projects.  Some of the features of your product address requirements that span projects.  Do they address departmental boundaries in any special way?

Eric:  Yes.  The larger the organization, the greater the risk for information silos to exist.  And, when information silos exist, that’s when projects break down – errors get made leading to expensive rework and defects (you know, all the issues we’ve heard about ad nauseum for years around the failure of projects).   Eliminate the silos, and you eliminate a major point of failure. 

The focus is at the Enterprise level because the complexity is magnified.  Some of our enterprise customers have hundreds of projects going on concurrently, with thousands of moving parts within them that are interrelated across people, departments and other projects.  Companies that are successful have adopted an open innovation model that not only breaks down walls internally for greater internal collaboration; it also brings external audiences such as customers and partners into the process as well.  This is where collaborative Web-based tools are making such a difference.  In fact, we’ve found this has become one of the primary benefits customers are seeking in their selection of an RM solution.

Dave:  “Requirements span projects” – that’s a great point to make.  Other software vendors, like Microsoft, are trying to do a better job of integrating “non-project” work into the overall picture.  So you address operational requirements with your products and integrate that work into an overall picture of “what needs to be done”? 

Eric:  Absolutely.  Projects don’t live in isolation.  And neither do the tools that people use to manage them.  We believe an effective RM tool has to be built on an open architecture and integrate well with other tools within the larger picture.  We’ve structured our tool around the concept that requirements, use cases, defects, artifacts, ideas, release plans, etc. are all fundamentally items and these items have relationships with other items, and projects are basically the collection of all the specific items toward the completion of specific goal(s).   So when it comes to the management of these items within projects, the tool must make it easy to:

1: Capture - define requirements and other items. 
2. Connect - relate them to other items, projects and people. 
3. Control – assess impact and manage change when it occurs. 
4. Collaborate – keep the entire team in sync and up to date throughout the lifecycle.

For example, we have customers who use our tool as a centralized repository for capturing research documents, usability studies, videos, raw product ideas, etc., essentially leveraging the tool to manage items at the front-end of the innovation funnel, and thus connecting these items up to the requirements definition and management phase later in the product planning & development process – creating a stronger bridge between R&D and Product/Project Management.  In fact, we’re customizing this for a Fortune 100 technology company right now.  So, companies are definitely looking at RM from a much more strategic perspective now and wanting to tie it together end-to-end.

 
Dave:   So many vendors now are producing very simple, easy to use lightweight apps.  How important is simplicity in your design and where do you focus your efforts if not on adding new features?  Can you describe a new feature that perhaps looked like a good idea at first, but then wasn’t? 

Eric:  Simplicity is a must.  Web 2.0 as a buzzword has been overexposed, but there is an undeniable movement and demand across many categories of software to be light-weight and Web-based - RM included.  But what is that really all about?  I believe it’s less about technology and more about customers simply wanting tools that work and help them get things done.  The days of big, bulky enterprise suites that take 6-9 months to implement and people needing months and months of training to learn them, and even then get underutilized and abandoned after a year.  Who can afford that inefficiency in managing their business? The #1 criticism of traditional requirements management tools is that they’re too difficult to use.   

In many ways, Jama and other new vendors are at an advantage because we don’t have 10-year old code bases to manage.  So we can build our tools on modern, flexible platforms.   Also, we take an iterative approach to our development of Contour, so we’re constantly working on new ways in which we can improve our UI, make tasks easier to accomplish and simply make things more intuitive for our users.  We push things out in new releases every few weeks and see how people respond.  In fact, we did a complete overhaul of our UI in our 2.0 release in December.  Our customers provide as much input into our product roadmap as we do.  Some features are home runs, others don’t stick.  And, when that happens, we go back to the drawing board to figure out a smarter way. 

To answer the last part of your question, one of the challenging areas within RM is reporting.  At first glance, companies want the ability to build custom reports, so we offer a flexible and powerful Custom Report Designer in response to that need.  But, in practice, building custom reports is a complex art form in itself.  So, we’ve found that for some customers who don’t have an internal reporting guru on-staff, they have more success when we actually build the reports for them versus just handing them the keys to this feature.

Dave:  Thanks Eric for the Q&A session.  Appreciate your time and perspective on things.

If you have any specific questions for Eric, you can reach him at [email protected] or for more information about Jama Software, visit www.jamasoftware.com