jama
 

Jama Blog: Leverage your collective genius.









Posts Tagged ‘collaboration’

Social Traceability with Derwyn Harris

Wednesday, May 2nd, 2012

Today, the Sticky ToolLook newsletter from Stickyminds.com featured Jama Contour and conducted a short Q&A with Derwyn Harris, co-founder and senior solutions architect at Jama Software. In the interview he discusses “social traceability” in software development.

- – - – - – - – - – - – - – -

Sticky tool look: Would you give us your definition of “social traceability” as it applies to software development?

Derwyn Harris: Social traceability is a new concept with respect to project or product lifecycles regardless of software, hardware, or other. There are two concepts we hear time and time again from customers looking to improve efficiency and success in their process: collaboration and traceability. Collaboration is the ability for teams to effectively review, approve, and make decisions as part of an on-going process, and traceability connects the artifacts of a project, such as business requirements to technical requirements to test or, in an agile world, epics to stories to test. When we at Jama talk about “social traceability,” we are referring to how collaboration is continually occurring around the different artifacts. If the artifacts are connected through traceability, a solution should leverage that connection not only to show what artifacts are impacted but also to show who is impacted along with the conversations.

If I were a BA working on site with a customer and identified a change, I’d turn to Contour to see the impact of that change and whom it impacts. From there, I could better determine and communicate the scope of the change. Without a solution in place, days or weeks may go by before that information was truly understood.

Stl:What are some tools that can improve that traceability, and how do they help?

DH: That’s a great question because it raises an interesting point. Do we even need tools? The answer is absolutely! We’ve learned that what makes teams successful is their ability to communicate effectively around the project artifacts. Not all teams have the luxury of being a five-person team in a single room with a whiteboard. We’re dealing with complex projects and geographically dispersed teams. True traceability is information tied together for all to see, as compared to being managed separate from the live data. Collaboration should also be inherent in the tool and should utilize the traceability to better understand not only what’s impacted but also who.

Stl:How does social traceability impact our communication and productivity?

DH: In the past decade, we have experienced huge change in the social sphere that has altered how we interact and communicate with each other. This evolution in communication has been a bit slower to take hold in business process and project management. The main reason for this is that, with respect to building products or managing projects, it’s more than just collaboration. Projects need clear decisions and a broader view of how information is connected. I guess one why to think about it is that “social,” in and of itself, is very much about the moment, while a project is much more of a living entity that requires constant iterations and the ability to see the whole as well as the focused. Social traceability provides this holistic view across project information, teams, and time to better communicate and thus improve productivity through better efficiency and visibility.

Stl:What are some current traceability challenges, and how do you approach them?

DH: The biggest problem I see is that teams and organizations simply don’t track traceability. Those that do typically use a separate Excel sheet to manage how artifacts are linked, but the effort it takes to ensure this is accurate and up to date is huge, and it’s actual effectiveness is questionable because it lacks visibility.

Traceability is a problem for the entire team and not just a business analyst or project manager. I had someone ask me once on a demo “Who manages the traceability?” My response was that it’s the responsibility of the entire team. Traceability is managed throughout the lifecycle as we move downstream or upstream. Business analysts work on distilling the requirements or stories from a stakeholder’s requests, and QA works on creating test cases based on the upstream artifacts entered by the business analysts. This is why traceability needs to be considered a social solution. It’s about connecting the people together along with what they are working on in a natural flow that doesn’t burden one person but rather makes the entire team work more efficiently.

Derwyn invites you to send him your comments and questions about social traceability.

Health Information Exchange – Creating Member Transparency, Collaboration & Socialization

Wednesday, April 25th, 2012

This week Regence received recognition from Forrester Research related to myRegence.com for cracking “the transparency code.”

MyRegence.com has been around since 2005 to support members in searching for doctors, nearby providers, comparison tools, treatment cost estimates, and socializing with other members looking for the same information.

Although Regence isn’t the only payer providing such a platform for member socialization and collaboration, they are the first to receive a full case study review by Forrester who notes myRegence.com has influenced higher member satisfaction, meaningful behavioral change and solid engagement levels from both members and providers—further impacting improved health and reduced cost.

Health Technology Online just issued an article “3 Secrets of Successful HIEs” with the number one critical component being collaboration and buy-in from key stakeholders.  Each on clearly understanding and providing input into the clinical, business, and technical requirements necessary for the HIE and any vendor solution support.  HIEs are built on the premise of strong communication in an environment built on a high level of trust—essential for a successful outcome.

Payer-Provider Collaboration Can Improve IT Requirements & Meet Compliance

Thursday, March 15th, 2012

In my previous blog post regarding ICD-10, I made the comment that the right hand feeds the left—referring to how payer-provider collaboration can increase efficiencies around ICD-10 remediation.

ICD-10 is not the only compliance initiative that can benefit from bi-directional payer-provider collaboration. The reality of today, is both entities are faced with a myriad of compliance initiatives that intersect. Any or all of these intersections can turn chaotic, and fast.

If not managed properly it can potentially divert tasks at hand—impacting deadlines, project cost overruns, errors or bugs in the systems, gaps subjecting them to the risk of regulatory fines or even data breach events and expensive privacy/security remediation.

The complexity of these intersections needs organization that can only come from clear goals and collaboration—internally and externally.

Collaborating in the context of each compliance initiative can better define the IT requirements to build or renovate the right systems, define when, where or if they intersect, how and by what deadline. Increasing efficiency across transactional intersections, eliminating duplication of processes, and saving money.

As one example, AETNA is one of the progressive insurers running focus groups with their provider partners for the sake of building the right requirements into their provider portal. They understand building what AETNA wants—siloed decisions—won’t improve the quality of the IT build, transaction processes or related costs.

Collaborating with specific context to their provider portal—is one step in the right direction. This payer-provider relationship can be elevated now to ICD-10, ACO, HIE or any other IT-driven initiative.

Advocate Health Care, the largest hospital system in Illinois, and Blue Cross Blue Shield of Illinois (BCBSIL) are declaring some early successes with its provider-payer accountable care organization, which is the largest commercial ACO thus far. Their collaboration thrust them into the forefront of this major initiative.

Five Challenges to Agile Planning: Part 5 of 5

Tuesday, January 31st, 2012

FIVE: Losing the Forest for the Trees

The Challenge: In the early stages of a new Agile project, all is good. Your team is working on user stories, test cases, building features, and happily coding along. The vision and plan has (hopefully) been established and everyone’s excited about being outrageously successful. You’ve also comfortably tackled some of the early platform and architecture efforts. Now if you’ve already solved the first four challenges discussed, this challenge – Losing the Forest for the Trees – will be much less of a challenge. But as Agile hums along, the backlog increases, new ideas come into the mix, bugs stack up, and the development team starts getting tired and frustrated. Progress appears to be slowing down since more time is spent on bugs, design changes, and minor enhancements. At this point it seems easier to focus on what can get done over what should or must get done. You may start wedging in small features and incremental tweaks into sprints while bigger, more challenging – and more valuable – problems can’t be addressed since these bigger efforts don’t allow room to fix bugs and finish features. Decisions get tougher and frustrations set in. Your management team may even start thinking that Agile isn’t for you since the plan is not being delivered upon.

The Solution: As one of my client’s executives put it (and I’m sure he borrowed it from somewhere), “You need to keep the main thing, the main thing.” At this point it’s more important than ever to go back to the basics – clarify the vision, listen to real customer input, and focus on what the “main thing” is. What are the features, user stories, use cases, and other attributes that you MUST get right to be successful in the marketplace? As your solution gets close to delivery Agile can’t be a philosophical software development process, but a business process for delivering greater value to customers and competitive offerings to the marketplace. Use your Agile skills to make the tough decisions to cut less important features that aren’t complete, ignore seemingly critical (but not important) bugs and re-energize the team on those product attributes that your customers care about most. These tough decisions obviously can’t wait until the final pre-launch, but must consistently be made through the entire development process. While nothing provides more satisfaction than a complete product that does everything you want it to do, when the schedule conflicts with completeness (and it always will), err on delivering a solid solution that does less. Then, get it into the hands of real customers, learn, iterate and succeed.

Read part 1, 2, 3, 4 or download “The Five Challenges to Agile Planning” whitepaper.


How can we help?

Toll-Free: 1 (800) 679-3058
Direct: (503) 922-1058
Fax: (877) 665-8476

Jama Headquarters
600 NW 14th Ave. Suite 200
Portland, Oregon 97209
support@jamasoftware.com
sales@jamasoftware.com

Connect with Jama online:

           


CONTOUR
Overview
USD Pricing
Euro Pricing
Videos
Screenshots
Features
Why Contour
What's New
Review Center
Integrations
Technology
Download Contour
Free Trial
Request Demo
Login



CUSTOMERS
Overview
Government
Customer List
Success Stories
Testimonials

RESOURCES
News
Webinars
Whitepapers
Blog
Twitter

SUPPORT
Overview
Training
Pro Services
Support Forum
Documentation

COMPANY
About Us
Jama Partners
Management Team
Board & Advisors
Careers
Contact Us
Privacy  |  Legal  |  Preferences  |  Enjoy the Journey